ОСНОВНЫЕ ЭТАПЫ РАЗРАБОТКИ ПРОГРАММНОГО ПРОДУКТА

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

При создании ПП можно выделить следующие основные этапы:

1) системный анализ (определение требований и анализ);

2) проектирование;

3) реализация;

4) тестирование;

5) внедрение;

6) эксплуатация и сопровождение;

7) эволюция.

Характеристика основных этапов

Этап системного анализа

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

1) анализ выдвинутых требований и определение реальной возможности их выполнить;

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

3) формализация требований заказчика;

4) оценка сложности задачи;

5) разработка целей программного продукта с точки зрения пользователя;

6) разработка целей проекта, которые касаются только самого процесса разработки.

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

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

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

Цели проекта, в отличие от целей продукта, связаны с самим процессом разработки и касаются его стоимости, сроков реализации проекта, адаптируемости программы и т.д.

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

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

Этап проектирования

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

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

Для того, чтобы проектные решения были максимально четкими и ясными и чтобы свести к минимуму число ошибок проектирования, необходимо соблюдать следующие условия:

1) каждая подсистема должна быть функционально замкнутой, т. е. результатом ее работы должна быть полная реализация определенной функции, тем самым обеспечивается независимость подсистем;

2) все связи между подсистемами должны быть явно описаны.

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

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

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