Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

В 1995 г. компания Standish Group проанализировала работу 364 американских корпораций и итоги выполнения более 23 000 проектов, связанных с разработкой ПО, и сделала следующие выводы:

 16,2 % проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

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

 31,1 % проектов были аннулированы до завершения.

Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89 %, а срок выполнения - на 122 %.

В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую сторону (26, 46 и 28 %, соответственно).

В числе причин возможных неудач фигурируют:

 нечеткая и неполная формулировка требований к ПО;

 недостаточное вовлечение пользователей в работу над проектом;

 отсутствие необходимых ресурсов;

 неудовлетворительное планирование;

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

 новизна используемой технологии для организации;

 отсутствие грамотного управления проектом;

 недостаточная поддержка со стороны высшего руководства.

Эдвард Йордан, один из ведущих мировых специалистов в области программной инженерии, анализируя причины неудач, отмечал, что множество проектов выполнялось в экстремальных условиях. Для таких проектов он даже предложил название «death march», буквально - «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50 %. По отношению к проектам создания ПО это означает наличие, как минимум, одного из следующих ог- раничений:

 план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной;

 количество разработчиков уменьшено более чем наполовину, по сравнению с необходимым;

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

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

Такие проекты порождаются самыми различными причинами, например:

 высокой конкуренцией, вызванной появлением новых компаний на рынке или новых технологий;

 воздействием неожиданных правительственных решений;

 политическими «играми» руководства;

 наивным оптимизмом и менталитетом первопроходцев у неопытных разработчиков.

Такие «смертельные марши» предъявляют особые требования к используемым методологиям, технологиям и средствам разработки ПО, независимо от того, объективные или субъективные причины лежат в их основе.

Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием программная инженерия (software engineering).

В процессе становления и развития программной инженерии можно выделить два этапа:

1) 1970 и 1980 годы - систематизация и стандартизация процессов создания ПО (на основе структурного подхода); в 1975 г. в США появилось первое издание, посвященное программной инженерии, IEEE Transactions on Software Engineering;

2) 1990 годы - начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).

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

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

Современные крупные проекты ППП и ИС характеризуют, как правило, следующие особенности:

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

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

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

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

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

 значительная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС. Жизненный цикл ПО

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

Структуру ЖЦ ПО регламентирует международный стандарт ISO/IEC 12207:1995 «Информационные технологии - Процессы жизненного цикла ПО» (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике).

В России в 1970-х годах создание ПО регламентировалось стандартами ГОСТ ЕСПД (серия ГОСТ 19.XXX), например, ГОСТ 19.102 77. Единая система программной документации. Стадии разработки. В 1980-1990-х годах создание автоматизированных систем регламентировалось стандартами ГОСТ ЕСС АСУ - ГОСТ 24.XXX и 34 XXX. например, ГОСТ 34.601-90 (ЕСС АСУ - Единая система стандартов автоматизированных систем управления). Информационная технология Автоматизированные системы. Стадии создания. К настоящему времени эти стандарты устарели и концептуально, и по форме.

С 1 июля 2000 года в России принят стандарт ГОСТ Р ИСО/МЭК 12207, разработанный на основе упомянутого выше международного стандарта. Стандарт состоит из семи разделов и четырех приложений.

Разделы 1-4 являются вводными, где сформулированы цели стандарта и области применения, определены основные термины, приведены ссылки на другие стандарты, поддерживающие разработку программных средств.

В разделах 5-7 подробно раскрывается содержание всех процессов, происходящих на разных стадиях жизненного цикла программного обеспечения.

Процессы жизненного цикла программного обеспечения разделены на три группы (рис. 7):

 основные;

 вспомогательные;

 организационные.

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

1. Инициирование приобретения;

2. Подготовку заявочных предложений;

3. Подготовку и корректировку договора;

4. Надзор за деятельностью поставщика;

5. Приёмку и завершение работ.

Рис. 7. Структура жизненного цикла программного обеспечения

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

 определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы программных продуктов или услуг;

 анализ требований к системе;

 принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;

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

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

Заявочные предложения должны содержать:

 требования к системе;

 перечень программных продуктов;

 условия и соглашения;

 технические ограничения (например, среда функционирования системы).

Заявочные предложения направляются выбранному поставщику (или нескольким поставщикам в случае проведения тендера).

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

Подготовка и корректировка договора включают следующие задачи:

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

 выбор конкретного поставщика на основе анализа предложений;

 подготовку и заключение договора с поставщиком;

 внесение изменений (при необходимости) в договор в процессе его выполнения.

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

В процессе приемки подготавливаются и выполняются необходимые тесты.

Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.

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

 подготовку ответа на заявочные предложения;

 подготовку договора,

 планирование;

 выполнение и контроль;

 проверку и оценку;

 поставку и завершение работ.

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

Планирование включает следующие задачи:

 принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;

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

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

 подготовительную работу;

 анализ требований к системе;

 проектирование архитектуры системы;

 анализ требований к ПО;

 проектирование архитектуры ПО;

 детальное проектирование ПО;

 кодирование и тестирование ПО;

 интеграцию ПО;

 квалификационное тестирование ПО;

 интеграцию системы;

 квалификационное тестирование системы;

 установку ПО;

 приёмку ПО.

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

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

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

Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

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

 внешних интерфейсов;

 спецификаций надежности и безопасности;

 эргономических требований;

 требований к используемым данным;

 требований к установке и приемке;

 требований к пользовательской документации;

 требований к эксплуатации и сопровождению.

Требования к ПО оцениваются исходя из критериев соответствия требований к системе, реализуемости и возможности проверки при тестировании.

Проектирование архитектуры ПО включает следующие задачи (для каждого компонента ПО):

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

 разработку и документирование программных интерфейсов ПО и баз данных;

 разработку предварительной версии пользовательской документации;

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

Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

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

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

 разработку и документирование детального проекта баз данных;

 обновление (при необходимости) пользовательской документации;

 разработку и документирование требований к тестам плана и тестирования компонентов ПО;

 обновление плана интеграции ПО.

Кодирование и тестирование ПО охватывают следующие задачи:

 разработку (кодирование) и документирование каждого компонента ПО и базы данных, а также совокупности тестовых процедур и данных для их тестирования;

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

 обновление (при необходимости) пользовательской документации;

 обновление плана интеграции ПО.

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

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

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

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

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

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

 эксплуатационное тестирование;

 эксплуатацию системы;

 поддержку пользователей.

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

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

 определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.

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

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

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

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

Процесс сопровождения охватывает следующие действия:

 подготовительную работу;

 анализ проблем и запросов на модификацию ПО;

 модификацию ПО;

 проверку и приемку;

 перенос ПО в другую среду;

 снятие ПО с эксплуатации.

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

 планирование действий и работ, выполняемых в процессе сопровождения;

 определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

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

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

 оценка целесообразности проведения модификации и возможных вариантов ее проведения;

 утверждение выбранного варианта модификации.

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

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

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

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

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

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

 подготовительную работу;

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

 выпуск документации;

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

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

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

 подготовительную работу;

 идентификацию конфигурации;

 контроль конфигурации;

 учет состояния конфигурации;

 оценку конфигурации;

 управление выпуском и поставку.

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

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

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

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

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

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

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

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

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

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

 подготовительную работу;

 верификацию.

В процессе верификации проверяются следующие условия:

 непротиворечивость требований к системе и степень учета потребностей пользователей;

 возможности поставщика выполнить заданные требования;

 соответствие выбранных процессов ЖЦ ПО условиям договора;

 адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;

 соответствие проектных спецификаций ПО заданным требованиям;

 корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;

 соответствие кода проектным спецификациям и требованиям;

 тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

 корректность интеграции компонентов ПО в систему;

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

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

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

 подготовительную работу;

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

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

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

 подготовительную работу;

 оценку управления проектом;

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

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

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

 подготовительную работу;

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

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

 подготовительную работу;

 разрешение проблем.

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

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

 инициирование и определение области управления;

 планирование;

 выполнение и контроль;

 проверку и оценку;

 завершение.

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

Планирование подразумевает выполнение как минимум, следующих задач:

 составление графиков выполнения работ;

 оценку затрат;

 выделение требуемых ресурсов;

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

 оценку рисков, связанных с конкретными задачами;

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

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

 подготовительную работу;

 создание инфраструктуры;

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

 создание процесса;

 оценку процесса;

 усовершенствование процесса.

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

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

 подготовительную работу;

 разработку учебных материалов;

 реализацию плана обучения.

Вопросы адаптации общей структуры ЖЦ ПС (программных средств), описанной в ГОСТ Р ИСО/МЭК 12207, являются ключевыми при выборе (построении) модели ЖЦ ПС (автономной или входящей в состав общей модели ЖЦ создаваемой информационной системы) в условиях реализации конкретного проекта.

Соответствие проекта стандарту ГОСТ Р ИСО/МЭК 12207 определяется как реализация в рамках конкретного проекта модели ЖЦ ПС, которая построена на основе выбора из данного стандарта соответствующих процессов, работ и задач. Выполнение процесса или работы считается завершенным, если решены все требуемые в них задачи в соответствии с предварительно установленными в договорной документации проекта (договоре или контракте) критериями и требованиями.

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

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

Процессы общей структуры ЖЦ ПС по ГОСТ Р ИСО/ 12207 основаны на двух исходных принципах: модульности и ответственности. Принцип модульности основан на следующих положениях:

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

 процессы свободно соединены между собой. Количество интерфейсов между процессорами сведено к минимуму.

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

 процесс должен быть своего рода модулем ЖЦ, т.е. каждый процесс должен выполнять только собственную функцию в ЖЦ, а интерфейсы между двумя любыми процессами должны быть минимальны;

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

 если процесс А вызван процессом В и только процессом В, тогда А принадлежит В;

 если работа или задача вызваны более чем одним процессом, тогда они сами становятся процессом;

 должна быть возможность для проверки любого процесса, работы и задачи ЖЦ;

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

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

Безусловно, применение ГОСТ Р ИСОМЭК 12207 требует от соответствующего субъекта определенных усилий по его адаптации к условиям реализации конкретных проектов. Кроме того, требуются усилия по его увязке с конкретными методикам разработки систем и другими стандартами.

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

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

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

Модели жизненного цикла ПО

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

К настоящему времени наибольшее распространение получи­ли следующие две основные модели ЖЦ ПО: каскадная модель (1970-1985 гг.) и спиральная модель (1986-1990 гг.). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии. Возвратов на пройденные стадии не предусматривается.

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

Рис. 8. Каскадная модель разработки ПО

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

 производительности;

 объема занимаемой памяти и др.

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

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

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

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

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

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

Это объясняется двумя причинами:

 пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;

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

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

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

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

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

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

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

Рис. 9. Реальный процесс создания ПО каскадным способом

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 10).

Рис. 10. Спиральная модель разработки ПО

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

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

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

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

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

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

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

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

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

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