Файл: Основы проектирования программ. Этапы создания программного обеспечения.pdf

Стандарт IEEE 1233-1998 «Guide for developing system requirements specifications» дает описание правилам построения требований для программно-аппаратных систем в целом, а также определяет необходимые свойства и атрибуты набора требований. Согласно стандарту, процесс разработки требований включает определение, организацию, представление и модификацию требований.

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

Рассмотрим стандарты, которые регламентируют процесс проектирования архитектуры АИС. Стандарт IEEE 1016-1998 «Recommended Practice for Software Design Descriptions» описывает принципы разработки непосредственно архитектуры АИС, а не ее компонентов.

Стандарт ISO/IEC 42010 IEEE Std 1471-2000 «System and software engineering – Recommended practice for architectural description of software-intensive systems». Представляет архитектуру системы в виде комплекса представлений, которые отражают структуру ПО с разных точек зрения. В соответствии со стандартом каждое представление архитектуры должно фиксировать отраженные в нем взгляды и интересы, причины, обуславливающие необходимость такого рассмотрения системы, несоответствия между элементами одного представления или между различными представлениями, а также различную служебную информацию.

Стандарт ISO 9001:2000 «Quality management systems – Requirements» определяет требования к качеству программного продукта, а также правила его обеспечения. Стандарт ISO/IEC 90003:2004 «Software engineering – Guidelines for the application of ISO 9001:2000 to computer software» описывает положения по применению стандарта ISO 9001:2000 к программному обеспечению. Также этот стандарт помогает определить набор техник и процедур, которые будут применяться для осуществления контроля и обеспечения качества разрабатываемых программ.

Отечественной разработкой стал стандарт ГОСТ 34. Согласно этому стандарту жизненный цикл процесса разработки АИС делится на следующие этапы:

1. Формирование требований к АС.
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.

У этого стандарта есть один недостаток: стандарт является старым. В этом стандарте заложены устаревшие представления об архитектуре АИС. Примерами этого являются следующие утверждения:

• Программные продукты двухуровневые, включающие клиентскую программу и сервер СУБД.
• Описание структуры таблиц базы данных дает представление о логической модели данных.
• Используется однооконный пользовательский интерфейс.
• Система содержит небольшое количество отчетов, они являются бумажными и печатаются принтере матричного типа.
• АИС разрабатывается для решения задач обработки данных, которые имеют четкий вход и выход и являются узкоспециализированными. Основу обработки информации составляет алгоритм.

---

Так же существуют следующие стандарты разработки АИС:

«Custom Development Method» методика компании «Oracle», применяемая для разработки прикладных информационных систем. Этот метод является технологическим материалом, детализированным до уровня шаблонов проектной документации, рассчитанной на применение в проектах компании. Согласно этому стандарту при разработке программного обеспечения применяется классическая модель жизненного цикла программного продукта.

Стандарт «Rational Unified Process» (RUP) представляет разработку программного обеспечения в виде итеративной модели жизненного цикла, который включает следующие фазы: начало, исследование, построение и внедрение. Каждая фаза жизненного цикла АИС может разбиваться на этапы, называемые итерациями. В результате осуществления этих этапов происходит выпуск версий программного продукта для внутреннего или внешнего использования. Прохождение процесса разработки через четыре этапа называют циклом разработки. Каждый цикл разработки завершается генерацией версии системы. Если после версия системы не удовлетворяет требованиям пользователя, то разработанный продукт продолжает свое развитие и проходит те же этапы разработки.

Стандарт «Microsoft Solution Framework» (MSF) похож на стандарт «RUP» тем, что делит разработку программного обеспечения на четыре фазы: анализ, проектирование, разработка, стабилизация. Эта модель является итерационной, что предполагает использование объектно-ориентированного подхода при моделировании системы. Стандарт «MSF» в сравнении со стандартом «RUP» больше ориентирован для разработки бизнес- приложений.

Стандарт «Extreme Programming» (XP) был создан в 1996 году и является самым новым среди рассмотренных стандартов. Основу этого стандарта составляет командная работа, с организацией эффективной коммуникацией между заказчиком и разработчиков во время всей разработки АИС. При этом разработка АИС проводится с использованием последовательно разрабатываемых прототипов АИС.

1.4 Характеристика этапов создания программных продуктов

Рассмотренные стандарты разработки программного обеспечения объединяет наличие следующих стадий:

1. Анализ требований к проекту.
2. Проектирование.
3. Реализация.
4. Тестирование продукта.
5. Внедрение и поддержка.

Общая схема этапов процесса разработки программного обеспечения представлена на рисунке 4.

---

Рисунок 4. Процесс разработки программного обеспечения.

Дадим характеристику каждой стадии разработки программного обеспечения.

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

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

• подбор оптимальных решений для клиентов;
• определение необходимой степени автоматизации деятельности организации;
• выявление необходимости в автоматизации конкретных бизнес-процессов.

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

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

На стадии проектирования осуществляется разработка следующих проектных решений:

1. Выбор платформы, на которой будет осуществляться функционирование системы языка или языков реализации;
2. Назначение требований к пользовательскому интерфейсу;
3. Определение наиболее подходящей СУБД.

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

1. Проектирование архитектуры системы.
2. Выявление требований к аппаратному обеспечению.
3. Планирование комплекса мероприятий для внедрения программного обеспечения.
4. Разработка документов, регламентирующих использование программного продукта.

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

---

• Внутренней организации программного обеспечения;
• Пользовательского интерфейса;
• Разграничения доступа.

Результатом этого этапа является рабочая версия продукта.

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

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

В результате процесса тестирования осуществляется устранение всех недостатков системы и дается заключение о ее качестве.

После того как программное обеспечение проходит процесс тестирования, осуществляется внедрение системы. Процесс внедрения программного продукта, как правило, предусматривает следующие этапы:

1. Установку и настройку программного обеспечения.
2. Процесс обучения пользователей.
3. Собственно эксплуатацию системы.
4. Основы проектирования программного обеспечения

2. Сущность процесса проектирования программного обеспечения

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

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

---

Как правило, процесс проектирования программных продуктов делится на два этапа:

• предварительное проектирование;
• детальное проектирование.

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

Процесс предварительного проектирования включает следующие этапы:

• идентификацию подсистем;
• определение основных принципов управления подсистемами;
• взаимодействие подсистем.

Рисунок 5. Информационные связи процесса проектирования.

К процессу предварительного проектирования относятся следующие типы деятельности:

1. Структурирование системы, в процессе которого система разделяется на ряд подсистем. Подсистемой называют независимый программный компонент. Затем определяют способы взаимодействия подсистем.
2. Моделирование управления, в процессе которого определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули, в процессе которой выделенные подсистемы делятся на модули. Затем происходит определение типов модулей и межмодульных соединений.

В результате осуществления стадии структурирования системы получаются следующие виды моделей:

• модель хранилища данных;
• модель клиент-сервер;
• трехуровневая модель;
• модель абстрактной машины.

Модель хранилища данных, которая представлена на рисунке 6, разделяет данные подсистемы, которые находятся в общей памяти. Эти данные впоследствии образуют базу данных программного продукта. Поэтому в каждом программном продукте должна быть предусмотрена система управления базой данных.

Рисунок 6. Модель хранилища данных.

Клиент-серверная модель используется для проектирования распределенных систем, в которых компоненты системы распределены по серверам. Для передачи данных в клиент-серверных системах применяются сетевые протоколы, например, протокол TCP/IP. Структура клиент-серверной модели представлена на рисунке 7.

---