ЖИЗНЕННЫЙ ЦИКЛ ПО ИС

из всех видов деятельности, которые осуществляются с того момента, как

версия 1.0 системы начинает свое существование лишь как идея, и до того момента, когда версия 6.74b сделает свой последний вздох на компьютере последнего заказчика.»

Стив Мак Коннелл, Быстрая разработка, 1996
(Steve McConnell, Rapid Development)‏

принятия решения о необходимости его создания и заканчивается в момент

его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

ЖЦ

В узком смысле может включать лишь часть ЖЦ, связанную с

кодированием/программированием:
Проектирование системы
Реализация
Тестирование и передача заказчику
[Сопровождение]

(или приемов) для завершения фаз(ы) ЖЦ ПО

Методология может включать применение:
математических

(формальных) моделей, пример – АМ Гуревича c состояниями;
методов («техник», «практик») разной степени формализации
инструментальных средств (CASE, RAD, CMS, …),

быстрое прототипирование; этапы ЖЦ = потоки; роли);
Microsoft MSF (синтез каскадной

и спиральной моделей, процессный подход, синхростабилизация);
Oracle CDM (каскадная модель, жестко детерминированные этапы ЖЦ, прототипирование)‏
«Гибкие»: Agile, XP (итеративность, неформальные критерии «лучшие практики», рефакторинг – улучшение кода)‏

начиная от зарождения идеи ПО до реализации и сдачи пользователю,

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

Требования 2% 21% / 18%
(со спецификациями)‏
Спецификации 5%
Проектирование 6% 18% / 19%
Кодирование 5% 36% / 34%

(с тестированием)‏
Тестирование 7%
Интеграция 8% 24% / 29%
Сопровождение 67%

многокомпонентных проектов)‏
Средства, увеличивающие расширяемость ПО
(и/или сроки обновления и тестирования)

более
эффективны, чем все ухищрения при кодировании
Фазы, предшествующие кодированию и следующие за ним, составляют 30% затрат (кодирование – 5%):
«обрамляющие» стадии улучшают качество ПО;
«обрамляющие» стадии ускоряют кодирование

12207) структура ЖЦ разработки ПО базируется на 3 группах процессов:
Основные
Вспомогательные

Организационные

приобретения - включает задачи:
определение заказчиком своих потребностей в приобретении;
анализ требований

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

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

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

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

набора процессов ЖЦ ПО, существует набор классический, включающий основные процессы,

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

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

в действие;
эксплуатация и сопровождение;
завершение эксплуатации;

выполнения и взаимосвязи процессов на протяжении ЖЦ. Модель жизненного цикла

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

каждой стадии
Ключевые события — точки завершения работ и принятия

решений.

Модель ЖЦ - пример
каскадная
спиральная

выпуску внутренней или внешней версии изделия, которое совершенствуется от итерации

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

выполнения проекта, не дожидаясь полного завершения текущего — недоделанную работу

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

при изменении требований заказчика.
При использовании спиральной модели отдельные элементы

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

интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По

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

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

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

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

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

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

главным недостатком каскадной схемы. Данный недостаток проявляется в основном в

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

недостаток каскадной модели в общем-то является одним из проявлений предыдущего.

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

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

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

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

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

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

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

тем больше продолжительность каждого из этапов разработки и тем сложнее

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