Водопадная модель процесса

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Федеральное Государственное Учреждение

Высшего Профессионального Образования

«Тихоокеанский Государственный Университет»

Кафедра: «Экономическая кибернетика»

Контрольная работа

По дисциплине: Разработка и стандартизация

Тема: «Водопадная модель процесса»

Содержание:

Введение

Основные процессы жизненного цикла

Адаптация стандарта

Модели жизненного цикла

Каскадная (водопадная) модель

Вывод

Список используемых источников

Введение

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

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

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

Эти принципы:

Модульность

* задачи в процессе являются функционально связанными;

* связь между процессами - минимальна;

* если функция используется более, чем одним процессом, она сама является процессом;

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

Ответственность

* каждый процесс находится под ответственностью конкретного лица (управляется и/или

контролируется им), определенного для заданного жизненного цикла, например, в виде роли в проектной команде;

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

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

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

* задачи

В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле:

* “P” - Plan - Планирование

* “D” - Do - Выполнение

* “C” - Check - Проверка

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

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

Основные процессы жизненного цикла

Приобретение

Процесс приобретения (как его называют в ГОСТ - “заказа”) определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой перевод названий работ оригинального стандарта):

* Inititation - инициирование (подготовка)

* Request-for-proposal preparation - подготовка запроса на предложение (подготовка заявки

на подряд)

* Contract preparation and update -подготовка и корректировка договора

* Supplier monitoring - мониторинг поставщика (надзор за поставщиком)

* Acceptance and completion - приемка и завершение (приемка и закрытие договора)

Все работы проводятся в рамках проектного подхода.

Поставка

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

* Inititation - инициирование (подготовка)

* Preparation of response - подготовка предложения (подготовка ответа)

* Contract - разработка контракта (подготовка договора)

* Planning - планирование

* Execution and control - выполнение и контроль

* Review and evaluation -проверка и оценка

* Delivery and completion - поставка и завершение (поставка и закрытие договора)

Процесс разработки определяет работы и задачи разработчика. Процесс состоит из следующих работ:

* Process implementation - определение процесса (подготовка процесса)

* System requirements analysis - анализ системных требований (анализ требований к системе)

* System design - проектирование системы (проектирование системной архитектуры)

* Software requirements analysis - анализ программных требований (анализ требований к программным средствам)

Введение в программную инженерию и управление жизненным циклом ПО:

* Software architectural design - проектирование программной архитектуры

* Software detailed design - детальное проектирование программной системы (техническое проектирование программных средств)

* Software coding and testing - кодирование и тестирование (программирование и тестирование программных средств)

* Software integration - интеграция программной системы (сборка программных средств)

* Software qualification testing - квалификационные испытания программных средств

* System integration - интеграция системы в целом (сборка системы)

* System qualification testing - квалификационные испытания системы

* Software installation - установка (ввод в действие)

* Software acceptance support - обеспечение приемки программных средств

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

Эксплуатация

Процесс разработки определяет работы и задачи оператора службы поддержки. Процесс включает следующие работы:

* Process implementation - определение процесса (подготовка процесса)

* Operational testing - операционное тестирование (эксплуатационные испытания)

* System operation - эксплуатация системы

* User support - поддержка пользователя

Сопровождение

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

Процесс включает следующие работы:

* Process implementation - определение процесса (подготовка процесса)

* Problem and modification analysis - анализ проблем и изменений

* Modification implementation - внесение изменений

* Maintenance review/acceptance - проверка и приемка при сопровождении

* Migration - миграция (перенос)

* Software retirement - вывод программной системы из эксплуатации (снятие с эксплуатации)

Важно понимать, что стандарт 12207 не определяет последовательность и разбиение

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

Адаптация стандарта

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

Адаптация включает следующие виды работ:

* Определение исходной информации для адаптации стандарта

* Определение условий выполнения проекта

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

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

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

Необходимо отметить, что существует еще один стандарт жизненного цикла - ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации процессов жизненного цикла системного уровня (Life Cycle Processes - System) и включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию жизненного цикла к конкретным требованиям и ограничениям, существующим или принятым в конкретной организации/подразделении или для заданного проекта.

Модели жизненного цикла

Наиболее часто говорят о следующих моделях жизненного цикла:

* Каскадная (водопадная) или последовательная

* Итеративная и инкрементальная - эволюционная (гибридная, смешанная)

* Спиральная (spiral) или модель Боэма

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

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

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

Каскадная (водопадная) модель

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

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

каскадная модель жизненный цикл

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

Марри Кантор отмечает ряд важных аспектов, характерных для водопадной модели: “Водопадная схема включает несколько важных операций, применимых ко всем проектам:

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

* планирование работ, связанных с каждым действием;

* применение операции отслеживания хода выполнения действий с контрольными этапами.

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

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

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

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

Вывод

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

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

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

Список используемых источников

1. Б.У. Боэм «Инженерное проектирование программного обеспечения». М.: Радио и связь. 1985.

2. Д.Райли. «Использование языка Модула-2». М.: Мир. 1993.

3. Ю.В. Иванов «Программы и их жизненные циклы» (реферат по дисциплине «Метрология ПО»). 1998.

Размещено на www.allbest.