Учебно-методическое пособие "Управление качеством разработки программного обеспечения"


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



страница3/18
Дата18.10.2016
Размер1.92 Mb.
ТипУчебно-методическое пособие
1   2   3   4   5   6   7   8   9   ...   18

3.2 Модели жизненного цикла программного обеспечения.


Одним из ключевых понятий управления проектами, в том числе в приложении к индустрии программного обеспечения, является жизненный цикл проекта (Project Life Cycle Management -PLCM).

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

Ниже приведены определения «модели» жизненного цикла программной системы, даваемые, например, в различных вариантах стандартов ГОСТ:
• Модель жизненного цикла - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее

использования [ГОСТ 12207, 1999].

• Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990].

Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207.

Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы

программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД).

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

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

Скотт Амблер (Scott W. Ambler), автор концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process), предлагает следующие уровни жизненного цикла, определяемые соответствующим содержанием работ:
• Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем

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

• Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента

• Жизненный цикл организации – охватывает всю деятельность организации в Целом


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

группа процессов

процессы

работы


задачи
В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле:
• “P” – Plan – Планирование

• “D” – Do – Выполнение

• “C” – Check – Проверка

• “A” – Act – Реакция (действие)


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

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

«Подходящая» модель жизненного цикла:

направляет проект

улучшает скорость разработки

улучшает отслеживание и контроль над проектом

минимизирует издержки и влияние рисков

улучшает отношение с клиентом

«Неподходящая» модель ЖЦ:

замедляет выполнение работ

вынуждает делать лишнюю работу

проект оказывается неуспешным


3.2.1 Каскадная модель (1970, W.W. Royce)


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

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

Каскадная модель (или «водопадная модель», waterfall) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Характерна для периода 1970-1985 гг.

Рис. 1. Каскадная модель.



На начальном периоде каскадная модель сыграла ведущую роль как метод регулярной разработки сложного программного обеспечения. В семидесятых-восьмидесятых годах XX века модель была принята как стандарт министерства обороны США.

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


  • Требования и их реализация максимально четко определены и понятны; используется неизменяемое определение продукта и вполне понятные технические методики. Это задачи типа:

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

    • операционные системы и компиляторы

    • системы реального времени управления конкретными объектами

Кроме того, каскадная модель применима в условиях:



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

  • выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (миграция уже существующего продукта на новую платформу)

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

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


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

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

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

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


Каскадная модель имеет следующие преимущества:

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

  • Проста и удобна в применении:

    • процесс разработки выполняется поэтапно.

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

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

  • Каждую стадию могут выполнять независимые команды (все документировано)

  • Позволяет достаточно точно планировать сроки и затраты

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

  • Попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;

  • Интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок;

  • Запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат

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


Каталог: shared -> files -> 201211
201211 -> 1. 1 Предмет и содержание курса 2 Вопросы стандартизации систем
201211 -> Учебное пособие 10 часть Основы общей теории управления. Функциональный и процессный подходы к управлению организацией 15
201211 -> Учебное пособие Санкт-Петербург 2012
files -> Технологические подходы к разработке по [Алексеев П. С.]
files -> Статья 48. Архитектурно-строительное проектирование
files -> Программа дисциплины вычислительная геометрия Цели изучения дисциплины
files -> Методы расчета расходов на it совокупная стоимость владения


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   18


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал