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

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

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

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

Эти модели можно разделить на 3 основных группы:

1. Инженерный подход
2. С учетом специфики задачи
3. Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.

Данная модель имеет следующий алгоритм:

1. Постановка задачи
2. Выполнение
3. Проверка результата
4. При необходимости переход к первому пункту

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

Каскадная модель жизненного цикла программного обеспечения (водопад)

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

Преимущества:

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

Недостатки:

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

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

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

V модель (разработка через тестирование)

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.

Модель на основе разработки прототипа

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

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

1. Прояснить не ясные требования (прототип UI)
2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
3. Проанализировать осуществимость проекта

Классификация протопипов:

1. Горизонтальные и вертикальные
2. Одноразовые и эволюционные
3. бумажные и раскадровки

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

Вертикальные прототипы – проверка архитектурных решений.

Одноразовые прототипы – для быстрой разработки.

Эволюционные прототипы – первое приближение эволюционной системы.

Модель принадлежит второй группе.

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

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

Преимущества:

• Быстрое получение результата
• Повышение конкурентоспособности
• Изменяющиеся требования – не проблема

Недостатки:

• Отсутствие регламентации стадий

Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.

Большое спасибо за внимание!

Источник

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

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

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

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

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

Мотивация изучения жизненного цикла и его моделей

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

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

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

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

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

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

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

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

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

Если деятельность разработчиков программного проекта поддерживается на всех основных этапах жизненного цикла, т.е. проект ведется в условиях использования некоторой так называемой CASE-системы (Computer Aided Software Engineering), то заранее установлены определенные рамки, включая контрольные точки, когда менеджер должен организовывать управляющие воздействия. Это, естественно, ограничение вариантов развития проекта. И также естественно, что CASE-система навязывает априорное представление о жизненном цикле, фиксированное поддерживаемой моделью. В такой ситуации может возникнуть ложное впечатление о единственности модели жизненного цикла. В результате, когда приходится менять условия разработки, коллектив может оказаться не готов к этому.

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

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

Источник