Лекция 5

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

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

Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3 –5) специалистов, которые:

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

• не предназначены для массового тиражирования и распространения как программного продукта на рынке, их оценивают качественно и интуитивно преимущественно как “художественные произведения”;

• не имеют конкретного независимого заказчика-потребителя, определяющего требования к программам и их финансирование;

• не ограничиваются заказчиком допустимой стоимостью, трудоемкостью и сроками их создания, требованиями заданного качества и документирования;

• не подлежат независимому тестированию, гарантированию качества и/или сертификации.

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

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

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

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

• для организации и координации деятельности специалистов-разработчиков при наличии единой, крупной целевой задачи, создания и совершенствования программного продукта, необхо­димы квалифицированные менеджеры проектов;

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

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

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

Такие крупномасштабные комплексы программ являются компонентами систем, реализующими обычно их основные, функциональные свойства, увеличивающими сложность и создающими предпосылки для последующих изменений их жизненного цикла. Реализация ЖЦ, методологии управления и изменения ПС зависит от многих факторов, от персонала, технических, организационных и договорных требований и сложности проекта. Множество текущих состояний и модификаций компонентов сложных ПС менеджерам необходимо упорядочивать, контролировать их развитие и применение участни­ками проекта. Организованное, контролируемое и методичное отсле­живание динамики изменений в жизненном цикле программ и данных, их слаженная разработка при строгом учете и контроле каждого изменения, являет­ся основой эффективного, поступательного развития каждой крупной системы методами программной инженерии.

Два взгляда на ЖЦ ПО: статический и динамический.

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

• основные (приобретение, поставка, разработка, эксплуатация, сопровождение);

• вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем);

• организационные (управление, создание инфраструктуры, усовершенствование, обучение).

Динамический взгляд на ЖЦ ПО отражается в модели ЖЦ во времени.

Модель ЖЦ ПО – это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. В любой модели ЖЦ рассматривается как совокупность стадий ЖЦ. Стадия ЖЦ – это часть ЖЦ ограниченная временными рамками, по завершении которой достигается определенный важный результат в соответствии с требованиями для данной стадии ЖЦ.

Модели ЖЦ:

• каскадная (водопадная);

• эволюционная;

• модель, основанная на формальных преобразованиях;

• итерационные модели (пошаговая и спиральная).

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

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

Особенности модели ЖЦ, основанной на формальных преобразованиях: использование специальных нотаций для формального описания требований; кодирование и тестирование заменяется процессом предобразования формальной спецификации в исполняемую программу. Достоинства: формальные методы гарантируют соответствие ПО спецификациям требований к ПО, т. о. вопросы надежности и безопасности решаются сами собой. Недостатки: большие системы сложно описать формальными спецификациями; требуются специально подготовленные и высоко квалифицированные разработчики; есть зависимость от средств разработки и нотации спецификаций.

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