Общие принципы разработки программных средств

ВСЕРОССИЙСКИЙ ЗАОЧНЫЙ  ФИНАНСОВО-ЭКОНОМИЧЕСКИЙ ИНСТИТУТ

 

 

КАФЕДРА  АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ 

 

ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИИ

 

 

 

 

 

 

 

 

КУРСОВАЯ РАБОТА

 

по дисциплине «Информатика»

 

на тему «Общие принципы разработки программных средств»

 

 

 

Исполнитель:

 

Карташевич Ольга Андреевна

 

специальность         Ф и Кр

 

группа                              21

 

№ зачетной книжки       07ФФБ03567

 

Руководитель:

 

                                                         Сазонова Наталья Стальевна

 

 

 

 

 

 

 

Москва- 2009

 

 

СОДЕРЖАНИЕ:

 

 

Введение…………………………………………………………………….3

 

1. Теоретическая часть

 

1.1 Классификация программных  средств………………………...….......5

 

1.2 Специфика разработки  программных средств……………………….8

 

1.3. Период разработки и эксплуатации  программного средства….........9

 

1.4. Понятие качества  ПС……………………………………………........13

 

1.5 Общие принципы обеспечения  надежности ПС……………….........14

 

1.6 Методы борьбы со  сложностью……………………………………....16

 

1.7 Обеспечение точности  перевода……………………………………...16

 

1.8 Преодоление барьера  между пользователем и            

 

разработчиком……..……………………………………………................17

 

1.9 Контроль принимаемых  решений……………………………………17

 

Заключение………………………………………………………………...18

 

2. Практическая часть

 

2.1 Общая характеристика  задачи………………………………………..19

 

2.2 Описание алгоритма решения задачи………………………………..20

 

Список использованной литературы…………………………………….25

 

 

 

 

 

 

 

 

Введение

 

   Обычно программы разрабатываются в расчете на то, чтобы ими могли пользоваться люди, не участвующие в их разработке (их называют пользователями). Для освоения программы пользователем помимо ее текста требуется определенная дополнительная документация. Программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией, называется программным средством (ПС). Программа позволяет осуществлять некоторую автоматическую обработку данных на компьютере. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Кроме того, программная документация помогает разобраться в самой программе, что необходимо, например, при ее модификации.

 

   Разработка программных средств очень трудный процесс, он состоит из многоуровневой системы, для этого надо знать какие программные средства существуют, понять их классификацию, принцип их взаимодействия, а главное как избавиться от барьера работы с ними.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Теоретическая часть.

 

1.1. Классификация программных  средств.

 

   Совокупность программ и сопровождающей их документации, предназначенная для решения задач на ПК, называется программным обеспечением. Оно необходимо для управления компьютером, и его можно разделить следующим образом: операционные системы, сервисные системы, программно-инструментальные средства и системы технического обслуживания.

 

   Главное место среди системных продуктов занимают операционные системы. Операционная система – пакет программ, хранящийся в долговременной памяти и используемый для управления устройствами, папками, пакетами программ и работой электронно-вычислительных машин в целом. До появления микропроцессоров каждый производитель разрабатывал свою собственную операционную систему. С эволюцией микропроцессорной техники потребности в ОС существенно изменились. До недавнего времени на большинстве ПК была установлена операционная система MS DOS (MS Disk Operating System – дисковая операционная система фирмы MS) или один из ее аналогов, например PC DOS (Personal Computer Disk Operating System – дисковая операционная система персональных компьютеров) фирмы IBM либо Novell DOS фирмы Novell.[2]

 

   Главными особенностями и отличиями современных операционных систем являются:

 

1. многозадачность.

 

2. развитый графический  пользовательский интерфейс.

 

3. устойчивость в работе  и защищенность.

 

4. полная независимость  от аппаратуры.

 

5. совместимость со  всеми видами приложений, разработанных  для MS DOS.

 

   Среди имеющегося разнообразия операционных систем особое место занимают сетевые ОС.

 

а) Сервисные системы  расширяют возможности ОС, предоставляя пользователю, а также выполняемым  программам набор разнообразных  услуг. К сервисным системам относят  оболочки, утилиты и операционные среды.

 

б) Оболочка операционной системы – это программный  продукт, который делает общение  пользователя с компьютером более  облегченным..

 

в) Утилиты – служебные программы, предоставляющие пользователю ряд дополнительных услуг. К утилитам относят такие программные средства, как: дисковые компрессоры; дисковые дефрагментаторы;  программы резервного копирования данных; архиваторы; программы, оптимизирующие использование оперативной памяти; программы защиты и восстановления данных; антивирусные программы и др. Для обслуживания жесткого диска в среде Windows используются служебные программы.

 

   Дадим им краткую характеристику.

 

1) Утилита дефрагментации  диска предназначена для оптимизации  работы диска и повышения скорости  доступа к нему. Дефрагментация  диска состоит в том, что фрагменты файла собираются в один блок. Можно выбрать один из трех способов дефрагментации: полную дефрагментацию, дефрагментацию только файлов, объединение свободных участков диска.

 

2) Программа проверки  диска проверяет достоверность информации, которая содержится в таблицах распределения файлов диска, а также осуществляет поиск сбойных блоков диска.

 

3) Программа уплотнения  диска (предназначена для создания  и обслуживания сжатых дисков.

 

4) Программа копирования  данных на диске работает в трех режимах: резервирования, восстановления и сравнения исходных данных с их резервными копиями. Для резервных копий используются дискеты, кассеты с магнитной лентой или другие сменные носители информации, а также возможно резервирование на другие жесткие диски.

 

5) Программа Системный  монитор анализирует пиковую  нагрузку процессора и других  ресурсов.

 

6) Антивирусные программы  появились почти одновременно  с персональными компьютерами, и  с тех пор состав их постоянно  растет. Современные антивирусные пакеты несут задачу выявления и устранения компьютерных вирусов. Одним из наиболее перспективных направлений развития антивирусных средств является создание сетевых версий этих продуктов. Сетевой антивирусный пакет устанавливается на сервер и при  обнаружении вируса блокирует дальнейшую работу с пораженными ресурсами.

 

7) Программно-инструментальные  средства – это программные  продукты, предназначенные для разработки  программного обеспечения. К ним  относят системы программирования, которые включают систему команд процессора и периферийных устройств, трансляторы с различных языков программирования.

 

8) Системы технического  обслуживания – совокупность  программно-аппаратных средств ПК  для обнаружения сбоев в процессе  работы компьютера. Они нужны  для проверки работоспособности отдельных узлов, блоков и всей машины в целом, являясь инструментом специалистов по эксплуатации и ремонту технических средств компьютера.

 

1.2 Специфика разработки  программных средств

 

   Разработка программных средств имеет ряд специфических особенностей, отметим главные из них:

- неформальный  характер требований к ПС (постановки задачи) и понятия ошибки в нем,  но формализованный основной объект разработки программы ПС. Тем самым разработка ПС содержит определенные этапы формализации.

- разработка ПС носит творческий  характер (на каждом  шаге  приходится делать какой-либо выбор, принимать какое-либо решение). Тем самым эта разработка ближе к процессу проектирования каких-либо  сложных  устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до  самого  ее конца.

- особенность продукта разработки представляет  собой некоторую совокупность текстов (т.е.  статических объектов),  смысл же этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т.е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств.

 

1.3. Этапы разработки и эксплуатации программного средства.

 

   В настоящее время можно выделить 5 основных подходов к организации процесса создания и использования ПС.

 

   Модель водопада  (каскадная моель)

 

   Модель водопада (waterfall model или последовательная разработка) – наверное, самый известный, исторически появившийся одним из первых процесс разработки. Он был описан в статье Ройса (W.W.Royce) в 1970 году (на самом деле, Ройс критиковал этот процесс, предлагая в качестве альтернативы итеративную разработку). Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей процесс:

 

Рисунок 1.

 

   Отдельные задачи, из которых состоит любой проект (не обязательно выполняемый по модели водопада), можно разделить между несколькими процессными областями. Классическая водопадная модель включает следующие области:

- разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.

- анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.

- реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.

- тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.

- развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.

 

   В модели водопада каждая из процессных областей представляет собой отдельную фазу проекта. Фазы выполняются строго последовательно, т.е. анализ и дизайн начинаются после завершения разработки требований, началу реализации предшествует завершение дизайна и т.д.

 

   Основные соображения для использования такой модели разработки вполне очевидны. Как известно, стоимость исправления ошибок, сделанных в ходе выполнения проекта зависит от того, насколько быстро эти ошибки обнаруживаются и исправляются. Ошибку в требованиях достаточно просто исправить на этапе разработки требований, но если о ней становится известно после завершения развертывания, последствия могут быть катастрофическими. Модель водопада стремится уменьшить, насколько это возможно, число таких долгоживущих ошибок. Для этого разработка дизайна не должна начинаться, пока требования не будут определены с достаточным качеством, кодирование не начинается до появления полного дизайна системы и т.д.

 

   Насколько эффективным оказался такой подход? Он хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения. Благодаря этому она часто используется в больших организациях (таких как Министерство обороны США и NASA) при строгих требованиях к надежности создаваемого ПО.

 

   Однако практика показала следующие недостатки этого процесса: процесс плохо работает в проектах с нечеткими требованиями. Даже если проектная команда считает, что полностью проработала и документировала функциональный дизайн системы, он может значительно отличаться от ожиданий пользователей. С большой вероятностью это расхождение будет обнаружено не на этапе рецензирования функциональной спецификации (редкий заказчик способен представить поведение реальной системы, читая документ с описанием ее функциональности), а во время внедрения продукта.

   Процесс крайне неэффективен при постоянных изменениях требований (что как правило случается в проектах, длящихся больше одного-двух месяцев). Каждое изменение заставляет возвращаться к фазе определения требований и повторять весь процесс с начала.

   Сложно управлять рисками некоторых типов (таких, как риски, связанные с использованием новых технологий или риски некорректного определения требований). Подобные риски могут проявить себя только на этапе реализации (если не тестирования), когда число возможных путей исправления ситуации намного меньше, чем в начале проекта.

Весьма ограничены возможности  оценки и корректировки важных атрибутов  проекта – скорости разработки, качества продукта, обоснованности принятых архитектурных решений. Адекватно  оценить эти атрибуты становится возможным только на поздних этапах проекта.