Модели жизненного цикла asdh-ориентация на сотрудничество

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

Тяжелый проект

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

Жизненные циклы сверх тяжелых проектов

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

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

Цель сотрудинчества учесть требования клиента, сформировать единое видение и оптимальный комплекс инструмента на всех стадиях участвуют 2 лица:

1)Менеджер проекта

2)куратор проекта со стороны клиента

Основные стадии проекта

1)подготовка прототипа

2)тестирование и устранение замечаний

3)перевод в тестовую эксплуатацию

4)обучения персонала

5) переход к промышленной эксплуатации, оценка результатов, завершение проектов

 

7)программирование пары весь код пишется двумя программистами на одном компьютере

8)коллективное владение кодом любой член команды может изменить любую часть кода, но несет ответственность за изменение

9)постоянная интеграция (несколько раз в день)

10)40 часовая рабочая неделя (сверх урочная работа) – признак больших проблем в системе

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

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

13)открытое рабочее пространство, команда размещается в одном помещение

14)изменение правил по необходимости

Методика Oracle CDM

Рисунки

стратегия	анализ	проектирование	реализация	внедрение	Эксплуатация

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

Этапы разработки

1)стратегия (определение требований)

2)анализ (формулирование детальных требований к прикладной системе)

3)проектирование (преобразование требований в детальные спецификации системы)

4)реализация (написание и тестирование приложений)

5)внедрение (установка новой прикладной системы, подготовка к началу эксплуатации)

6)эксплуатация (поддержка и слежение за приложением, планирование будущих функциональных расширений)

Процессы разработки

Сопоставление бизнес требований это исследование существующих решений.

Конвертация данных – это проектирование и построение базы данных.

Методика Oracle CDM осуществляет управление и руководство проектом внедрения разработки и внедрения информационных систем масштаба предприятия.

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

Идентифицированный процесс RVP

Таблица

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

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

Фаза проработки

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

Фаза построения

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

Фазы передач

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

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

1)моделирование предметной области (бизнес моделирование)

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

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

Требование принято фиксировать в модели вариантов использования (use cases)

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

-диаграммы классов системы

-диаграммы компонентов системы

-диаграммы взаимодействий между объектами входе реализации вариантов использований

-диаграммы состояний для отдельных объектов

-диаграммы развертывания

4)реализация – цели определить структуру исходного кода системы, разработать код его компонента и протестировать их, интегрировать систему в работающее целое

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

6)развертывание – цель, развернуть систему в её рабочем окружение и оценить ее работоспособность

7)управление конфигурациями и изменения – цель, определение элементов подлежащих хранения и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений

8)управление проектами – цель планирования управления персонала обеспечение связи с другими заинтересованными лицами, управления рисками, отслеживание текущего состояния проекта

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