 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Спиральная модель
Весь процесс разбивается на итерацию. Каждый виток спирали – итерация.
Каждый виток спирали разбит на четыре сектора:
Первый. Определение целей. Определяются цели каждой итерации проекта. Кроме того, устанавливаются ограничения на процесс создания ПО и на сам программный продукт, уточняются планы производства компонентов. Определяются проектные риски (например, риск превышения сроков или риск превышения стоимости проекта). В зависимости от "проявленных" рисков, могут планироваться альтернативные стратегии разработки ПО.
Второй. Оценка и разрешение рисков. Для каждого определенного проектного риска проводится его детальный анализ. Планируются мероприятия для уменьшения (разрешения рисков). Например, если существует риск, что системные требования определен неверно, планируется разработать прототип системы.
Третий. Разработка и тестирование. После оценки рисков выбирается модель процесса создания системы. Например, сети доминируют риски, связанные с разработкой интерфейсов, наиболее подходящей будет эволюционная модель разработки прототипированием. Если основные риски связаны с соответствием системы и спецификации, скорее всего, следует применить модель формальных преобразований. Каскадная модель может быть применена в том случае, если основные риски определены как ошибки, которые могут проявиться на этапе сборки системы.
Четвёртый. Планирование. Здесь пересматривается проект и принимается решение о том, начинать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта.
Существенное отличие спиральной модели от других моделей процесса создания ПО заключается в точном определении и оценивании рисков. Если говорить неформально, то риск — это те неприятности, которые могут случиться в процессе разработки системы. Например, если при написании программного кода используется новый язык программирования, то риск может заключаться в том, что компилятор этого языка может быть ненадежным или что результирующий код может быть не достаточно эффективным. Риски могут также заключаться в превышении сроков или стоимости проекта. Таким образом, уменьшение (разрешение) рисков — важный элемент управления системным проектом.
Гибкие методологии разработки программных продуктов.
Классические методологии характеризируются, во-первых, слишком большим объемом документации; процесс разработки — это жёсткая и неизменная структура, эти характеристики являются сдерживающими факторами при разработке маленьких программных продуктов, на смену приходят гибкие методологии.
Предпосылки возникновения гибких методологий.
Первый этап — code and fix: сначала пишем, потом отлаживаем, особенности заключаются в том, что нет никакого единого плана разработки; вместо единого проекта есть набор краткосрочных решений, минус в том, что такие продукты нельзя поддерживать и развивать, ещё одна особенность — слишком продолжительный период тестирования и отладки, это приводит к нарушению планки выпуска продукта.
Второй этап — классическая методология.
Третий этап — гибкие методологии. Плюсы: меньшая ориентация на документацию продукта. Гибкие методологии являются адаптивными, вместо единой структуры применяются подстроенные под каждый проект методологии разработки. Гибкие методологии ориентированы на человека, а не на процесс.
Особенности гибких методологий разработки программных продуктов.
Проектирование и конструирование. Процесс разработки программного продукта можно сравнить с инженерной деятельностью, предложено в качестве проекта рассматривать исходный код, а сборку — компиляция. При изготовлении программного продукта можно считать, что девяносто процентов времени тратится на проектирование — то есть на написание кода. Поскольку почти всё рабочее время уход на написание кода, то каждый программист рассматривается как творческое лицо.
Непредсказуемость требований. Требования к программному продукту всегда меняются и будут меняться. Некоторые причины:
— Меняются цели, меняются требования заказчика, меняются продукты которые разрабатываем.
— Невозможность составления полной всеобъемлющей непротиворечивой спецификации требований.
— Меняются технологии, меняются ОС и остальные средства.
— На начальном этапе (до начала проектирования) невозможно точно оценить длительность (трудоемкость, стоимость) той или другой функции программы.
— Заказчик не может оценить, целесообразно ли заказывать эту функцию.
Особенности управления непредсказуемым процессом.
Не нужно делать вид, что требования не меняются, нельзя пытаться втиснуть гибкий процесс в какую-нибудь жесткую методологию. Нужно постоянно владеть актуальной информацией, состоянием по делу на текущий момент времени, состояние наших дел.
Для того чтобы адаптировать процесс к меняющемся требованиям, его нужно организовать итеративно. На начало итерации фиксируется некоторый набор требований, в течении итерации новые требования не применяются, в течение короткого промежутка времени реализуется некоторый набор функций, разработанные в текущей итерации программные модули интегрируется с ранее созданными модулями, в итоге получается очередная версия системы, после проходит аттестация с заказчиком, процесс повторяется. Основной момент при этом — определение длительности итерации, в среднем длится около четырёх недель, итерация должна быть настолько короткой, насколько возможно в рамках текущего проекта.
Адаптивный заказчик —это одна из особенностей гибких методологий.
Адаптивный процесс требует особых отношений с заказчиком. Если классических подход предполагает по сути дела покупку заказчиком программного продукта, то гибкие методологии говорят о том, что с заказчиком нужно дружить и постоянно взаимодействовать. Важен контроль с заказчиком каждой итерации, каждого этапа разработки, это существенно повышает качество программного продукта. Гибкие методологии предполагают постоянное взаимодействие с заказчиком, вплоть до того, что специалист по программной области принимается в команду.
Особенности отношения к разработчику.
Классическую модель акцентуируют на процессе, а не на разработчике. Важный шаг, который сделан — люди-программисты поставлены на первое место. Смещаются аспекты в управлении проектом, то есть менеджер не должен учить программиста программировать, не менеджер говорит о сроках, а программист смотрит на требования и говорит, сколько его команде нужно времени — программисту делегируется часть ответственности по управлению проектом.
Гибкие методологии ориентированы на быструю разработку небольших программных продуктов. Как правило, создание таких продуктов предполагает использование небольшой команды разработчиков, каждый из которых обладает высокой квалификацией. Поэтому гибкая методология говорит, что к каждому разработчику нужно подходить индивидуально.
Поиск по сайту: