Программный продукт и информационные технологии

 

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

определение потребностей;

исследование и описание основных концепций;

проектирование и разработка;

испытания системы;

создание и производство;

распространение и продажа;

эксплуатация;

сопровождение и мониторинг;

снятие с эксплуатации (утилизация).

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

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

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

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

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

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

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

Модель процессов жизненного цикла системы и степень её практического применения в качестве обязательного или рекомендуемого документа зависит от роли конкретного  программного продукта в системе. Должна быть определена соответствующая модель жизненного цикла системы, в которой  программный продукт становится её частью. Установление этого поможет  определить, можно ли использовать конкретную модель для разработки, эксплуатации или сопровождения  программного средства. Программные  средства могут быть постоянно (резидентно) размещены в компьютерах, встроены как часть программно-аппаратных средств или интегрированы в  объект технических средств. В любом  случае заказ, поставку, разработку, эксплуатацию или сопровождение программных  средств необходимо координировать и гармонизировать с аналогичными процессами для всей исходной системы.

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

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

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

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

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

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

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

 

 

 

 

 

3. Модели  жизненного  цикла  программного продукта

Каскадная модель была введена  в 70 – 80 гг. Она удобна для однородных ПП, когда каждое приложение представляло собой единое целое.

Основные характеристики модели:

- Жизненный цикл разбивается  на этапы (фазы);

- Переход с этапа на  этап – только после полного  завершения текущего этапа;

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

Главные характерные черты каскадной модели следующие:

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

циклические повторения реализованных  фаз с возможно более ранней фазы.

 

. Каскадная модель ЖЦПО.

 

В каскадной модели успешное окончание одной из фаз ЖЦПО означает достижение соответствующей цели инженерного  программирования.

К этим подцелям необходимо добавить еще две:

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

Кодируемость – получение полного, верифицированного набора компонентов программы.

Основные достоинства:

Формирование полного  набора проектной документации в  конце работы над этапом. Документация отвечает критериям полноты и  завершенности;

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

Основные недостатки:

- Большие сроки от  анализа до завершения;

- Требования к ПО «заморожены»  в виде ТЗ до конца разработки.

 

Не углубляясь в экономический  анализ, которому Б.У. Боэм уделяет большое  внимание в книге «Инженерное  проектирование программного обеспечения», скажем лишь, что экономическое обоснование  каскадной модели, ориентированной  на последовательное достижение целей, базируется на двух главных предпосылках:

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

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

 

Рассмотрим одно из усовершенствований идеальной каскадной модели –  пошаговую разработку.