Каскадная модель жизненного цикла

Практическое занятие №1

Модели жизненного цикла программного обеспечения АБИС

Цели работы

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

Теоретические сведения

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

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

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

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

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

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

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

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

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

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

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

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

·планирование последовательности работ и сроков их исполнения,

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

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

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

Резюме

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

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

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

Задания к выполнению работ

1.Подготовьте краткое словесное описание Вашей задачи/подсистемы/системы, которая является предметомия?

2. Составьте матрицы, относящиеся к выбору модели ЖЦ Вашего проекта, ответив на вопросы, приведенные для каждой категории в таблицах 1.1-1.4 При этом для ответов Да – используйте, значение 1, ответов Нет – используйте, значение 0, все остальным ответам присвойте значения в интервале от 0 до 1, в зависимости от близости к Да или Нет

3. Расположите по степени важности вопросы, относящиеся к каждой категории, относительно Вашего проекта, для которого выбирается приемлемая модель.

4. Проанализируйте полученные результаты и сделайте выводы о приемлемой модели ЖЦ для Вашего проекта.

5. Подготовить ответы на контрольные вопросы

Номера контрольных вопросов взять у преподавателя.

6. Оформить в электронном или печатном виде отчет о выполнении работы.

В состав отчета входят:

· Письменные ответы на контрольные вопросы

· Краткое описание Вашей задачи/подсистемы/системы?

· Результаты выполнения практического задания

· Выводы по результатам практического задания

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

[1] В строительном проекте задача заключается в том, чтобы, имея хорошо понятный проект, определить все задачи, выделить соответствующие средства, определить действия и взаимозаменяемые компоненты, а затем выполнять задания так, чтобы бюджет и/или критический путь были минимальными.

Практическое занятие №1

Модели жизненного цикла программного обеспечения АБИС

Цели работы

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

Теоретические сведения

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

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

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

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

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

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

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

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

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

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

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

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

·планирование последовательности работ и сроков их исполнения,

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

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

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

Каскадная модель жизненного цикла

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

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

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

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

Рис.1.2. Каскадная модель жизненного цикла

Нетрудно заметить, что каскадная модель имеет множество преимуществ, если ее использовать в проекте, для которого она достаточно приемлема:

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

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

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

· ее структурой может руководствоваться даже слабо подготовленный в техническом плане или неопытный персонал;

· она отличается стабильностью требований;

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

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

· она способствует осуществлению строгого контроля менеджмента проекта;

· при правильном использовании модели дефекты можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;

· она облегчает работу руководителю проекта по составлению плана и комплектации команды разработчиков;

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

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

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

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

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

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

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

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

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

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

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

5. Основные риски программных проектов смещены на завершающий этап работ. По мере выполнения строительного проекта его риск становится все меньше и меньше. Часто наибольший риск присутствует в начале проекта, на этапе рытья котлована и подготовки строительной площадки. К моменту выполнения отделочных работ он практически сводится к нулю, если только субподрядчики выполнят свои работы в соответствии с графиком и спецификациями. А в программных проектах все происходит с «точностью до наоборот». Наиболее рискованной частью разработки программных продуктов является объединение отдельных элементов системы.

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

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

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

Чтобы адаптировать каскадный процесс к особенностям разработки ПО, были предприняты попытки его модификации, примером которой могут служить итерационная и V-образная модели жизненного цикла.