Управление жизненным циклом информационной системы

Источники информации по дисциплине «Управление жизненным циклом ИС» 1. Васильев Р.Б., Калянов Г.Н., Левочкина Г.А. Управление развитием информационных систем. Учебное пособие для вузов / Под редакцией Г.Н. Калянова. – 2 изд., стереотип. – М.: Горячая линия – Телеком, 2017. – 376 с.: ил. 2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2–е изд., перераб. и доп. – М.: Финансы и статистика, 2006. – 544 с.: ил. 3. Дегтярев А.В., Вдовин В.А., Ковалев А.М., Кущенков Б.К. Информационные технологии в менеджменте. Учебное пособие. М.: «Доброе слово», 2011. – 152 с. 4. Дегтярев А.В., Оганов В.А., Басков А.О. Экономико-математические и организационные методы в управлении информационным департаментом. – М.: Изд-во МАИ-ПРИНТ, 2009. – 164 с.: ил. 5. Зараменских Е.П. Управление жизненным циклом информационных систем: моно- графия / Е.П. Зараменских. – Новосибирск: Издательство ЦРНС, 2014. – 270 с. 6. Исаев, Георгий Николаевич. Проектирование информационных систем: учеб. пособие. /Г.Н. Исаев. – М.: Издательство «Омега-Л», 2013. – 424 с.: ил., табл. 6. Ковалев А.М., Ковалев В.А. Основы управления проектами в области информационных технологий: Учеб. пособие. – М.: Доброе слово, 2007 – 102 с.: ил. 8. Костров А.В., Александров Д.В. Уроки информационного менеджмента. Практикум: Учеб. пособие. – М.: Финансы и статистика, 2005. – 304 с.: ил. 9. Ньюэл Майкл В. Управление проектами для профессионалов. Руководство к сдаче сертификационных экзаменов / Пер. с англ. М.: Кудиц-Пресс, 2008. – 416 с. 10. Сатунина А.Е. Управление проектом корпоративной информационной системы предприятия: учеб. пособие. / А.Е. Сатунина, Л.А. Сысоева/ – М.: Финансы и статистика; ИНФРА-М, 2009. – 352 с.: ил. 11. Товб А.С., Ципес Г.Л. Управление проектами: стандарты, методы, опыт. – М.: ЗАО «Олимп-Бизнес», 2003. – 240 с.: ил. 12. Троцкий М., Груча Б., Огонек К. Управление проектами. Пер. с польского. – М.: Финансы и статистика, 2011. – 304 с.: ил. 13. Шафер, Дональд, Ф., Фатрелл, Роберт, Т., Шафер, Линда, И. Управление программными проектами: достижение оптимального качества при минимуме затрат. Пер. с англ. – М.: Издательский дом «Вильямс», 2005. – 1136 с.: ил. Рабочий конспект лекций по дисциплине «Управление жизненным циклом ИС» 1. Жизненный цикл информационной системы: определение и основные понятия Жизненный цикл (ЖЦ) информационной системы (ИС) – непрерывный процесс, началом которого становится момент принятия решения о необходимости системы, а завершением – ее изъятие из эксплуатации. Средняя продолжительность ЖЦ ИС составляет в настоящее время 15 лет. Первоначально специалисты в области информационных технологий вполне справедливо решили, что важнейшей составной частью ИС является программное обеспечение (ПО). Следствием этого явилось известное отождествление ЖЦ ПО и ЖЦ ИС, хотя понятие «информационная система» существенно шире, чем понятие «программное обеспечение». Как бы там ни было, именно вопросы ЖЦ ПО к настоящему времени тщательно «отшлифованы» в следующих международных стандартах: - ISO/IEC 12207:2008 Information technology – Software life cycle processes (Информационные технологии. Процессы жизненного цикла программного обеспечения)1. Российский аналог ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; - ISO/IEC TR 15271:1998 Information technology – Guide for ISO/IEC 12207 (Software Life Cycle Processes) (Информационная технология. Руководство по применению ISO/IEC 12207 (Процессы жизненного цикла программных средств)). Российский аналог ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)»; - ISO/IEC TR 16326:1999 Software engineering – Guide for the application of ISO/IEC 12207 to project management (Программная инженерия. Руководство по применению ISO/IEC 12207 при управлении проектом). Российский аналог ГОСТ Р ИСО/МЭК ТО 16326-2002 «Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом». Несколько позже регламентации по вопросам ЖЦ распространилась на ИС в целом, что связано с появлением следующих стандартов: - ISO/IEC 15288:2005 Systems engineering. System life cycle processes (Системотехника. Процессы жизненного цикла системы). Российский аналог: ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем; - ISO/IEC/IEEE 16326:2009 «Systems and software engineering - Life cycle processes - Project management», IDT (Системная и программная инженерия. Процессы жизненного цикла. Управление проектом). Российский аналог: ГОСТ Р 57101-2016/ISO/IEC/IEEE 16326:2009 Системная и программная инженерия. Процессы жизненного цикла. Управление проектом. Стандарты ЖЦ ИС не отменили стандарты ЖЦ ПО, а уточнили и дополнили их. В лекциях будет использована терминология как тех, так и других. В связи с указанными особенностями подходов к ЖЦ представляет интерес концепция уровней ЖЦ, которая была предложена в 2005 г. Скоттом Амблером, автором практик гибкого моделирования Agile Modeling и концепции Enterprise Unified Process (см. рис.1.1). Логика рассуждений в данном случае следующая: жизненный цикл бизнеса включает всю деятельность ИТ-департамента, в том числе по разработке, развертыванию, поддержке и сопровождению информационных систем, частью которых является программное обеспечение. Рис. 1.1. Концепция уровней жизненного цикла Названными выше международными стандартами и их отечественными аналогами устанавливается, что для осуществления ЖЦ ИС (ПО) нужно обеспечить определенного набора процессов. Процесс (process), согласно стандарту ISO/IEC 12207:2008, представляет собой совокупность взаимосвязанных или взаимодействующих видов деятельности (действий), преобразующих некоторые входные данные в выходные. В частном случае процесс может представлять собой какой-либо один вид деятельности. В свою очередь, вид деятельности (действие) можно рассматривать как некоторый набор задач. На рис. 1.2 представлены основные группы процессов жизненного цикла программных средств (ПС) согласно стандарту ISO/IEC 12207:2008. Они подразделены на два больших раздела. В разделе стандарта, закодированном под номером 6, представлены процессы работы с программной системой в целом. Система здесь понимается как некоторый комплекс взаимосвязанных программ. Раздел 7 стандарта содержит специальные процессы работы с программным продуктом или услугой, которые являются некоторым элементом более крупной программной системы. Если какие-либо процессы этих двух разделов одинаковы по своему содержанию (рекурсивны), то они излагаются в стандарте один раз с указанием ссылки. Всего стандартом предусмотрены 7 групп процессов ЖЦ ПО: • процессы соглашения ‒ два процесса; • процессы организационного обеспечения проекта ‒ пять процессов; • процессы проекта ‒ семь процессов; • технические процессы ‒ одиннадцать процессов; • процессы реализации программных средств ‒ семь процессов; • процессы поддержки программных средств ‒ восемь процессов; • процессы повторного применения программных средств ‒ три процесса. Как указывалось, каждый процесс может включать ряд действий. Например, процесс приобретения охватывает следующие действия: 1. Инициирование приобретения. 2. Подготовка заявочных предложений. 3. Подготовка и корректировка договора. 4. Надзор за деятельностью поставщика. 5. Приёмка и завершение работ. Каждое действие может включать ряд задач. Например, подготовка заявочных предложений должна предусматривать: 1. Формирование требований к системе. 2. Формирование списка программных продуктов. 3. Установление условий и соглашений. 4. Описание технических ограничений (среда функционирования системы и т.д.). Рис. 1.2. Группы процессов жизненного цикла ПО в соответствии со стандартом ISO/IEC 12207: 2008 (российский аналог – ГОСТ Р ИСО/МЭК 12207-2010) В Приложении 1 к лекциям приводится фрагмент стандарта, в котором раскрывается содержание и составные части процессов реализации программных средств (код 7.1). Стандарт ISO/IEC 15288:2005 отредактировал подход к определению состава и объединения в группы процессов ЖЦ, поскольку в нем речь идет об ИС в целом, а не только о ПО. В отличие от стандарта ISO/IEC 12207, стандарт ISO/IEC 15288 распространяется на ИС в целом, охватывая такие их элементы, как: «технические средства, программные средства, люди, процессы (например, процесс оценки), процедуры (например, инструкции оператора), основные средства и природные ресурсы. Согласно данному стандарту, любой процесс ЖЦ может быть начат в любой момент, без ограничения порядка использования и последовательности (в том числе, при параллельном выполнении нескольких процессов). Следует также отметить высокий уровень абстракции ISO 15288 в сравнении с ISO 12207, так как данный стандарт не приводит ролей, конечных результатов в виде списка выходных документов, либо же состава работ, лишь оставаясь на уровне концепции. Важная особенность ISO 15288 в том, что использоваться он может как со стороны заказчика, так и со стороны исполнителя. Это достигается благодаря тому, что стандарт содержит четыре основные группы процессов (предприятия, соглашения, проекта и технические – см. рис. 1.3), описывающие соответственно вспомогательные корпоративные процессы, взаимодействие с контрагентами, управление проектом и саму реализацию (создание, применение) системы. Важной положительной чертой стандарта является его связь с бизнес-стороной проекта создания системы за счет групп процессов предприятия и соглашения. Благодаря наличию подобных разделов стандарта появляется связь с соответствующими корпоративными функциями и для бизнеса становится более понятным место процессов ЖЦ ИС в процессах организации в целом. Рис. 1.3. Группы процессов жизненного цикла ИС в соответствии со стандартом ISO/IEC 15288:2005 (российский аналог – ГОСТ Р ИСО/МЭК 15288-2005) Наряду с понятием «процесс ЖЦ ИС (ПО)» стандарты устанавливают два других важных понятия: «модель ЖЦ ИС (ПО)» и «стадия ЖЦ ИС (ПО)». Согласно международному стандарту ISO/IEC 12207: 2008 (и, соответственно, его российскому аналогу ГОСТ Р ИСО/МЭК 12207-2010) модель жизненного цикла (life cycle model) представляет собой структуру (то есть состав и взаимосвязь) процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые служат в качестве общей ссылки для установления связей (то есть определяют способ установления этих связей) и взаимопонимания сторон. В литературе и в ряде других стандартов в качестве синонимов термина «стадия» используются также понятия «этап» и «фаза». В рассматриваемом стандарте указано, что стадии могут перекрываться и/или повторяться циклически в соответствии с областью применения, размером, сложностью системы, потребностью в изменениях и возможностями организации-исполнителя. Для каждой стадии задаются формулировка цели и описание выходов. Стадию можно определить как период в пределах жизненного цикла системы, относящийся к состоянию системного описания или непосредственно к самой системе. При этом, как правило, стадии относятся к периодам значительного продвижения системы и достижения запланированных сроков на протяжении жизненного цикла. Это определение взято уже из стандарта ISO/IEC 15288:2005, который по данным вопросам нисколько не противоречит стандарту ISO/IEC 12207: 2008. Указанные стандарты не требует использования какой-либо конкретной модели жизненного цикла. Однако они требуют, чтобы в каждом проекте определялась подходящая модель жизненного цикла, предпочтительно та, которая уже выбиралась организацией для применения в различных проектах. Стандарт ISO/IEC 12207: 2008 не содержит требований использования какой-либо заданной совокупности стадий и установления конкретных связей между ними и прямо указывает на то, что решение по составу и содержанию фаз жизненного цикла ИС должен принимать разработчик. Однако рекомендации (именно рекомендации) по данным вопросам мы можем найти в других стандартах (см. таблицу 1.1). 2. Основные модели жизненного цикла ИС (IT проекта) В международном стандарте ISO/IEC TR 15271:1998 (Руководство по применению ISO/IEC 12207) и его отечественном аналоге ГОСТ Р ИСО/МЭК ТО 15271-2002, причем в разделах, которые носят иллюстративный или справочный характер, рассматриваются три модели жизненного цикла ИС, которые трактуются разработчиками стандарта как фундаментальные, а именно каскадная, инкрементная и эволюционная модели. Остальные модели жизненного цикла представляют их модификацию или компиляцию. Ниже дается краткое описание наиболее распространенных моделей жизненного цикла систем в области информационных технологий. Каскадная модель (рис 2.1) предусматривает последовательную организацию проектных работ. В этом случае разработка системы разбивается на этапы, причем переход с одного этапа на следующий происходит только после того, как будут полностью завершены работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка на следующем этапе могла быть продолжена другой командой разработчиков. В качестве этапов разработки системы при каскадной модели в общем случае принимаются стадии жизненного цикла системы (см. блоки на рис. 2.1) или их часть, ограниченная целями и задачами проектных работ. Понятия этапа разработки и стадии жизненного цикла системы в этой модели отождествляются. Основными достоинствами каскадной модели жизненного цикла системы являются: - на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах разрабатывается полный комплект пользовательской документации, охватывающей все предусмотренные стандартом виды обеспечения системы: организационное, методическое, информационное, программное, аппаратное; - выполняемые в логической последовательности этапы позволяют достаточно точно планировать сроки завершения проекта и соответствующие затраты; - каскадная модель имеет универсальный характер и достаточно широко распространенна за пределами области информационных технологий. Она, как правило, хорошо известна потребителям, заказчикам, не имеющим отношение к разработке и эксплуатации ИС и ПО: велика вероятность того, что заказчик мог ранее встречаться с этой моделью при реализации инновационных проектов, проектов капитального строительства и т.д. Таблица 1.1 Стадии жизненного цикла информационной системы в соответствие со стандартами ISO/IEC TR 15271:1998 (ГОСТ Р ИСО/МЭК ТО 15271-2002) ISO/IEC 15288:2005 (ГОСТ Р ИСО/МЭК 12207-2010) ГОСТ 34.601-90 Раздел 8 Приложение C a) Определение потребностей. b) Исследование и описание основных концепций. c) Демонстрация и аттестация основных концепций. d) Проектирование и разработка. e) Создание и производство. f) Распространение и продажа. g) Эксплуатация. h) Сопровождение и поддержка. i) Снятие с эксплуатации (утилизация). 1) Установление потребностей пользователя. 2) Определение требований. 3) Проектирование системы. 4) Изготовление системы. 5) Испытание. 6) Корректировка. 7) Поставка или использование. a) стадия замысла; b) стадия разработки; c) стадия производства; d) стадия применения; e) стадия поддержки применения; f) стадия прекращения применения и списания. 1) Формирование требований к автоматизированной системе. 2) Разработка концепции автоматизированной системы. 3) Техническое задание. 4) Эскизный проект. 5) Технический проект. 6) Рабочая документация (по программам). 7) Ввод в действие. 8) Сопровождение автоматизированной системы. Рис. 2.1. Каскадная модель жизненного цикла разработки ИС Основными недостатками каскадной модели являются: - существенная задержка в получении результатов, длительный цикл проектирования; - ошибки и недостатки на любом из этапов выясняются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие этапы, их итеративного повторения; - сложность распараллеливания работ по проекту для сокращения цикла проектирования; - чрезмерная информационная насыщенность каждого из этапов; - высокий уровень риска инвестирования в проект в связи с возможностью зацикливания проектных работ из-за итеративного исправления ошибок и внесения изменений. При использовании каскадной модели для разработки сложных систем практически неизбежным является возврат к предыдущим стадиям и уточнение или пересмотр ранее принятых решений. В результате реальный процесс разработки системы (рис. 2.2) заметно отличается от исходной канонической каскадной модели (рис. 2.1). Изображенную на рис. 2.2 схему часто рассматривают в качестве самостоятельной модели жизненного цикла системы, так называемой каскадной модели с промежуточным контролем, в которой заранее планируемые межстадийные корректировки обеспечивают большую надежность результатов проектирования по сравнению с каскадной моделью, хотя и могут увеличить период разработки. Еще одно отличие реального процесса разработки системы, а, следовательно, и каскадной модели с промежуточным контролем от каскадной модели заключается в том, что в целях сокращения сроков системной разработки допускается начинать следующую стадию жизненного цикла (например, кодирование) до завершения предыдущей (например, проектирования). В качестве области применения каскадной модели целесообразно рассматривать: - разработку несложных систем; - разработку сложных систем в условиях, когда требования к разработке и последующей реализации системы максимально четко определены на первой стадии проектных работ, понятны разработчикам, заказчикам и пользователям и не будут меняться в процессе проектирования. Это обычно достигается в том случае, если: 1) разработка осуществляется для однотипного программного продукта (системы); 2) проводится разработка и выпуск новой версии программного продукта (системы); 3) осуществляется перенос используемого программного продукта (системы) на новую техническую или программную платформу. Рис. 2.2. Реальный процесс разработки ИС (каскадная модель с промежуточным контролем) Эволюционная модель жизненного цикла применяется в двух основных разновидностях. Первую разновидность будем называть спиральной моделью (ориентирована на презентацию результатов разработки перед заказчиком). Вторая разновидность получила название структурной эволюционной модели быстрого прототипирования (ориентирована на активное участие в разработке системы пользователя). Спиральная модель жизненного цикла предполагает постоянно повторяющийся итерационный процесс разработки системы (рис. 2.3). Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения работ на текущем этапе – недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации – как можно быстрее создать работоспособный продукт, который можно показать заказчику и пользователям системы. Таким образом, существенно упрощается процесс внесения в проект уточнений и дополнений. При использовании спиральной модели понятия стадии жизненного цикла системы и этапа ее разработки не совпадают. Каждый этап проектирования интерпретируется как виток спирали спиральной модели или, в прикладном аспекте, как очередная версия системы. При этом на различных этапах разработки ИС полностью или частично повторяются формально одни и те же стадии ее жизненного цикла, отличающиеся содержанием выполняемых работ. Рис. 2.3. Спиральная модель жизненного цикла ИС Основные преимущества применения спиральной модели: - упрощение внесения изменений в проект при изменении требований заказчика и по другим причинам; - постепенная интеграция отдельных элементов системы в единое целое, что уменьшает количество возникающих проблем в связи с относительно небольшим количеством единовременно интегрируемых элементов; - уменьшение уровня рисков инвестирования в проект; - возможность получения более надежной и устойчивой системы в связи с устранением ошибок и слабых мест на каждой итерации; - возможность совершенствования процесса разработки системы на каждой итерации по сравнению с предыдущей на основе проводимого в конце итерации анализа. Основная проблема применения спиральной модели – определение момента времени перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов проектирования системы. Иначе процесс разработки превратится в бесконечное совершенствование сделанного ранее. Иными словами, завершение итерации и ее отдельного этапа должны проводиться в сроки, строго соответствующие плану работ, даже если не вся запланированная работа закончена. Возможный вариант состава и последовательности этапов разработки системы в случае применения спиральной модели жизненного цикла на примере процесса создания сложного программного продукта представлен в табл. 2.1. В приведенном примере принципиальное значение имеют этапы проектирования, связанные с формированием альфа- и бета-версий программного продукта. Точные определения этих состояний разработки ПО от фирмы к фирме меняются. В данном случае альфа-версия программы – это завершенный в логическом аспекте продукт, содержащий большое количество ошибок, в то время как бета-версия – это продукт, уже почти готовый к выпуску. Таблица 2.1 Этапы разработки ПО при использовании спиральной модели Этапы разработки Этапы (подэтапы) жизненного цикла, отдельные работы Проектирование продукта Разработка предложений Разработка требований к продукту Заключение контракта Разработка внешней структуры Разработка внутренней структуры Разработка спецификации Моделирование Реализация базовых функций Постановка задачи Проектирование Кодирование Тестирование модуля (как «стеклянного ящика») Разработка версии «Почти альфа» Постановка задачи Проектирование Кодирование Исправление ошибок Тестирование модулей Разработка Альфа - версии Кодирование Тестирование модулей Доработка проектных документов Исправление ошибок Написание драйверов устройств Начало разработки контрольного примера Разработка версии «Пре-бета» Исправление ошибок Разработка Бета - версии Завершение реализации функций Исправление ошибок Пересмотр пользовательского интерфейса Написание установочных утилит Работа над драйверами устройств Разработка примеров Подготовка дисков для бета-тестировщиков Замораживание пользовательского интерфейса Осуществление изменений, не отражающихся на пользовательском интерфейсе Исправление ошибок Работа над повышением производительности программы Формирование окончательного варианта данных Формирование окончательного варианта программы установки Формирование окончательной конфигурации дисков Подготовка к финальному тестированию Исправление ошибок Последняя проверка целостности Исправление ошибок Кодирование демонстрационных материалов Архивация исходного кода Выпуск продукта Тестирование программного продукта заказчиком Оформление акта приемки-сдачи системы Общее количество последовательно улучшаемых версий программного продукта в данном примере достигает семи: почти альфа; альфа; пре-бета; бета; версия, сформированная после замораживания пользовательского интерфейса; версия для финального тестирования; готовый продукт. Промежуточные версии могут быть продемонстрированы пользователям и заказчику, которые при этом, как правило, вносят предложения по усовершенствованию системы. Следует подчеркнуть, что при использовании спиральной модели жизненного цикла разбиение разработки на этапы вовсе не означает, что все поставленные перед разработчиками задачи на каждом витке спирали решаются последовательно, одна за другой. Как раз наоборот, многие работы выполняются параллельно, например, в то время как одни части программы только пишутся, другие уже могут тестироваться и описываться в виде руководства пользователя. В одно и то же время может выполняться и разработка требований к продукту и написание спецификации, и создание прототипа. В качестве области применения спиральной модели жизненного цикла системы целесообразно рассматривать выполнение сложных проектов с длительным циклом разработки, когда для разработчика и для заказчика имеет принципиальное значение в короткое время осуществить демонстрацию возможностей и качества системы. Как правило, требования к разработке такой системы на начальном этапе проектных работ в полном объеме определить сложно. С этой целью разрабатываются недоработанные до конца версии системы, которые, тем не менее, могут быть продемонстрированы заказчику. Вся последующая разработка сводится к созданию улучшенных версий системы с учетом замечания заказчика и пользователей. Структурная эволюционная модель быстрого прототипирования (рис.2.4) сохраняет некоторые свойства спиральной модели. Рис. 2.4. Структурная эволюционная модель быстрого прототипирования. Термин «прототип», как и в случае канонической спиральной модели, означает недоработанную до конца версию ИС. Однако эта версия представляется не только для демонстрации возможности системы, но, в первую очередь, для ее опробования пользователями и последующей совместной доработки пользователями и разработчиками. Причина «изобретения» данной модели жизненного цикла заключается в том, что во многих случаях значительные трудности для пользователей, заказчика и разработчиков представляет формировании полного набора комплексных требований к системе на начальном этапе ее разработки. Использование модели прототипирования предполагает, что окончательный набор требований будет оперативно сформирован коллективом пользователей и разработчиков в процессе системной разработки. На рис. 2.4 в эллипсе выделяются четыре круга. Начало жизненного цикла системной разработки помещено в центр эллипса в так называемый первый круг. Здесь пользователи и разработчики совместно формируют некоторый предварительный план проекта, руководствуясь предварительными требованиями. В результате создается документ, описывающий в общих чертах разрабатываемую систему и процесс ее создания. На втором круге разрабатывается исходный прототип, заведомо не учитывающий все требования к системе, тем более, что некоторые требования могут быть сформулированы только на основе апробации системы пользователями. С этой целью производится экспресс-опрос пользователей и формирование более детализированного перечня требований по сравнению с требованиями, сформулированными на первом круге, проектируется и создается база данных системы, пользовательский интерфейс, прикладные программы, названные на рисунке «функциями». На третьем круге осуществляется итерационный цикл быстрого прототипирования. Разработчики демонстрируют пользователям прототип, а пользователи оценивают его функционирование в условиях конкретной организации. Естественно, что прототип должен формироваться на той программной и технической платформе, на которой будет функционировать система. После опробования прототипа пользователями определяются проблемы, над устранением которых работают совместно пользователи и разработчики. Команда разработчиков продолжает выполнять процесс совершенствования прототипа до тех пор, пока пользователи не согласятся, что прототип в точности отражает системные требования. На четвертом круге осуществляется формирование окончательной версии системы. Созданный на третьем круге прототип заменяется полнофункциональной системой. Вначале заказчиком официально утверждается версия прототипа, согласованная пользователями и разработчиками. Затем проводится окончательная доработка проекта (на схеме она обозначена как производная разработка). Основное ее содержание – подготовить полный комплект необходимой сопроводительной документации, поскольку в итерационном цикле быстрого прототипирования это сделать невозможно. При необходимости осуществляется подгонка системы под реальные условия предприятия, для которого система создается. В качестве заключительного этапа предусматривается эксплуатация и сопровождение системы, которая допускает ее усовершенствование. Преимущества модели быстрого прототипирования: • конечный пользователь может сформировать системные требования в процессе разработки; • исходя из реакции пользователя и заказчика на эксплуатацию прототипа разработчики оперативно получают сведения о возникающих проблемах, что сводит к минимуму отклонения от требований; • возможность полноты и системности в формировании требований; • в процессе разработки можно внести новые, и даже неожиданные, требования в связи с тем, что реальное функционирование системы и объекта управления может отличаться от первоначальной концептуальной модели; • при использовании данной модели имеет место видимые признаки прогресса в разработке системы, благодаря чему заказчик чувствует себя уверенно. Недостатки модели: • не все заказчики могут согласиться с применением этой модели, поскольку разрабатываемая система имеет в данном случае репутацию как система «разработанная на скорую руку»; • прототипы обычно страдают недостатком сопроводительной документации. Если процесс разработки по какой-то причине прервется, то система будет недоработана не только в функциональном аспекте, но и в аспекте документирования; • при использовании модели прототипирования решение сложных проблем может отодвигаться на будущее. В результате сформированная система может не оправдать возлагаемых на нее заказчиком надежд; • возможность недооценки разработчиками 4 круга, т.е. процедур окончательной разработки полнофункциональной системы. Очень часто система в полной мере не обеспечивается документацией. Область применения: • требования заранее неизвестны в полном объеме; • требования непостоянны, существенная вероятность неверно сформулированных требований; • выполняется новая не имеющая аналогов разработка; • система имеет повышенную степень сложности. Название инкрементной модели жизненного цикла ИС происходит от понятия «инкремент» (от англ. – increment) – возрастание, увеличение, прирост. Инкрементная разработка представляет собой процесс частичной реализации всей системы в целом и медленного наращивания ее функциональных возможностей. Таким образом, инкремент в данном случае означает часть системы, внедрение которой обеспечивает наращивание ее функциональных возможностей и повышение эффективности. Обычно имеется в виду последовательная разработка и добавление в ИС новых функциональных подсистем (комплексов задач). При этом предполагается, что на первом этапе системной разработки выполняется конструирование системы в целом, в том числе определяется состав функций и инкрементов, последовательность их разработки и внедрения. В дальнейшем осуществляется последовательная разработка и внедрение инкрементов, причем каждый инкремент проходит через такие фазы жизненного цикла, как детализированная разработка проекта (детальное проектирование), кодирование, тестирование, интеграция, внедрение, эксплуатация и сопровождение. Графическая интерпретация одной из версий инкрементной модели жизненного цикла ИС показана на рис. 2.5. Начальная стадия системной разработки показана в левом верхнем углу и специально не выделена. Последовательно реализуемые инкременты обведены большими прямоугольниками. На рис. 2.5 тестирование рассредоточено по нескольким уровням, как это принято в V–образной модели. Вопреки утверждению разработчиков стандартов ISO/IEC 12207: 2008 и ГОСТ Р ИСО/МЭК 12207-2010 можно все же утверждать, что в данном случае инкрементная модель представляет собой сложную разветвленную каскадную модель. При этом инкрементные каскады выполнены по схеме V–образной модели, которая является частным случаем каскадной модели (см. ниже). На рис. 2.6 представлена графическая интерпретация другой версии инкрементной модели жизненного цикла ИС, в которой каждый из инкрементов реализуется в соответствии со спиральной моделью жизненного цикла системы. Модель в целом представляет собой комбинацию каскадной и спиральных моделей. Особенность инкрементной модели заключается в том, что внедрение каждого последующего инкремента означает его интеграцию с уже существующей системой. Неизбежное следствие – изменение первоначального проекта общей части системы, уточнение ее концепции. Рис. 2.5. Инкрементная модель (версия 1) Рис. 2.6. Инкрементная модель (версия 2) Преимущества инкрементной модели: • нет необходимости в единовременных крупных вложениях в систему и в значительных ресурсах подразделения-исполнителя; • при разработке каждого последующего инкремента может быть учтен накопленный опыт создания предыдущего инкремента; • имеется возможность более подробно изучить потребности клиента; • заказчик и пользователь постепенно привыкают к новой технологии управления объектом. Недостатки: - создаются условия для затягивания разработки на большой срок, осуществления ее по мере выделения средств; - можно ошибиться в определении состава инкрементов и порядка их реализации; - может возникнуть тенденция к оттягиванию решений трудных проблем на будущее. Область применения. Модель выбирается для проектов, на выполнение которых предусматривается большой период времени. Это достаточно удобно для ИТ-подразделения предприятия, которому поручили системную разработку «своими силами». В то же время важно подчеркнуть, что ИТ-подразделение предприятия может при необходимости осуществить системную разработку на базе любой другой модели жизненного цикла ИС. V–образная модель жизненного цикла ориентирована на усиленное осуществление процедур тестирования программного продукта (ПП) или информационной системы (ИС). С этой целью планирование тестовых испытаний, их проработка осуществляется еще до начала кодирования практически на всех предыдущих этапах жизненного цикла (рис. 2.7). Из рисунка следует, что эта модель является разновидностью каскадной модели. Пунктирные линии показывают взаимосвязь между фазами жизненного цикла по поводу организации тестирования. Содержание фаз тестирования: • Модульное тестирование: выполняется проверка каждого закодированного модуля программы на наличие ошибок. • Интеграция и тестирование: тестирование после установки взаимосвязей между группами ранее поэлементно испытанных модулей с целью подтверждения того, что эти группы работают так же хорошо, как и модули, испытанные независимо друг от друга на предыдущей фазе. • Системное и приемочное тестирования: проверка функционирования программной системы в целом; при этом приемочное тестирование осуществляется в аппаратной и программной среде пользователя. Рис. 2.7. V-образная модель жизненного цикла разработки ИС • В блоке «Производство, эксплуатация и сопровождение» на начальной стадии его реализации заказчики и пользователь могут провести независимое от разработчика приемочное испытание, которое позволяет им протестировать функциональные возможности системы на соответствие исходным требованиям. Существуют много различных технологий тестирования. При тестировании по методу «черного ящика» (black box) программа рассматривается как объект, внутренняя структура которого не известна. Тестировщик вводит данные и анализирует результат, но как именно работает программа, он не знает. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам. Интерес для него представляют, прежде всего, те значения каждого класса входных данных, которые с наибольшей вероятностью могут привести к ошибкам тестируемой программы. Этот метод тестирования является преобладающим на рассматриваемом этапе жизненного цикла программного продукта. При тестировании по методу «стеклянного ящика» (glass box или в некоторых источниках white box – «белый ящик») ситуация совершенно иная. Тестировщик (как правило, это программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. Такое тестирование рассматривается как составная часть процесса программирования. Программисты выполняют эту работу постоянно, они тестируют каждый модуль после его написания, а затем еще раз после его интеграции в систему. Тестировщик «черного ящика» не изучает исходный код программы – он исследует ее извне, работая с ней, как это будет делать пользователь. И так же, как исследование программы изнутри позволяет выявить проблемы и критические точки, которые невидно извне, так и тестировщик «черного ящика» выявляет ошибки и недостатки, которые программист упускает. Существуют различные концепции тестирования «черного» и «стеклянного» ящиков. В частности, структурное тестирование является одним из видов тестирования «стеклянного ящика». Его главной идеей является правильный выбор тестируемого программного пути. В противоположность ему ставится функциональное тестирование, где каждая функция программы тестируется путем ввода входных данных и анализа выходных данных. При этом внутренняя структура программы учитывается очень редко. Довольно специфическим вариантом тестирования является псевдоотладка: в программу намеренно вносятся ошибки, и по количеству найденных ошибок определяется эффективность проводимых тестов. Существуют и другие виды тестирования: регрессионное, стабильности и целостности, бета-тестирование, на соответствие стандартам, производительности, нагрузочное, адаптационное. Разработаны также различные средства программного обеспечения процедуры тестирования. Не следует стремиться к существенной экономии времени и средств на разработку системы за счет тестирования, поскольку выпуск продукта с ошибками, в конечном счете, обойдется дороже. Преимущества V-образной модели: • 1) Все преимущества каскадной модели; • 2) Создание условий для повышения качества ПП за счет повышенного внимания к тестированию, верификации, аудиту. Недостатки: • Такие же, как и у каскадной модели. Область применения: те же области, которые характерны для каскадной модели. V–образная модель выбирается для систем, которые требуют повышенной надежности. Поэтому область ее применения можно дополнить АСУТП – автоматизированными системами управления технологическими процессами. Модель быстрой разработки приложений (RAD) начала применяться в 80 – х годах прошлого века в компании IBM как альтернатива каскадной модели. По этой причине первоначально она и была разновидностью каскадной модели. Основные особенности этой модели: • пользователь задействован на всех фазах жизненного цикла разработки; • обязательность применения специфических CASE – средств для ускорения разработки; • разработка должна осуществляться в короткое время (по данным американским источников – за 60 дней, по данным отечественных источников – за 90 дней); • в качестве средств ускорения проектирования могут использоваться также заимствованные модули из других систем, сокращенный состав этапов жизненного цикла и некоторые организационные мероприятия (например, декомпозиция проектных работ по подсистемам и их параллельное выполнение отдельными проектными группами с последующей интеграцией проектных решений). Графическое отображение модели RAD представлено на рис. 2.8. Несмотря на определенную стилизацию изображения достаточно хорошо видно, что это разновидность каскадной модели. Рис. 2.8. Модель быстрой разработки приложений Содержание этапов жизненного цикла рассматриваемой модели: 1 этап - планирование требований. Предусматривает сбор и документирование требований пользователей, которые выполняются на основе рабочего метода, называемого совместным планированием требований. Он заключается в структурном анализе и обсуждении имеющихся коммерческих задач, осуществляемых совместно пользователями и разработчиками. Для сбора требований применяются специальные CASE-средства. 2 этап - пользовательское описание. Пользовательское описание разрабатываемой системы формируется совместно командой пользователей и разработчиков. При этом разрабатывается как модель функционирующей системы, так и модель системы, которая создается. 3 этап - конструирование. Это детализированное проектирование системы, построение программного кода и тестирование. На этой же фазе предполагается демонстрация программного продукта заказчику. Рекомендуется использовать специальные средства генерации программ, например, на основе разработанной структуры данных. 4 этап - перевод на новую систему эксплуатации. Осуществляются приемочные испытания, установка системы у заказчика, обучение пользователей. Обучение пользователей сводится к минимуму, поскольку они участвуют в разработке, начиная с первого этапа. Преимущества модели RAD: • возможность обеспечения короткого цикла разработки; • меньшее количество специалистов-разработчиков по 2 причинам: задействование пользователей, использование специалистов, которым знакома предметная область; • уменьшение затрат на проектирование; • привлечение заказчика на постоянной основе сводит до минимума риск того, что система не будет удовлетворять установленным требованиям. Недостатки: • для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению проектных работ в условиях жестких временных ограничениях. Если в процессе проектирование окажется, что пользователи не смогут принимать в этом процессе участие на постоянной основе, то это сразу негативно скажется на качестве программного продукта и времени его разработки; • квалификация разработчиков должна быть достаточно высокой в том смысле, что они должны в совершенстве владеть применяемыми CASE–средствами. Область применения: • при разработке систем требования, к которым достаточно хорошо известны; • пользователь готов принимать участие в разработке на постоянной основе; • в распоряжении разработчиков имеется уже разработанные модули, которые можно применять в проектировании; • для разработки системы, которая предназначена для концептуальной проверки, является некритической и имеет небольшой размер; • команда разработчиков должна хорошо ориентироваться в предметной области. После появления спиральной модели жизненного цикла ИС появилась возможность реализации модели быстрой разработки приложений как разновидности спиральной модели (рис. 2.9). • • • • • • • • • • • • • • • • Рис. 2.9. Спиральная версия модели быстрой разработки приложений 3. Основные задачи управления жизненным циклом ИС Задачи управления жизненным циклом ИС следует рассматривать как специфические задачи разработки ИС и управления ИТ проектами. Необходимость в их решении возникает в случае принятия решения о создании ИС, то есть о реализации ИТ проекта (в том числе проекта разработки и внедрения ИС, проекта поставки и адаптации ИС и т.п.). Специфика этих задач заключается в том, что они «настраивают» трехмерное пространство управления проектами (см. рис. 3.1). В частности, состав и содержание указанных по горизонтальной оси этапов разработки ИС зависит от выбранной (разработанной) модели ЖЦ ИС, состава стадий ЖЦ ИС, отобранных для каждой стадии процессов, действий и задач ЖЦ ИС. Рассмотрим данную группу задач более подробно. 1) Выбор модели жизненного цикла ИС из числа наиболее распространенных (например тех, которые рассматривались выше в разделе 2). Решению этой задачи может помочь таблица 3.1. Вначале необходимо ответить на каждый вопрос таблицы исходя из условий разработки ИС (отсутствие соответствующей графы можно рассматривать как относительный недостаток таблицы). При совпадении ответа с бинарной характеристикой модели ЖЦ ИС («да» или «нет») в соответствующей клетке проставляется «1», при несовпадении – «0». Полученная сумма нулей и единиц по каждой модели жизненного цикла определит приоритет выбора модели ЖЦ в данной ситуации реализации ИТ проекта. При выполнении практического задания (лабораторной работы) по дисциплине «Управление жизненным циклом ИС» количество условий проектирования в зависимости от варианта задания колеблется от 1 до 3. В этом случае задача решается без таблицы на основе изучения характеристик моделей ЖЦ и соответствующих логических выводов. Рис. 3.1. Пространство процессов управления Таблица 3.1 Таблица для выбора модели ЖЦ ИС Вопросы Каскадная V-образная Прототип Спиральная RAD Инкремент-ная 1 2 3 4 5 6 7 Выбор основных требований Являются ли требования легко определимыми, хорошо известными? ДА ДА НЕТ НЕТ ДА НЕТ Могут ли требования заранее определены в цикле? ДА ДА НЕТ НЕТ ДА ДА Часто ли будут изменяться требования в цикле? НЕТ НЕТ ДА ДА НЕТ НЕТ Нужно ли демонстрировать требования с целью определения? НЕТ НЕТ ДА ДА ДА НЕТ Требуется ли демонстрация возможностей, проверка концепций? НЕТ НЕТ ДА ДА ДА НЕТ 1 2 3 4 5 6 7 Будут ли отражаться сложные системы? НЕТ НЕТ ДА ДА НЕТ ДА Обладает ли требования функциональными свойствами на ранних этапах? НЕТ НЕТ ДА ДА ДА ДА Команда разработчиков Является ли проблемная предметная область проекта новой для большинства разработчиков? НЕТ НЕТ ДА ДА НЕТ НЕТ Является ли технология новой для большинства разработчиков? ДА ДА НЕТ ДА НЕТ ДА Являются ли инструменты, используемые в разработке новыми для большинства разработчиков? ДА ДА НЕТ ДА НЕТ НЕТ Изменяются ли роли участников во время ЖЦ? НЕТ НЕТ ДА ДА НЕТ ДА Можно ли пройти обучение? НЕТ ДА НЕТ НЕТ ДА ДА Является ли структура более значимой, чем гибкость? ДА ДА НЕТ НЕТ НЕТ ДА Будет ли менеджер отслеживать прогресс команды? ДА ДА НЕТ ДА НЕТ ДА Важна ли легкость распределения ресурсов? ДА ДА НЕТ НЕТ ДА ДА Приемлет ли команда равноправные обзоры и инспекции, менеджмент? ДА ДА ДА ДА НЕТ ДА Коллектив пользователей Будут ли присутствовать пользователи? ДА ДА НЕТ ДА НЕТ ДА Будут ли пользователи ознакомлены с определением системы? НЕТ НЕТ ДА ДА НЕТ ДА Будут ли пользователи ознакомлены с предметной областью? НЕТ НЕТ ДА НЕТ ДА ДА Будут ли пользователи вовлечены во все стадии ЖЦ? НЕТ НЕТ ДА НЕТ ДА НЕТ Будут ли пользователи отслеживать ход выполнения проекта? НЕТ НЕТ ДА ДА НЕТ НЕТ Риски Будет ли проект идентифицировать новое направление для организации? НЕТ НЕТ ДА ДА НЕТ ДА Имеет ли смысл системная интеграция? НЕТ ДА ДА ДА ДА ДА Является ли расширением старой системы? НЕТ ДА НЕТ НЕТ ДА ДА Стабильное финансирование на всем ЖЦ? ДА ДА ДА НЕТ ДА НЕТ Длительная эксплуатация продукта в организации? ДА ДА НЕТ ДА НЕТ ДА Должна ли быть высокая степень надежности? НЕТ ДА НЕТ ДА НЕТ ДА Будет ли система меняться в условии предвидимых методов на этапе эксплуатирования? НЕТ НЕТ ДА ДА НЕТ ДА Является ли график ограниченным? НЕТ НЕТ ДА ДА ДА ДА Являются ли прозрачными интерфейсные модули? ДА ДА НЕТ НЕТ НЕТ ДА Доступны ли для повторного пользования компоненты? НЕТ НЕТ ДА ДА ДА НЕТ Является ли доступным использование ресурсов? НЕТ НЕТ ДА ДА НЕТ НЕТ 2) Задача выбора модели ЖЦ ИС может быть преобразована в задачу разработки модели ЖЦ ИС на основе: - корректировки выбранной базовой модели; - на основе компиляции нескольких моделей ЖЦ (обычно одна из них рассматривается как базовая). Подобные ситуации рассматривались в разделе 2 конспекта лекций (см. рис. 2.2, 2.4, 2.6 и 2.9). 3) Определение стадий ЖЦ ИС. Лучше всего воспользоваться рекомендациями стандартов (см. табл. 1.1). В то же время возможно применение состава стадий ЖЦ ИС, который привычен (традиционен) для данной проектной организации в сфере информационных технологий или же характерен для определенного вида моделей ЖЦ. Не следует забывать, что для каскадной модели ЖЦ и производной от нее моделей этапы разработки ИТ проекта совпадают со стадиями ЖЦ разрабатываемой ИС. Определение стадий ЖЦ ИС и этапов разработки ИС представляет в данном случае единый процесс. Для эволюционной модели ЖЦ и производных от нее моделей такого совпадения нет. Этапы жизненного цикла соответствуют последовательно улучшаемым версиям разрабатываемой ИС, которые исполнитель представляет заказчику. В этом случае определение этапов системной разработки дополняет определение стадий ЖЦ ИС и заключается, прежде всего, в определении рационального количества прототипов и требований к ним. 4) Определение процессов, действий и задач для каждой стадии ЖЦ ИС. Это кропотливый и достаточно творческий процесс, поскольку стандарты не дают четких рекомендаций по данному вопросу. Вместе с тем, можно воспользоваться рекомендациями консалтинговых фирм. Так в табл. 3.2 представлены взаимосвязи между стадиями и процессами ЖЦ ПО в соответствии со стандартом ISO/IEC 12207 в его ранней версии 1995 г.2 Таблица 3.2 Взаимосвязи между стадиями и процессами ЖЦ ПО Наименование процессов и действий Стадия Ф П Р Т В Э С 1 2 3 4 5 6 7 8 Основные процессы Приобретение Инициирование приобретения ● Подготовка заявочных предложений ● Подготовка и корректировка договора ● Надзор за деятельностью поставщика ● ● ● ● ● Приемка и завершение работ ● ● Поставка Инициирование поставки ● Подготовка ответа на заявочные предложения ● Подготовка договора ● Планирование ● Выполнение и контроль ● ● ● ● ● Проверка и оценка ● ● ● ● ● Поставка и завершение работ ● ● Разработка Подготовительная работа ● 1 2 3 4 5 6 7 8 Анализ требований к системе ● ● Проектирование архитектуры системы ● Анализ требований к ПО ● ● Проектирование архитектуры ПО ● Детальное проектирование ПО ● Кодирование и тестирование ПО ● Интеграция ПО ● Квалификационное тестирование ПО ● ● Интеграция системы ● Квалификационное тестирование системы ● ● Установка ПО ● Приемка ПО ● Эксплуатация Подготовительная работа ● Эксплуатационное тестирование ● Эксплуатация системы ● Поддержка пользователей ● Сопровождение Подготовительная работа ● ● Анализ проблем и запросов на модификацию ПО ● ● Модификация ПО ● ● Проверка и приемка ● ● Перенос ПО в другую среду ● Снятие ПО с эксплуатации ● Вспомогательные процессы Документирование Подготовительная работа ● ● ● ● ● ● ● Проектирование и разработка ● ● ● ● ● ● ● Выпуск документации ● ● ● ● ● ● ● Сопровождение ● ● ● ● ● ● ● Управление конфигурацией Подготовительная работа ● Идентификация конфигурации ● Контроль конфигурации ● ● ● ● ● Учет состояния конфигурации ● ● ● ● ● Оценка конфигурации ● ● ● ● ● Управление выпуском и поставка ● ● ● Обеспечение качества Подготовительная работа ● ● Обеспечение качества продукта ● ● ● ● ● ● ● Обеспечение качества процесса ● ● ● ● ● ● ● Обеспечение прочих показателей качества системы ● ● ● ● ● ● ● Верификация Подготовительная работа ● ● ● ● ● ● Верификация ● ● ● ● ● ● Аттестация Подготовительная работа ● Аттестация ● ● Совместная оценка Подготовительная работа ● ● ● ● ● ● Оценка управления проектом ● ● ● ● ● ● Техническая оценка ● ● ● ● ● ● 1 2 3 4 5 6 7 8 Аудит Подготовительная работа ● ● ● ● ● ● Аудит ● ● ● ● ● ● Разрешение проблем Подготовительная работа ● ● ● ● ● ● Разрешение проблем ● ● ● ● ● ● Организационные процессы Управление Инициирование и определение области управления ● ● ● ● ● ● Планирование ● ● ● ● ● ● ● Выполнение и контроль ● ● ● ● ● ● ● Проверка и оценка ● ● ● ● ● ● ● Завершение ● ● Создание инфраструктуры Подготовительная работа ● Создание инфраструктуры ● ● Сопровождение инфраструктуры ● ● ● ● ● ● Усовершенствование Создание процесса ● ● Оценка процесса ● ● ● ● ● ● Усовершенствование процесса ● ● ● ● ● Обучение Подготовительная работа ● ● ● ● Разработка учебных материалов ● ● ● ● Реализация плана обучения ● ● ● ● ● ● ● Расшифровка условных обозначений: ЖЦ ПО – жизненный цикл программного обеспечения Ф – формирование требований к ПО; П – проектирование; Р – реализация (программирование, кодирование); Т – тестирование; В – ввод в действие; Э – эксплуатация и сопровождение; С – снятие с эксплуатации. 5) Отслеживание соблюдения результатов решения задач 1 – 4 в ходе реализации ИТ проекта. Решение этой задачи допускает управление изменениями, осуществляемыми в разумных пределах, поскольку ИТ проектирование представляет собой достаточно сложный динамичный процесс. Остальные задачи управления ЖЦ ИС трудно отделить от задач управления ИТ проектами. Можно назвать, в частности, следующие задачи менеджмента ЖЦ ИС в контексте проектной деятельности3: - Управление стейкхолдерами; - Управление человеческими ресурсами; - Управление финансами; - Управление коммуникациями; - Управление качеством; - Управление содержанием; - Управление рисками; - Управление программой проектов. Приложение 1 к лекциям по дисциплине «Управление жизненным циклом ИС» Процессы реализации программных средств в соответствии с международным стандартом ISO/IEC 12207: 2008 (российский аналог – ГОСТ Р ИСО/МЭК 12207-2010) Наименование процесса, его цель, содержание и выходы Наименование вида деятельности Содержание задачи 7.1.1 Процесс реализации программных средств. Цель: создание заданных элементов системы, выполненных в виде программных продуктов или услуг. Содержание: в ходе этого процесса происходит преобразование заданных поведенческих, интерфейсных и производственных ограничений в действия, которые создают системный элемент, выполненный в виде программного продукта или услуги, известный как «программный элемент». Результатом процесса является создание программной составной части, удовлетворяющей как требованиям к архитектурным решениям, что подтверждается посредством верификации*, так и требованиям правообладателей, что подтверждается посредством валидации**. Выходы. В результате успешного осуществления процесса реализации программных средств: a) определяется стратегия реализации; b) определяются ограничения по технологии реализации проекта; c) изготавливается программная составная часть; d) программная составная часть упаковывается и хранится в соответствии с соглашением о ее поставке. Дополнение: процесс реализации программных средств имеет следующие процессы более низкого уровня: - процесс анализа требований к программным средствам; - процесс проектирования архитектуры программных средств; - процесс детального проектирования программных средств; - процесс конструирования программных средств; - процесс комплексирования программных средств; - процесс квалификационного тестирования программных средств. *Верификация (verification) – подтверждение (на основе представления объективных свидетельств) того, что заданные требования полностью выполнены. **Валидация (validation) – подтверждение (на основе представления объективных свидетельств) того, что требования, предназначенные для конкретного использования или применения, выполнены 7.1.1.3.1 Стратегия реализации программных средств. 7.1.1.3.1.1 Если не оговорено в контракте, разработчик должен определить или выбрать модель жизненного цикла, соответствующую области применения, размерам и сложности проекта. Модель жизненного цикла должна содержать стадии, цели и выходы каждой стадии. Виды деятельности и задачи процесса реализации программных средств должны быть выбраны и отражены в модели жизненного цикла. Эти виды деятельности и задачи могут пересекаться или взаимодействовать друг с другом, могут выполняться итеративно или рекурсивно. 7.1.1.3.1.2 Исполнитель должен: a) документировать результаты в соответствии с процессом менеджмента программной документации (см. 7.2.1); b) передавать результаты в процесс менеджмента конфигурации программных средств (см. 7.2.2) и выполнять управление изменениями в соответствии с ним; c) документировать, решать проблемы и снимать несоответствия, найденные в программных продуктах и задачах в соответствии с процессом решения проблем в программных средствах (см. 7.2.8); d) выполнять поддержку процессов в соответствии с контрактом; e) устанавливать базовые линии и соединять элементы конфигурации в сроки, определенные приобретающей стороной и поставщиком. 7.1.1.3.1.3 Исполнитель должен выбирать, адаптировать и применять те стандарты, методы, инструментарий и языки программирования (если не оговорено в контракте), которые документально оформлены, являются подходящими и установлены организацией для выполнения деятельности в рамках процесса реализации программных средств и поддерживающих процессов. 7.1.1.3.1.4 Исполнитель должен разрабатывать планы проведения действий процесса реализации программных средств. Планы должны включать в себя конкретные стандарты, методы, инструментарий, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая безопасность и защиту. При необходимости могут разрабатываться отдельные планы. Эти планы должны документироваться и выполняться. 7.1.1.3.1.5 При разработке или сопровождении программных продуктов могут применяться непоставляемые элементы. Однако должно гарантироваться, что функционирование и сопровождение поставляемых программных продуктов после поставки приобретающей стороне не зависит от таких элементов; другими словами, эти элементы следует также рассматривать как поставляемые. 7.1.2 Процесс анализа требований к программным средствам. Примечание: процесс анализа требований к программным средствам в настоящем стандарте является процессом более низкого уровня, чем процесс реализации программных средств. Цель: установление требований к программным элементам системы. Выходы. В результате успешного осуществления процесса анализа требований к программным средствам: a) определяются требования к программным элементам системы и их интерфейсам; b) требования к программным средствам анализируются на корректность и тестируемость; c) осознается воздействие требований к программным средствам на среду функционирования; d) устанавливается совместимость и прослеживаемость между требованиями к программным средствам и требованиями к системе; e) определяются приоритеты реализации требований к программным средствам; f) требования к программным средствам принимаются и обновляются по мере необходимости; g) оцениваются изменения в требованиях к программным средствам по стоимости, графикам работ и техническим воздействиям; h) требования к программным средствам воплощаются в виде базовых линий* и доводятся до сведения заинтересованных сторон. *Базовая линия (baseline) – спецификация или продукт, которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения 7.1.2.3.1 Анализ требований к программным средствам. 7.1.2.3.1.1 Исполнитель должен установить и документально оформить следующие требования к программным средствам (включая спецификации характеристик качества): a) спецификации функциональных характеристик и возможностей, включая эксплуатационные, физические характеристики и условия окружающей среды, при которых будет применяться программная составная часть; b) внешние интерфейсы к программной составной части; c) квалификационные требования; d) спецификации по безопасности, включая те спецификации, которые относятся к методам функционирования и сопровождения, влиянию окружающей среды и ущербу для персонала; e) спецификации по защите, включая спецификации, связанные с угрозами для чувствительной информации; f) спецификации эргономических факторов, включая спецификации, связанные с ручными операциями, взаимодействием человека с оборудованием, ограничениями по персоналу и областям, требующим концентрации внимания и чувствительным к ошибкам человека и уровню его обученности; g) описание данных и требования к базам данных; h) инсталляция и требования к приемке поставляемого программного продукта в местах функционирования и сопровождения; i) требования к документации пользователя; j) операции пользователя и требования к их выполнению; k) пользовательские требования к сопровождению. Примечание: следует определить приоритет выполнения требований к программным средствам. 7.1.2.3.1.2 Исполнитель должен оценить требования к программным средствам, учитывая критерии, перечисленные ниже (результаты оценок должны быть документально оформлены): a) прослеживаемость к системным требованиям и к системному проекту; b) внешняя согласованность с системными требованиями; с) внутренняя согласованность; d) тестируемость; е) осуществимость программного проекта; f) осуществимость функционирования и сопровождения. 7.1.2.3.1.3 Исполнитель должен проводить ревизии* в соответствии с 7.2.6. Примечание: вслед за успешными оценкой и ревизией следует принимать требования к программным средствам, закреплять их в базовой линии и сообщать об этом всем заинтересованным сторонам. Последующие изменения в базовой линии требований к программным средствам следует оценивать по стоимости, графикам исполнения и воздействиям технических решений. *Ревизия программных средств - поддержка общего понимания с правообладателями прогресса относительно целей соглашения и того, что именно необходимо сделать для помощи в обеспечении разработки продукта, удовлетворяющего правообладателей. 7.1.3 Процесс проектирования архитектуры программных средств. Примечание: процесс проектирования архитектуры программных средств в настоящем стандарте является процессом более низкого уровня, чем процесс реализации программных средств. Цель: обеспечение проекта для программных средств, которые реализуются и могут быть верифицированы относительно требований. Выходы. В результате успешной реализации процесса проектирования архитектуры программных средств: a) разрабатывается проект архитектуры программных средств и устанавливается базовая линия, описывающая программные составные части, которые будут реализовывать требования к программным средствам; b) определяются внутренние и внешние интерфейсы каждой программной составной части; c) устанавливаются согласованность и прослеживаемость между требованиями к программным средствам и программным проектом. 7.1.3.3.1 Проектирование архитектуры программных средств. 7.1.3.3.1.1 Исполнитель должен преобразовать требования к программным составным частям в архитектуру, которая описывает верхний уровень его структуры и идентифицирует программные компоненты. Необходимо гарантировать, что все требования к программным составным частям распределяются по программным компонентам и в дальнейшем уточняются для облегчения детального проектирования. Архитектуру программной составной части необходимо документировать. Примечание: проектирование архитектуры программных средств обеспечивает также основу для верификации программных составных частей, объединения программных составных частей друг с другом и их интеграции с остальными составными частями системы. 7.1.3.3.1.2 Исполнитель должен разработать и документально оформить проект верхнего уровня для внешних интерфейсов программной составной части и интерфейсов между ней и программными компонентами. 7.1.3.3.1.3 Исполнитель должен разработать и документально оформить проект верхнего уровня для базы данных. 7.1.3.3.1.4 Исполнитель должен разработать и документально оформить предварительные версии пользовательской документации. 7.1.3.3.1.5 Исполнитель должен определить и документировать требования к предварительному тестированию и график работ по комплексированию программных средств. 7.1.3.3.1.6 Исполнитель должен оценить архитектуру программной составной части, проекты по интерфейсам и базе данных, учитывая следующие критерии: a) прослеживаемость к требованиям программной составной части; b) внешняя согласованность с требованиями программной составной части; c) внутренняя согласованность между программными компонентами; d) приспособленность методов проектирования и используемых стандартов; e) осуществимость детального проектирования; f) осуществимость функционирования и сопровождения. Результаты оценок следует оформлять документально. 7.1.3.3.1.7 Исполнитель должен проводить ревизии в соответствии с 7.2.6. 7.1.4 Процесс детального проектирования программных средств. Примечание: процесс детального проектирования программных средств в настоящем стандарте является процессом более низкого уровня, чем процесс реализации программных средств. Цель: обеспечение проекта для программных средств, которые реализуются и могут быть верифицированы относительно установленных требований и архитектуры программных средств, а также существенным образом детализируются для последующего кодирования и тестирования. Выходы. В результате успешного осуществления процесса детального проектирования программных средств: а) разрабатывается детальный проект каждого программного компонента, описывающий создаваемые программные модули; b) определяются внешние интерфейсы каждого программного модуля; c) устанавливается совместимость и прослеживаемость между детальным проектированием, требованиями и проектированием архитектуры. 7.1.4.3.1 Детальное проектирование программных средств 7.1.4.3.1.1 Исполнитель должен разработать детальный проект для каждого программного компонента программной составной части. Программные компоненты должны быть детализированы на более низком уровне, включающем программные блоки, которые могут быть закодированы, откомпилированы и проверены. Следует гарантировать, что все требования к программным средствам распределяются от программных компонентов к программным блокам. Детальный проект должен быть документально оформлен. 7.1.4.3.1.2 Исполнитель должен разработать и документально оформить детальный проект для внешних интерфейсов к программным составным частям, между программными компонентами и между программными блоками. Необходимо, чтобы детальный проект для интерфейсов позволял проводить кодирование без потребности в получении дополнительной информации. 7.1.4.3.1.3 Исполнитель должен разработать и документально оформить детальный проект базы данных. 7.1.4.3.1.4 Исполнитель должен совершенствовать пользовательскую документацию по мере необходимости. 7.1.4.3.1.5 Исполнитель должен определять и документировать требования к тестированию и графики работ по тестированию программных блоков. Необходимо, чтобы требования к тестированию включали в себя проведение проверок программных блоков при граничных значениях параметров, установленных в требованиях. 7.1.4.3.1.6 Исполнитель должен обновлять требования к тестированию и графики работ по комплексированию программных средств. 7.1.4.3.1.7 Исполнитель должен оценивать детальный проект для программных средств и требования к тестированию по следующим критериям: a) прослеживаемость к требованиям программной составной части; b) внешняя согласованность с архитектурным проектом; c) внутренняя согласованность между программными компонентами и программными блоками; d) соответствие методов проектирования и используемых стандартов; e) осуществимость тестирования; f) осуществимость функционирования и сопровождения. Результаты оценки должны быть документально оформлены. 7.1.4.3.1.8 Исполнитель должен проводить ревизии в соответствии с 7.2.6. 7.1.5 Процесс конструирования программных средств. Примечание: процесс конструирования программных средств, представленный в настоящем стандарте, является процессом более низкого уровня, чем процесс реализации программных средств. Цель: создание исполняемых программных блоков, которые должным образом отражают проектирование программных средств. Выходы. В результате успешного осуществления процесса конструирования программных средств: a) определяются критерии верификации для всех программных блоков относительно требований; b) изготавливаются программные блоки, определенные проектом; c) устанавливается совместимость и прослеживаемость между программными блоками, требованиями и проектом; d) завершается верификация программных блоков относительно требований и проекта. 7.1.5.3.1 Конструирование программных средств. 7.1.5.3.1.1 Исполнитель должен разработать и документально оформить: a) каждый программный блок и базу данных; b) процедуры тестирования и данные для тестирования каждого программного блока и базы данных. 7.1.5.3.1.2 Исполнитель должен тестировать каждый программный блок и базу данных, гарантируя, что они удовлетворяют требованиям. Результаты тестирования должны быть документально оформлены. 7.1.5.3.1.3 Исполнитель должен улучшать документацию пользователя при необходимости. 7.1.5.3.1.4 Исполнитель должен совершенствовать требования к тестированию и графики работ по комплексированию программных средств. 7.1.5.3.1.5 Исполнитель должен оценивать программный код и результаты испытаний, учитывая следующие критерии: a) прослеживаемость к требованиям и проекту программных элементов; b) внешнюю согласованность с требованиями и проектом для программных составных частей; c) внутреннюю согласованность между требованиями к блокам; d) тестовое покрытие блоков; e) соответствие методов кодирования и используемых стандартов; f) осуществимость комплексирования и тестирования программных средств; g) осуществимость функционирования и сопровождения. Результаты оценки должны быть документально оформлены. 7.1.6 Процесс комплексирования программных средств. Примечание:процесс комплексирования программных средств в настоящем стандарте является процессом более низкого уровня, чем процесс реализации программных средств. Цель: объединение программных блоков и программных компонентов, создании интегрированных программных элементов, согласованных с проектом программных средств, которые демонстрируют, что функциональные и нефункциональные требования к программным средствам удовлетворяются на полностью укомплектованной или эквивалентной ей операционной платформе. Выходы. В результате успешного осуществления процесса комплексирования программных средств: a) разрабатывается стратегия комплексирования для программных блоков, согласованная с программным проектом и расположенными по приоритетам требованиями к программным средствам; b) разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие с требованиями к программным средствам, связанными с этими составными частями; c) программные составные части верифицируются с использованием определенных критериев; d) программные составные части, определенные стратегией комплексирования, изготавливаются; e) регистрируются результаты комплексного тестирования; f) устанавливаются согласованность и прослеживаемость между программным проектом и программными составными частями; g) разрабатывается и применяется стратегия регрессии для повторной верификации программных составных частей при возникновении изменений в программных блоках (в том числе в соответствующих требованиях, проекте и кодах). 7.1.6.3.1 Комплексирование программных средств 7.1.6.3.1.1 Исполнитель должен разработать план комплексирования для объединения программных блоков и программных компонентов в программную составную часть. План должен включать в себя требования к тестированию, процедуры, данные, обязанности и графики работ. План должен быть оформлен документально. 7.1.6.3.1.2 Исполнитель должен объединить программные блоки, программные компоненты и тесты, поскольку они разрабатываются в соответствии с планом комплексирования. Должны быть гарантии в том, что каждое такое объединение удовлетворяет требованиям к программной составной части и что составная часть комплексируется при завершении выполнения данной задачи. Результаты комплексирования и тестирования должны быть оформлены документально. Примечание: должна быть разработана стратегия регрессии для применения повторной верификации программных элементов в случае, когда изменения проводятся в программных блоках, включая соответствующие требования, проект и коды. 7.1.6.3.1.3 Исполнитель должен обновлять пользовательскую документацию по мере необходимости. 7.1.6.3.1.4 Исполнитель должен разработать и документально оформить для каждого квалификационного требования к программной составной части комплект тестов, тестовых примеров (входов, результатов, критериев тестирования) и процедур тестирования для проведения квалификационного тестирования программных средств. Разработчик должен гарантировать, что после комплексирования программная составная часть будет готова к квалификационному тестированию. 7.1.6.3.1.5 Исполнитель должен оценить план комплексирования, проект, код, тесты, результаты тестирования и пользовательскую документацию, учитывая: a) прослеживаемость к системным требованиям; b) внешнюю согласованность с системными требованиями; c) внутреннюю согласованность; d) тестовое покрытие требований к программной составной части; e) приспособленность используемых методов и стандартов тестирования; f) соответствие ожидаемым результатам; g) осуществимость квалификационного тестирования программных средств; h) осуществимость функционирования и сопровождения. Примечание: в критерии оценки следует включать согласованность и прослеживаемость между программным проектом и программными составными частями. Результаты оценки должны быть оформлены документально. 7.1.6.3.1.6 Исполнитель должен проводить ревизии в соответствии с 7.2.6. 7.1.7 Процесс квалификационного тестирования программных средств. Примечание: процесс квалификационного тестирования программных средств, представленный в настоящем стандарте, является процессом более низкого уровня, чем процесс реализации программных средств. Цель: подтверждение того, что комплектованный программный продукт удовлетворяет установленным требованиям. Выходы. В результате успешного осуществления процесса квалификационного тестирования программных средств: a) определяются критерии для комплектованных программных средств с целью демонстрации соответствия с требованиями к программным средствам; b) комплектованные программные средства верифицируются с использованием определенных критериев; c) записываются результаты тестирования; d) разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного средства при проведении изменений в программных составных частях. Примечание: должна быть разработана стратегия регрессии для повторного применения тестирования комплексированного программного средства при проведении изменений в программных составных частях. 7.1.7.3.1 Квалификационное тестирование программных средств 7.1.7.3.1.1 Исполнитель должен проводить квалификационное тестирование в соответствии с квалификационными требованиями к программному элементу. Должна обеспечиваться гарантия того, что реализация каждого требования к программным средствам тестируется на соответствие. Результаты квалификационного тестирования должны быть документально оформлены. 7.1.7.3.1.2 Исполнитель должен обновлять пользовательскую документацию по мере необходимости. 7.1.7.3.1.3 Исполнитель должен оценивать проект, код, тесты, результаты тестирования и пользовательскую документацию, учитывая следующие критерии: a) тестовое покрытие требований к программной составной части; b) соответствие с ожидаемыми результатами; c) осуществимость системного комплексирования и тестирования, если они проводятся; d) осуществимость функционирования и сопровождения. Результаты оценки должны быть документально оформлены. 7.1.7.3.1.4 Исполнитель должен поддерживать проведение аудитов* в соответствии с 7.2.7. Результаты аудитов должны быть документально оформлены. Если и технические, и программные средства разрабатываются или комплексируются, то аудиты могут быть отсрочены до тех пор, пока не будет выполнено системное квалификационное тестирование. 7.1.7.3.1.5 После успешного завершения аудитов (если они проводились) исполнитель должен обновить и подготовить поставляемый программный продукт для системного комплексирования, системного квалификационного тестирования, инсталляции программных средств или поддержки приемки программных средств. Примечание: процесс квалификационного тестирования программных средств может использоваться в процессе верификации программных средств (см. 7.2.4) или процессе валидации программных средств (см. 7.2.5). *Аудит (audit) - независимая оценка программных продуктов и процессов, проводимая уполномоченным лицом с целью оценить их соответствие требованиям