Большинство сложных систем имеет иерархическую внутреннюю структуру, что позволяет рассматривать их как некоторую совокупность взаимозависимых подсистем. Внутренние связи элементов таких подсистем сильнее, чем связи между подсистемами.

          На свойствах иерархических систем («целое-часть») строится блочно-иерархический подход к исследованию и созданию ПО, предполагающий сначала создавать части объектов (блоки, модули), а затем собирать из них объект

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

Чем выше блок, тем более абстрактным должно быть его описание. Это сохраняет возможность осмысления проекта и, возможность принимать правильные решения

Чем выше блок, тем более абстрактным должно быть его описание. Это сохраняет возможность осмысления проекта и, возможность принимать правильные решения

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

Использование блочно-иерархического подхода

•  делает возможным создание сложных систем;

•  упрощает проверку работоспособности системы в целом и отдельных ее блоков;

обеспечивает возможность модернизации систем

60

Жизненный цикл ПО и этапы его разработки.

Жизненным циклом (ЖЦ) ПО называют период от момента появления идеи создания ПО до момента завершения его поддержки разработчиком или фирмой, выполнявшей сопровождение.

   ЖЦ состоит из ряда процессов, состав которых регламентируется стандартом ISO/IEC 12207: 1995. 

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

По стандарту процесс разработки включает следующие действия:

• подготовительную работу – выбор модели ЖЦ, стандартов, методов и средств разработки, а также составление плана работ;

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

• проектирование архитектуры системы – определение состава необходимого оборудования, ПО;

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

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

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

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

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

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

• интеграцию системы – сборку всех компонентов системы, включая ПО и оборудование;

• квалификационное тестирование системы – тестирование системы на соответствие требованиям к ней и проверка оформления и полноты документации;

• установку программного обеспечения – установку программного обеспечения на оборудовании заказчика и проверку его работоспособности;

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

61

ГОСТ 19.102-77 «Стадии разработки» Постановка задачи. Анализ требований и определение спецификаций Проектирование Реализация. Сопровождение.

Указанные действия можно сгруппировать, выделив следующие основные этапы разработки ПО (ГОСТ 19.102-77 «Стадии разработки»):

• постановка задачи (стадия «Техническое задание»);

• анализ требований и разработка спецификаций (стадия «Эскизный проект»);

• проектирование (стадия «Технический проект»);

• реализация (стадия «Рабочий проект»);

• сопровождение.

В процессе постановки задачи четко формулируют назначение ПО и определяют основные требования к нему.

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

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

        Анализ требований и определение спецификаций

Спецификациями называют точное формализованное описание функций и ограничений разрабатываемого ПО.

Для получения спецификаций:
 - выполняют анализ требований ТЗ;
 - формулируют содержательную постановку задачи;
 - выбирают математический аппарат формализации;
 - строят модель предметной области;
 - определяют подзадачи и выбирают или разрабатывают методы их решения.

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

На этом этапе также целесообразно сформировать тесты для поиска ошибок в ПО, указав ожидаемые результаты

                                                    Проектирование

Основной задачей этого этапа является определение подробных спецификаций разрабатываемого ПО. Процесс проектирования сложного программного обеспечения обычно включает:

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

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

• проектирование компонентов.

Результатом проектирования является детальная модель разрабатываемого ПО вместе со спецификациями его компонентов всех уровней.

                                                 Реализация

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

Сопровождение – это процесс создания и внедрения новых версий программного продукта.

   Причинами выпуска новых версий могут служить:

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

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

• изменение среды функционирования (появление новых АО или ПО, с которыми взаимодействует сопровождаемое программное обеспечение).

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

62

Эволюция моделей жизненного цикла ПО

Каскадная модель. (1970-1985 годы)

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

Достоинствами такой схемы являются:

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

• простота планирования процесса разработки.

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

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

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

• изменение требований заказчика непосредственно в процессе разработки;

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