Вопросы: 1.Планирование времени и стоимости проекта 2.Рациональный унифицированный процесс 3.Подходы к разработке ПО ИС 12.05.2013 1 П.П. Мельников, Финансовый. - презентация

1 Вопросы: 1.Планирование времени и стоимости проекта 2.Рациональный унифицированный процесс 3.Подходы к разработке ПО ИС П.П. Мельников, Финансовый университет при Правительстве РФ

2 Входы: Концепция проекта Матрица требований Список ресурсов Команда проекта Выходы: ИСР (WBS) Сетевая диаграмма Перечень действий Ресурсы, распределенные по работам Оценки продолжительности работ и методики их расчета Оценки стоимости работ и методики их расчета Расписание Предельная цена проекта Запросы на изменения 1. Планирование времени и стоимости с использованием специализированного ПО 1) Формирование иерархической структуры работ (work breakdown structure- WBS) ИСР – ориентированная на результат поставки иерархическая декомпозиция работ, выполняемых командой проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. Ориентация на результат поставки включает как внутренние, так и внешние результаты поставки. Разработка ИСР по сути является планированием содержания работ. Создание ИСР помогает структурировать необходимые поставки, сделать информацию о них более наглядной. При созданииWBS необходима разумная глубина отражения в понятии «пакета работ». Основные признаки пакета работ: Относительно короткий Работы по созданию пакета могут быть выполнены без прерывания Работы по созданию пакета могут быть выполнены на аутсорсинге П.П. Мельников, Финансовый университет при Правительстве РФ

3 Под прерыванием понимается вынужденная остановка работ (например, для проведения других действий или получения согласования). Так, нельзя назвать пакетом работы по созданию «макета и шаблона сайта», если мы знаем, что нарисованный макет нужно сперва предъявить заказчику и, только получив его согласие, можно приступать к формированию шаблона. Источником данных для создания WBS служит концепция проекта. Наиболее удобным местом хранения введенных данных выступает специализированное ПО Microsoft Project. С помощью этого пакета можно хранить информацию о работах в следующем виде: Важнейшим элементом ИСР служит так называемый «словарь ИСР» (WBS- dictionary). Словарь позволяет подробнее описать то, что мы имели в виду под скупой формулировкой в ИСР. Роль «словаря» могут выполнять ссылки на данные результатов обследования П.П. Мельников, Финансовый университет при Правительстве РФ

4 2) Определение перечня действий При определении перечня действий в том же самом программном продукте необходимо декомпозировать сформированный ранее пакет работ до действий. Пакеты является поставко- ориентироваными. В качестве пакета могут выступать экранные формы, элементы интерфейса, хранимые процедуры, структуры базы данных и т.д. Теперь нужно декомпозировать их, описывая действия, каждое из которых может не иметь измеримого результата. Четких правил для выполнения такой декомпозиции нет. Глубина декомпозиции никак не регламентируется. В некоторых случаях не требует декомпозиции и сам пакет - можно оставить его в первоначальном виде. В примере декомпозиции подверглись только два пакета – «создать макет» и «утвердить макет у заказчика» П.П. Мельников, Финансовый университет при Правительстве РФ

5 3) Определение последовательности действий Порядок действий и пакетов указывается в поле «предшественник». В специализированном ПО Microsoft Project в режиме отображения «Диаграмма Ганта» для этой цели есть специальное поле «предшественник», которое может содержать ссылку на одну или несколько предшествующих работ П.П. Мельников, Финансовый университет при Правительстве РФ

6 Чтобы наглядно отобразить результат можно перевести его из таблично вида в графический, сформировав «сетевой график» П.П. Мельников, Финансовый университет при Правительстве РФ

7 4). Определение ресурсов Определившись, какие действия в какой последовательности будут выполняться в проекте, мы почти готовы приступить к непосредственной оценке их продолжительности и стоимости. «Почти» связано с тем, что в большинстве проектов ИТ-сферы исполнители оказывают огромное влияние на эффективность выполнения работы. До того, как мы дадим оценки по времени – мы должны знать «кто» и «над чем» будет работать. С составом команды проекта мы определились ранее. Специализированное ПО Microsoft Project позволяет задавать список ресурсов для проекта и назначать один или несколько из них для каждого действия П.П. Мельников, Финансовый университет при Правительстве РФ

8 5). Определение продолжительности и стоимости Грубые предположения о продолжительности и стоимости были ранее включены в устав. Теперь требуются намного более точные прогнозы. Потребителем таких оценок будет уже не спонсор / заказчик, а непосредственные исполнители, команда. То, что будет сделано сейчас, станет мерилом их успешности на проекте. Главные рекомендации для оценки времени Среди основных методов оценки времени иногда называют: Оценку одним человеком Оценку по аналогу Параметрическую оценку PERT Эвристическую оценку Анализ резервов Метод оценки одним человеком нужно использовать с осторожностью (в силу его субъективности) и никогда не делать основным. Оценка по аналогу – прекрасный способ мгновенно получить грубую оценку (его часто используют в фазе инициации) а также дать команде простой и понятный «ориентир продукта». Однако на многих ИТ-проектах данный метод недоступен (в силу уникальности того же продукта) П.П. Мельников, Финансовый университет при Правительстве РФ

9 Методы параметрических и эвристических оценок порождают огромное количество споров и дискуссий в разных профессиональных сообществах. Не пренебрегайте данными оценками, но относитесь к ним критично. PERT (или «оценка по трем точкам) – чрезвычайно полезный прием, позволяющий оценить продолжительность выполнения работ, комбинируя «оптимистичную», «пессимистичную» и «наиболее вероятную» оценки. Целесообразно использовать PERT для тех работ, оценка которых затруднена и/или имеет высокий диапазон допущения. Этот метод оперирует тремя видами усредненных прогнозов – «пессимистичным», «оптимистичным» и «наиболее вероятным». Для этого нужно определить их (самостоятельно или с помощью экспертов) для каждой работы «достоверную» продолжительность которой вы собираетесь определить, а затем подставить в приведенные ниже формулы. Согласно PERT предполагаемая длительность (или EAD) составит: EAD = (P + 4M +O) / 6 где P – «пессимистичная оценка», O – «оптимистичная оценка», M – «наиболее вероятная оценка». С помощью PERT можно дополнительно уточнить и сам диапазон допущения: 1.Возможное отклонение (SD) составит: SD = (P-O) / 6 2.Диапазон колебания (range) составит: Оптимистичный прогноз = EAD – SD Пессимистичный прогноз = EAD + SD П.П. Мельников, Финансовый университет при Правительстве РФ

10 Точность создаваемых сейчас оценок должна быть достаточно высокой с погрешностью от 5 до 25%, или меньше, в зависимости от характера проекта. После получения оценок, полученные результаты нужно внести в соответствующий столбец рабочей области специализированного ПО. Для первого вида работы (Придумать макет) следует установить дату начала выполнения ее выполнения П.П. Мельников, Финансовый университет при Правительстве РФ

11 6). Оценка стоимости Многие из методов, применяемых для оценивания времени, могут применяться при оценке стоимости. Это и оценка одним человеком, и оценка по аналогу, и параметрическая оценка, и тот же PERT (оперирующие вместо прогнозов времени – стоимостью). Однако одним из наиболее удобных и наглядных способов является оценка «снизу вверх». Себестоимость ИТ-проектов, в своей основе, складывается из себестоимости их ресурсов. Перечень ресурсов следует ввести в соответствующие поля рабочей области специализированного программного ПО. Теперь можем просто задать правила начисления их зарплаты (будь то ставки в час, зарплата в месяц, повышенные сверхурочные и т.п.). Все расчеты произведет ПО П.П. Мельников, Финансовый университет при Правительстве РФ

12 Сведения о суммарных затратах можно получить из общей статистики по проекту П.П. Мельников, Финансовый университет при Правительстве РФ

13 7). Создание расписания Прежде всего нужно задать точку старта Точкой старта проекта является дата начала выполнения работ для первой задачи «Придумать макет». В уставе зафиксированы даты начала и окончания проекта. Используя специализированное ПО, мы задаем точку старта проекта и видим предполагаемую дату окончания. Укладывается ли результат в сроки, указанные в уставе? Возможно, что полученные сроки окончания всех работ не устраивают заказчика. В этом случае удобно ввести понятие «вех». Веха – это работа с нулевой или установленной длительностью. Вехи используются при создании расписания проекта, чтобы обозначить значимый этап. Добавим в наше расписание значимые для нас вехи. Допустим, в уставе прописано, что до 3 октября необходимо согласовать с заказчиком макет, а весь проект завершить не позже 5-го. Укажем в перечне задач соответствующие вехи П.П. Мельников, Финансовый университет при Правительстве РФ

14 Сетевой анализ расписания Сетевой анализ включает в себя: анализ и выравнивание ресурсов анализ критического пути сжатие расписания (crashing и fast track) анализ Монте-Карло Анализ и выравнивание ресурсов начинается с анализа диаграммы использования ресурсов. При анализе определяется, нет ли перегрузки – не получается ли, что один и тот же разработчик должен несколько месяцев решать одновременно множество задач, работая за троих? Если да, то следует использовать «выравнивание ресурсов». Критический путь отражает самый длинный путь в нашей сетевой диаграмме и самое короткое время, за которое можно выполнить проект. Это одно из фундаментальных понятий в проектном управлении. Работы на критическом пути нельзя делать параллельно. Пример по разработке сайта был сознательно упрощен и весь состоит из критического пути. Так, мы не можем приступать к созданию главной страницы, не согласовав макет с заказчиком. Сжатие расписания всегда имеет целью ускорить выполнение работ по проекту, в том числе и путем привлечения дополнительных сотрудников. Анализ Монте-Карло – термин из теории игр. Этот вид анализа основан на задании исходных условий и дальнейшем моделировании возможных ситуаций. Осуществляется с использованием особого ПО П.П. Мельников, Финансовый университет при Правительстве РФ

15 8). Определение предельной цены проекта Предельная цена проекта (cost baseline) – это сумма себестоимости всех работ по проекту и стоимости всех резервов на непредвиденные случаи (contingency reserves). Определяется менеджером проекта. Бюджет проекта – это сумма предельной цены проекта и управленческих резервов. Определяется спонсором. Предельная цена проекта – это одна из граней тройственного ограничения. Неотъемлемым ее компонентом является стоимость резервов, которая определяется в ходе управления рисками П.П. Мельников, Финансовый университет при Правительстве РФ

16 ПОДХОДЫ К РАЗРАБОТКЕ ПО ИС Структурный (функциональный) подход к разработке ИС Сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов. Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов П.П. Мельников, Финансовый университет при Правительстве РФ

17 Принципы структурного подхода Базовыми принципами являются: принцип "разделяй и властвуй"; принцип иерархического упорядочения принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются: принцип абстрагирования - выделение существенных аспектов системы и отвлечение от несущественных; принцип непротиворечивости обоснованность и согласованность элементов системы; принцип структурирования данных данные должны быть структурированы и иерархически организованы П.П. Мельников, Финансовый университет при Правительстве РФ

18 Виды моделей, применяемых при структурном подходе к проектированию В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются: DFD (Data Flow Diagrams) - диаграммы потоков данных; SADT(Structured Analysis and Design Technique метод структурного анализа и проектирования) модели и соответствующие функциональные диаграммы; ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь". Диаграммы потоков данных и диаграммы "сущность-связь" наиболее часто используемые в CASE-средствах виды моделей. С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД). На стадии анализа и проектирования по DFD используются для описания структуры проектируемой системы ПО, при этом они могут уточняться, расширяться и дополняться новыми конструкциями. Аналогично ERD уточняются и дополняются новыми конструкциями, описывающими представление данных на логическом уровне, пригодном для последующей генерации схемы базы данных П.П. Мельников, Финансовый университет при Правительстве РФ

19 4. Объектно-ориентированный подход к разработке ПО ЭИС Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение бизнес-модели организации, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации бизнес-функций П.П. Мельников, Финансовый университет при Правительстве РФ

20 Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов: абстрагирование; инкапсуляция; модульность; иерархия; типизация; параллелизм; устойчивость П.П. Мельников, Финансовый университет при Правительстве РФ

21 Основными понятиями объектно-ориентированного подхода являются объект и класс. Объект предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов П.П. Мельников, Финансовый университет при Правительстве РФ

22 Средства объектно-ориентированного моделирования Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования. Диаграмма (Diagram) это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы П.П. Мельников, Финансовый университет при Правительстве РФ

23 Преимущества и недостатки объектно-ориентированного подхода Объектно-ориентированный подход обладает следующими преимуществами: Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей. Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем. Объектная модель естественна, поскольку ориентирована на восприятие мира так, как его воспринимает человек. К недостаткам объектно-ориентированного подхода относятся: Высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух– трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны П.П. Мельников, Финансовый университет при Правительстве РФ

24 Сравнение существующих методик В функциональных моделях (DFD-диаграммах потоков данных, SADT- диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов. Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления. При функциональном подходе объектные модели данных в виде ER-диаграмм «объект свойство связь» разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи. Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться П.П. Мельников, Финансовый университет при Правительстве РФ

25 Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые могут обращаться к атрибутам этого класса. Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов). В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше. При объектно-ориентированном подходе изменяется и принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы П.П. Мельников, Финансовый университет при Правительстве РФ

26 Для объектно-ориентированного подхода разработаны графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по наглядности представления модели пользователю-заказчику объектно- ориентированные модели явно уступают функциональным моделям. При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же предметную область. В таком случае должны использоваться комбинированные модели предметной области П.П. Мельников, Финансовый университет при Правительстве РФ

27 Процесс производства программного продукта (Software Engineering Process), также известный как процесс разработки программного обеспечения (ПО) (Software Development Process), определяет кто, что, когда и как участвует в разработке ПО. Разработка – это процесс, в котором требования пользователя превращаются в ПО. Унифицированный процесс разработки программного обеспечения (Unified Software Development Process, USDP) – описывает то, как требования реализуются в программное обеспечение. Обычно его называют Унифицированным процессом или UP. Методология моделирования определяется так называемым Унифицированным процессом (Unified Process, UP). Эта методология включает исполнителей, действия и артефакты (искусственно созданные объекты, процессы и т.п.), которые необходимо использовать, осуществить или создать для моделирования программной системы. Процесс ООП в контексте языка UML получил специальное название рациональный унифицированный процесс (Rational Unified Process, RUP). Концепция RUP и основные его элементы разработаны А. Джекобсоном в ходе его работы над языком UML. RUP (Rational Unified Process) – это коммерческая UP от IBM. Она предоставляет стандарты, инструментальные средства и другие элементы, необходимые для разработки П.П. Мельников, Финансовый университет при Правительстве РФ

28 Rational Unified Process и его содержание Суть концепции RUP заключается в последовательной декомпозиции или разбиении процесса ООАП на отдельные этапы, на каждом из которых осуществляется разработка соответствующих типов канонических диаграмм модели системы. На начальных этапах RUP строятся логические представления статической модели структуры системы, затем логические представления модели поведения, и лишь после этого физические представления модели системы. В результате RUP должны быть построены канонические диаграммы на языке UML, при этом последовательность их разработки в основном совпадает с их последовательной нумерацией.

29 Принципы RUP Rational Unified Process (RUP) методология разработки программного обеспечения, созданная компанией Rational Software. В основе RUP лежат следующие принципы: 1.Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков. 2.Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)). 3.Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. 4.Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. 5.Постоянное обеспечение качества на всех этапах разработки проекта (продукта). 6.Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам П.П. Мельников, Финансовый университет при Правительстве РФ

30 Принцип итерации В основе UP лежит понятие итерации: большой проект по разработке ПО разбивается на несколько меньших «мини-проектов», которыми легче управлять и выполнять. Каждый из этих «мини-проектов» и есть итерация. Каждая итерация включает все элементы обычного проекта по разработке ПО: планирование; анализ и проектирование; построение; интеграция и тестирование; версия для внутреннего или внешнего использования. Каждая итерация создает базовую версию, включающую в себя частично завершенную версию целевой системы и документацию проекта. В ходе последовательных итераций базовые версии наращиваются до тех пор, пока не будет создан окончательный полный вариант системы. Разница между предыдущей и последующей базовыми версиями представляет собой инкремент. Поэтому UP называют итеративным и инкрементным жизненным циклом П.П. Мельников, Финансовый университет при Правительстве РФ

31 Рабочие потоки итерации В каждой итерации определены пять основных рабочих потоков, которые определяют, что должно быть сделано и какие навыки для этого необходимы. К основным рабочим потокам относятся: определение требований - сбор данных о том, что должна делать система; анализ - уточнение и структурирование требований; проектирование - реализация требований в архитектуре системы; реализация - построение программного обеспечения; тестирование – выполняется проверка, отвечает ли реализация предъявляемым требованиям. В конце каждой итерации проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта П.П. Мельников, Финансовый университет при Правительстве РФ

32 Жизненный цикл проекта разделен на четыре фазы (стадии): Начало, Уточнение, Построение (конструирование) и Внедрение. Каждая из фаз имеет свои контрольные точки. В каждой фазе может быть одна или более итераций, в каждой итерации выполняются пять основных и любое количество дополнительных рабочих потоков. UP состоит из последовательности четырех фаз, каждая из которых завершается контрольной точкой: Начало (Inception) - цели жизненного цикла; Уточнение (Elaboration) - архитектура жизненного цикла; Построение (Construction) - базовая функциональность; Внедрение (Transition) - выпуск продукта. Одной из особенностей UP является то, что он ориентирован на цели, а не на создание поставляемых артефактов. Каждая фаза завершается контрольной точкой, состоящей из набора условий, которым надо удовлетворить, и эти условия могут включать или не включать, в зависимости от конкретных потребностей проекта, создание отдельного, готового продукта П.П. Мельников, Финансовый университет при Правительстве РФ

33 Обоснование выполнимости - может включать разработку технического прототипа с целью проверки правильности технологических решений или концептуального прототипа для проверки бизнес-требований. Разработка экономического обоснования для демонстрации того, что проект обеспечит выраженную в количественном отношении коммерческую выгоду. Определение основных требований для создания предметной области системы. Выявление наиболее опасных рисков. Основными исполнителями в данной фазе являются руководитель проекта и архитектор системы. В фазе Начало основное внимание обращено на определение требований и анализ. Тестирование обычно не применяется в данной фазе, поскольку единственными программными артефактами здесь являются прототипы, которые не будут больше нигде использоваться. Контрольной точкой фазы Начало являются Цели жизненного цикла П.П. Мельников, Финансовый университет при Правительстве РФ

34 Условия принятияПоставляемые артефакты Заинтересованные стороны согласовали цели проекта. Общее описание, определяющее основные требования, характеристики и ограничения проекта (Устав). Заинтересованные стороны определили и одобрили предметную область системы. Исходная модель прецедентов (выполненная только на 10-20%). Заинтересованные стороны определили и одобрили ключевые требования. Глоссарий проекта. Заинтересованные стороны одобрили затраты и план работы. Исходный план проекта. Руководитель проекта сформировал экономическое обоснование проекта. Экономическое обоснование. Руководитель проекта провел оценку рисков. Документ или база данных оценки рисков. Посредством технических исследований и/или создания прототипа была подтверждена выполнимость. Один или более одноразовых прототипов. Архитектура намечена в общих чертах.Документ с исходной архитектурой П.П. Мельников, Финансовый университет при Правительстве РФ

35 В фазе Уточнение основное внимание в каждом из основных рабочих потоков обращено на следующее: определение требований - детализация предметной области системы и требований; анализ - выяснение, что необходимо построить; проектирование - создание стабильной архитектуры; реализация - построение базовой версии архитектуры; тестирование - тестирование базовой версии и архитектуры. Итак, основное внимание в фазе Уточнение направлено на рабочие потоки определения требований, анализа и проектирования. Реализация приобретает значение в конце фазы при создании исполняемой базовой версии архитектуры. Контрольной точкой фазы уточнения является Архитектура жизненного цикла П.П. Мельников, Финансовый университет при Правительстве РФ

36 Условия принятияПоставляемые артефакты Создана гибкая надежная исполняемая базовая версия архитектуры. Исполняемая базовая версия архитектуры. Исполняемая базовая версия архитектуры демонстрирует, что важные риски были выявлены и учтены. Статическая UML-модель. Динамическая UML-модель. UML-модель прецедентов. Представление продукта стабилизировалось.Общее описание проекта. Оценка рисков пересмотрена.Обновленная оценка рисков. Экономическое обоснование проекта пере- смотрено и одобрено всеми заинтересованными сторонами. Обновленное экономическое обоснование проекта. Создан достаточно детальный план проекта, что обеспечило возможность сформулировать реалистичную заявку на затраты времени, денег и ресурсов в следующих фазах. Заинтересованные стороны одобрили план проекта. Проведена проверка экономического обоснования проекта согласно плану проекта. Обновленный план проекта. Экономическое обоснование проекта. Заинтересованные стороны достигли соглашения о продолжении проекта. Подписанный документ П.П. Мельников, Финансовый университет при Правительстве РФ

37 ФАЗА «ПОСТРОЕНИЕ» (CONSTRUCTION) Цель фазы - завершить определение требований, анализ и проектирование и развить исполняемую базовую версию архитектуры, созданную в фазе Уточнение, в завершенную систему. В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability). Условия принятия контрольной точки фазы Построение. Условия принятияПоставляемые артефакты Программный продукт достаточно стабилен и качественен для распространения среди пользователей. Программный продукт. UML-модель. Тестовый комплект. Заинтересованные стороны одобрили и готовы к введению программного продукта в свое окружение. Руководство для пользователя. Описание данной версии. Расхождения реальных расходов с предполагаемыми приемлемы. План проекта П.П. Мельников, Финансовый университет при Правительстве РФ

38 ФАЗА «ВНЕДРЕНИЕ» (TRANSITION) Фаза Внедрение начинается, когда завершено бета-тестирование и система окончательно развернута. Сюда относится устранение всех дефектов, обнаруженных при бета-тестировании, и подготовка к массовому выпуску программного обеспечения. Цели этой фазы: исправление дефектов; подготовка пользовательских платформ под новое программное обеспечение; настройка работоспособности программного обеспечения на пользовательских платформах; изменение программного обеспечения в случае возникновения непредвиденных проблем; создание руководств для пользователей и другой документации; предоставление пользователям консультаций; проведение послепроектного анализа. Условия принятияПоставляемые артефакты Бета-тестирование завершено, необходимые изменения сделаны и пользователи согласны с тем, что система успешно развернута. Сообщество пользователей активно использует продукт. Программный продукт. Стратегии поддержки продукта согласованы с пользователями и реализованы. План поддержки пользователя. Обновленные руководства для пользователей П.П. Мельников, Финансовый университет при Правительстве РФ