Жизненный цикл программы

Жизненный цикл программного обеспечения (ЖЦ ПО) — это совокупность взаимосвязанных процессов от момента появления идеи создания программного обеспечения до окончания его эксплуатации.

Описание структуры ЖЦ ПО и состав его процессов регламентируется международным стандартом ISO/IEC 12 207: 1995 «Information Technologe — Software Life Cycle Processes» («Информационные технологии — Процессы жизненного цикла программного обеспечения»). Отечественный вариант стандарта называется ГОСТ Р ИСО/МЭК 12 207—2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

Согласно этому стандарту, архитектура ЖЦ ПО состоит из трех компонентов:

• 1) Основные процессы: Приобретение, Поставка, Разработка, Эксплуатация, Сопровождение;
• 2) Поддержка: Документирование, Конфигурационное управление, Обеспечение качества, Верификация, Валидация (проверка правильности), Управление проектом, Ревизия отчетов, Решение задач (устранение дефектов);
• 3) Организация. Управление, Инфраструктура, Совершенствование, Обучение.

Стандарт состоит из семи разделов и четырех приложений. Разделы 1—4 являются вводными. Разделы 5—7 состоят из подразделов, в которых раскрывается содержание работ и даются комментарии к ним. Общее число работ и комментариев превышает 220.

Процесс Разработка программного обеспечения (разд. 5.3) содержит 13 подразделов:

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

Можно выделить следующие укрупненные этапы разработки ПО с учетом соответствующих стадий разработки по ГОСТ 19.102—77 «Стадии разработки»:

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

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

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

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

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

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

Проектирование — это процесс разработки структурной схемы ПО с проектированием компонентов и их взаимосвязей.

Реализация — это процесс программирования компонентов ПО на выбранном языке программирования, их тестирования и отладки.

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

К оценке длительности и трудоемкости разработки ПО предъявляются следующие требования:

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

На практике применяются следующие основные методы оценки трудоемкости разработки ПО:

• • методика СОСОМО;
• • оценка трудозатрат по функциональным точкам;
• • экспертная оценка.

Методика СОСОМО (Constmctive Cost Model) базируется на оценке трудоемкости в зависимости от количества строчек программного кода. Эта зависимость выражается формулой.

где Т — трудозатраты (чел/мес); KLOC — количество строчек кода (без учета комментариев); EAF — фактор корректировки трудозатрат в зависимости от факторов среды; аир — константы, определенные в процессе анализа проекта.

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

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

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

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

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

где L, — наилучшая оценка; 5, — наихудшая оценка; М_; — наиболее вероятная оценка.

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

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

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

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

При авторской разработке весь жизненный цикл разработки поддерживается одним человеком — автором. Такой метод применим в области создания наукоемких приложений, для реализации которых требуется детальное изучение предметной области, а круг потребителей приложения достаточно узок. Однако для современных массовых разработок такой метод неприменим из-за их объема и сложности, а также необходимости их длительной поддержки и сопровождения.

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

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

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

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

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

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

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

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

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

• • подготовка процесса;
• • обеспечение качества продукта;
• • обеспечение процесса;
• • обеспечение систем качества.

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

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

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

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

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

Можно выделить три модели жизненного цикла программного обеспечения:

• • каскадная модель;
• • модель с промежуточным контролем;
• • спиральная модель.

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

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

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

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

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

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

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

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

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