Фаза разработки модели процессов MSF подготовка лекции: А.Д. Фирсов phirsof@mail.ru контроль качества: И.В. Мозговая mir_ra@mail.ru 22.02.2004. - презентация

1 Фаза разработки модели процессов MSF подготовка лекции: А.Д. Фирсов контроль качества: И.В. Мозговая

2 SE.MSF.NET Фаза разработки 2 Вопросы по материалу предыдущих лекций Каковы промежуточные вехи фазы планирования модели процессов MSF? Опишите их? Каковы промежуточные вехи фазы планирования модели процессов MSF? Опишите их? Расскажите о трех типах проектирования в MSF. Какие UML- диаграммы чаще всего используются при концептуальном проектировании (логическом, физическом)? Расскажите о трех типах проектирования в MSF. Какие UML- диаграммы чаще всего используются при концептуальном проектировании (логическом, физическом)? Назовите основные классы метамодели UML. Как они взаимосвязаны? Назовите основные классы метамодели UML. Как они взаимосвязаны?

3 SE.MSF.NET Фаза разработки 3 План занятия 1.Фаза разработки РазработкаРазработка ТестированиеТестирование 2.Стоимостный анализ 3.Software construction по SWEBOK 4.Configuration management по SWEBOK

4 SE.MSF.NET Фаза разработки 4 Итак Итак Команда сформирована Команда сформирована Риски проанализированы и учтены Риски проанализированы и учтены Концепция проекта утверждена Концепция проекта утверждена Планы проекта утверждены Планы проекта утверждены Среды разработки и тестирования развернуты Среды разработки и тестирования развернуты А теперь - разработка А теперь - разработка

5 SE.MSF.NET Фаза разработки 5 Фаза разработки модели процессов MSF Цель - выполнить задачу описанную в спецификациях Цель - выполнить задачу описанную в спецификациях Команда сосредотачивает свои усилия на Команда сосредотачивает свои усилия на Написании кодаНаписании кода Разработке инфраструктурыРазработке инфраструктуры Разработке тестов и документацииРазработке тестов и документации Разработке стратегии продажРазработке стратегии продаж

6 SE.MSF.NET Фаза разработки 6 Ведущие ролевые кластеры по фазам ФазаВедущие ролевые кластеры Выработк а концепцииУправление продуктом Планировани е Управление программой Разработк а Разработка, Удовлетворение потребителя Стабилизац ия Тестирование, Управление выпуском Внедрени е Управление выпуском

7 SE.MSF.NET Фаза разработки 7 Задачи проектной группы на фазе разработки Ролевой кластерФокус Управление продуктомОжидания заказчика Управление программойУправление функциональной спецификацией; мониторинг проекта; доработка планов РазработкаРазработка программного кода и инфраструктуры; документирование конфигураций Удовлетворение потребителя Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн ТестированиеФункциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования Управление выпускомЧеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists)

8 SE.MSF.NET Фаза разработки 8 Вехи фазы разработки

9 SE.MSF.NET Фаза разработки 9 Веха Kонцепция подтверждена Подтверждение концепции (proof of concept) включает в себя проверку ключевых элементов решения в непроизводственной копии существующей среды. Проектная группа демонстрирует группе сопровождения и потребителям все аспекты решения с целью верификации сформулированных требований. Подтверждение концепции это не просто прототипирование и проверка технологий. Прототипы могут быть созданы достаточно быстро и просто (обычно на предыдущих фазах) для изучения возможных характеристик продукта. Они необходимы только для предварительного анализа и ни в коей мере не характеризуют качество продукта. Проверка технологий это проверка применимости в конкретных условиях тех технологий которые предполагается использовать в продукте. Подтверждение концепции – тестирование инфраструктуры решения в лабораторных условиях, близких к производственным.

10 SE.MSF.NET Фаза разработки 10 Он сказал:Поехали и махнул рукой и махнул рукой

11 SE.MSF.NET Фаза разработки 11 В результате этапа физического проектирования разработчики имеют UML-диаграммы с подробным описанием классов, которые планируется использовать в программе и набор спецификаций, описывающих функциональные требования

12 SE.MSF.NET Фаза разработки 12 Работа движется…

13 SE.MSF.NET Фаза разработки 13 Появился код interface interface uses uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs; Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs; type type TForm1 = class(TForm) TForm1 = class(TForm) procedure FormCreate(Sender: TObject); procedure FormCreate(Sender: TObject); procedure FormMouseDown(Sender: TObject; Button: TMouseButton; procedure FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Shift: TShiftState; X, Y: Integer); private private { Private declarations } { Private declarations } public public { Public declarations } { Public declarations } end; end; var var Form1: TForm1; Form1: TForm1; implementation implementation {$R *.DFM} {$R *.DFM} procedure TForm1.FormCreate(Sender : TObject); procedure TForm1.FormCreate(Sender : TObject); const const W = 36 * PI / 180; W = 36 * PI / 180; var var R, R1, R2 : HRgn; R, R1, R2 : HRgn; X, Y, I : Integer; X, Y, I : Integer; function S(A : Integer; R : Integer) : Integer; function S(A : Integer; R : Integer) : Integer; begin begin Result := round(R * sin(W * A)); Result := round(R * sin(W * A)); end; end; function C(A : Integer; R : Integer) : Integer; function C(A : Integer; R : Integer) : Integer; begin begin Result := round(R * cos(W * A)); Result := round(R * cos(W * A)); end; end; function GetStarReg(X, Y, R : Integer) : HRGN; function GetStarReg(X, Y, R : Integer) : HRGN; var var P : array[0..4] of TPoint; P : array[0..4] of TPoint; begin begin P[0] := Point(X, Y - R); P[0] := Point(X, Y - R); P[1] := Point(X - S(4, R), Y - C(4, R)); P[1] := Point(X - S(4, R), Y - C(4, R)); P[2] := Point(X - S(8, R), Y - C(8, R)); P[2] := Point(X - S(8, R), Y - C(8, R)); P[3] := Point(X - S(2, R), Y - C(2, R)); P[3] := Point(X - S(2, R), Y - C(2, R)); P[4] := Point(X - S(6, R), Y - C(6, R)); P[4] := Point(X - S(6, R), Y - C(6, R)); Result := CreatePolygonRgn(P, 5, WINDING); Result := CreatePolygonRgn(P, 5, WINDING); end; end; begin begin X := Width div 2; X := Width div 2; Y := Height div 2; Y := Height div 2; R := GetStarReg(X, Y, 150); R := GetStarReg(X, Y, 150); I := 1; I := 1; repeat repeat R1 := GetStarReg(X - S(I, 120), Y - C(I, 110), 40); R1 := GetStarReg(X - S(I, 120), Y - C(I, 110), 40); CombineRgn(R, R, R1, RGN_OR); CombineRgn(R, R, R1, RGN_OR); inc(I, 2); inc(I, 2); until I > 9; until I > 9; R1 := GetStarReg(X, Y, 30); R1 := GetStarReg(X, Y, 30); CombineRgn(R, R, R1, RGN_DIFF); CombineRgn(R, R, R1, RGN_DIFF); R1 := CreateEllipticRgn(3, 3, Width - 2, Height - 2); R1 := CreateEllipticRgn(3, 3, Width - 2, Height - 2); R2 := CreateEllipticRgn(20, 10, Width - 20, Height - 10); R2 := CreateEllipticRgn(20, 10, Width - 20, Height - 10); CombineRgn(R1, R1, R2, RGN_DIFF); CombineRgn(R1, R1, R2, RGN_DIFF); CombineRgn(R, R, R1, RGN_OR); CombineRgn(R, R, R1, RGN_OR); SetWindowRgn(Handle, R, True); SetWindowRgn(Handle, R, True); end; end; procedure TForm1.FormMouseDown(Sender: TObject; Button: TMouseButton; procedure TForm1.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Shift: TShiftState; X, Y: Integer); begin begin with Canvas do begin with Canvas do begin if Pixels[X,Y]=clRed then Form1.Close; if Pixels[X,Y]=clRed then Form1.Close; end;end;end. end;end;end.

14 SE.MSF.NET Фаза разработки 14 Разрабатываем инфраструктуру Определяем конфигурацию Определяем конфигурацию Разрабатываем скрипты Разрабатываем скрипты Внедряем инструменты автоматизации Внедряем инструменты автоматизации Определяем механизмы устранения сбоев Определяем механизмы устранения сбоев Разрабатываем систему резервного копирования Разрабатываем систему резервного копирования

15 SE.MSF.NET Фаза разработки 15 Контроль изменений В процессе работы накапливаются различные варианты готового кода В процессе работы накапливаются различные варианты готового кода Естественно, что в код и структуру могут вноситься изменения Естественно, что в код и структуру могут вноситься изменения Соответственно возникает необходимость в механизме управления этими изменениями, а также в ответственных лицах Соответственно возникает необходимость в механизме управления этими изменениями, а также в ответственных лицах

16 SE.MSF.NET Фаза разработки 16 Релиз Периодическая сборка всех элементов решения (кода), документации, средств развертывания и поддержки, которые реализованы на данный момент времени и отвечают поставленным критериям качества

17 SE.MSF.NET Фаза разработки 17 Веха внутренний релиз n Изменения вносятся пошагово Изменения вносятся пошагово Каждый релиз проходит тестирование Каждый релиз проходит тестирование Каждый релиз стабилизируется Каждый релиз стабилизируется На каждой вехе устанавливается критерий качества для релиза и порядок его определения (test case) На каждой вехе устанавливается критерий качества для релиза и порядок его определения (test case) Внутренний цикл разработки релиза Внутренний релиз n Разработка Tестирование и стабилизация Буферное время Внутренний релиз n+1

18 SE.MSF.NET Фаза разработки 18 Установите стандарты для оценки качества релизов Установите стандарты для оценки качества релизов Делайте каждый релиз максимально завершенным Делайте каждый релиз максимально завершенным Используйте практику частых сборок промежуточных версий (ежедневных билдов) Используйте практику частых сборок промежуточных версий (ежедневных билдов) Регулярно проводите code reviews Регулярно проводите code reviews Принципы использования внутренних релизов

19 SE.MSF.NET Фаза разработки 19 Преимущества использования внутренних циклов релиза Облегчение деления проекта на управляемые задачи Облегчение деления проекта на управляемые задачи Обеспечение возможности внесения изменений в план Обеспечение возможности внесения изменений в план Повышение общего качества продукта Повышение общего качества продукта Четкая формулировка краткосрочных целей Четкая формулировка краткосрочных целей

20 SE.MSF.NET Фаза разработки 20 Промежуточные билды Поскольку центром внимания фазы разработки является создание решения, проектной группе необходимо установить промежуточные вехи, помогающие определить прогресс в работе Поскольку центром внимания фазы разработки является создание решения, проектной группе необходимо установить промежуточные вехи, помогающие определить прогресс в работе Разработка ведется параллельно и сегментировано, поэтому возникает потребность в единой мере общего прогресса. Промежуточные билды предоставляют такую меру, заставляя команду разработчиков синхронизировать различные составляющие на уровне решения в целом Разработка ведется параллельно и сегментировано, поэтому возникает потребность в единой мере общего прогресса. Промежуточные билды предоставляют такую меру, заставляя команду разработчиков синхронизировать различные составляющие на уровне решения в целом В зависимости от проекта, количество промежуточных билдов и частота их создания может меняться В зависимости от проекта, количество промежуточных билдов и частота их создания может меняться Зачастую имеет смысл устанавливать вехи завершения (фиксации) графического дизайна и разработки базы данных, так как от этих составляющих многое зависит Зачастую имеет смысл устанавливать вехи завершения (фиксации) графического дизайна и разработки базы данных, так как от этих составляющих многое зависит Build A periodic assembly of all solution elements that are sufficiently complete to be included

21 SE.MSF.NET Фаза разработки 21 Ежедневные билды - "пульс" процесса разработки Каждый внутренний цикл релиза включает серии ежедневных билдов Каждый внутренний цикл релиза включает серии ежедневных билдов Ежедневный билд состоит из трех частей: Ежедневный билд состоит из трех частей: Разработка – работаРазработка – работа над заданной в распи- сании частью проекта Тестирование согласноТестирование согласно плану тестирования Валидация – проверкаВалидация – проверка соответствию критериям качества Разработка Тестирование Валидация Валидация

22 SE.MSF.NET Фаза разработки 22 Ежедневные билды MSF рекомендует как можно чаще собирать текущие версии всех компонент решения для проведения тестирования и анализа MSF рекомендует как можно чаще собирать текущие версии всех компонент решения для проведения тестирования и анализа В первую очередь разрабатывается базовая функциональность решения, и лишь затем создаются дополнительные его возможности. Разработка и тестирование ведутся непрерывно и одновременно, представляя собой параллельные процессы. Ежедневные билды служат верификацией совместимости всего разработанного программного кода и позволяют группам направлений продвигаться в своей работе к следующим итерациям разработки и тестирования В первую очередь разрабатывается базовая функциональность решения, и лишь затем создаются дополнительные его возможности. Разработка и тестирование ведутся непрерывно и одновременно, представляя собой параллельные процессы. Ежедневные билды служат верификацией совместимости всего разработанного программного кода и позволяют группам направлений продвигаться в своей работе к следующим итерациям разработки и тестирования

23 SE.MSF.NET Фаза разработки 23 Расписание рабочего дня команды создателей Windows :00 издан новый билд системы 18:00 издан новый билд системы Он устанавливается на тестовые компьютеры, на которых начинается проверка его качества (запускаются тестирующие скрипты – более 10 млн строк)Он устанавливается на тестовые компьютеры, на которых начинается проверка его качества (запускаются тестирующие скрипты – более 10 млн строк) 05:00 начинается процесс анализа результатов тестирования 05:00 начинается процесс анализа результатов тестирования Они по мере обработки помещаются на специальной веб-странице, к которой имеют доступ все члены проектной командыОни по мере обработки помещаются на специальной веб-странице, к которой имеют доступ все члены проектной команды 09:00 итоги тестирования отсылаются членам команды проекта 09:00 итоги тестирования отсылаются членам команды проекта 09:30 лидеры подкоманд начинают совещание для приоритезации багов 09:30 лидеры подкоманд начинают совещание для приоритезации багов Определяется, какие из багов должны быть устранены сегодняОпределяется, какие из багов должны быть устранены сегодня

24 SE.MSF.NET Фаза разработки 24 Расписание рабочего дня команды создателей Windows 2000 После совещания лидеров разработчики вносят изменения в свой код После совещания лидеров разработчики вносят изменения в свой код Они проводят полную перекомпиляцию локальных копий последнего билда и удостоверяются, что вносимые изменения решают поставленные задачи и не порождают новых баговОни проводят полную перекомпиляцию локальных копий последнего билда и удостоверяются, что вносимые изменения решают поставленные задачи и не порождают новых багов Лидеры подкоманд делают code review и утверждают вносимые измененияЛидеры подкоманд делают code review и утверждают вносимые изменения 15:00 заканчивается внесение утвержденных изменений в централизованное хранилище кода 15:00 заканчивается внесение утвержденных изменений в централизованное хранилище кода Начинается сборка нового билдаНачинается сборка нового билда Сразу после сборки проводится минимальное тестирование целостности бида, при необходимости – коррекция и пересборкаСразу после сборки проводится минимальное тестирование целостности бида, при необходимости – коррекция и пересборка 18:00 издан новый билд системы 18:00 издан новый билд системы

25 SE.MSF.NET Фаза разработки 25 Создание внутренних релизов с ежедневными билдами Ежедневные билды Внутренний релиз n Tестирование и стабилизация Буферное время Внутренний релиз n+1

26 SE.MSF.NET Фаза разработки 26 Code Reviews Исследование кода Исследование кода Инспекция кода Инспекция кода Анализ кода Анализ кода Проверка кода Проверка кода Обследование кода Обследование кода Обзор кода Обзор кода Изучение кода Изучение кода

27 SE.MSF.NET Фаза разработки 27 Code Review Может выполнятся формально, неформально, третьей стороной Может выполнятся формально, неформально, третьей стороной Для проекта: Для проекта: Повышение качества кодаПовышение качества кода Ускорение разработкиУскорение разработки Озвучивание неявных допущенийОзвучивание неявных допущений Для команды: Для команды: Обучение на примерахОбучение на примерах Снижение потерь от неверных решенийСнижение потерь от неверных решений Обеспечение понятности кодаОбеспечение понятности кода

28 SE.MSF.NET Фаза разработки 28 Готовый продукт должен включать: Готовый продукт должен включать: Пользовательская документация, help-файлы и т.п.Пользовательская документация, help-файлы и т.п. Графические элементы интерфейсаГрафические элементы интерфейса Методики обучения пользователей, учебные курсыМетодики обучения пользователей, учебные курсы Сценарии тестирования эргономичностиСценарии тестирования эргономичности Эти элементы решения создаются параллельно с другими его составляющими (код и т.п.) Эти элементы решения создаются параллельно с другими его составляющими (код и т.п.) Итеративный процесс разработки – много последовательно улучшающихся версий Итеративный процесс разработки – много последовательно улучшающихся версий Этот процесс синхронизируется с вехами выпуска промежуточных релизов решения Этот процесс синхронизируется с вехами выпуска промежуточных релизов решения Деятельность кластера Удовлетворение потребителя на фазе разработки

29 SE.MSF.NET Фаза разработки 29 Готовый продукт должен включать: Готовый продукт должен включать: Документация для служб сопровождения, системных администраторов и т.п.Документация для служб сопровождения, системных администраторов и т.п. Инструкции для сопровождающего персонала и служб help-deskИнструкции для сопровождающего персонала и служб help-desk Базу знаний (knowledge base) о системеБазу знаний (knowledge base) о системе Учебные материалы для подготовки сотрудников служб сопровожденияУчебные материалы для подготовки сотрудников служб сопровождения Эти элементы решения создаются параллельно с другими его составляющими (код и т.п.) Эти элементы решения создаются параллельно с другими его составляющими (код и т.п.) Итеративный процесс разработки – много последовательно улучшающихся версий Итеративный процесс разработки – много последовательно улучшающихся версий Этот процесс синхронизируется с вехами выпуска промежуточных релизов решения Этот процесс синхронизируется с вехами выпуска промежуточных релизов решения Деятельность кластера Управление выпуском на фазе разработки

30 SE.MSF.NET Фаза разработки 30 Вопросы от Microsoft What are the deliverables of the developing phase? What are the deliverables of the developing phase? Why is change control especially important during the developing phase? Why is change control especially important during the developing phase? What does developing mean, in addition to writing code? What does developing mean, in addition to writing code? How is a build more than just code compilation? How is a build more than just code compilation? What are some guidelines for conducting good code reviews? What are some guidelines for conducting good code reviews?

31 SE.MSF.NET Фаза разработки 31 Тестирование решения. Цели Проверить соответствие элементов решения спецификациям Проверить соответствие элементов решения спецификациям Выявить ошибки в проектировании Выявить ошибки в проектировании Выявить ошибки от возможных нестандартных действий пользователя Выявить ошибки от возможных нестандартных действий пользователя Протестировать все составляющие решения (не только код, но и документацию и т.п.)" Протестировать все составляющие решения (не только код, но и документацию и т.п.)" Testing – Assessing the state of quality of the solution

32 SE.MSF.NET Фаза разработки 32 Тестирование – часть жизненного цикла решения, а не одиночная активность MSF

33 SE.MSF.NET Фаза разработки 33 Управляйте ошибками Оценивайте результаты тестирования Оценивайте результаты тестирования Формализуйте процесс тестирования Формализуйте процесс тестирования Классифицируйте и расставляйте приоритеты Классифицируйте и расставляйте приоритеты Анализируйте ошибки Анализируйте ошибки

34 SE.MSF.NET Фаза разработки 34 Пример возможного процесса управления багами Resolve ClosePrioritize and Assign Report Bug Retired

35 SE.MSF.NET Фаза разработки 35 Веха Разработка завершена Эта веха является кульминацией фазы разработки. К моменту ее наступления создание всех составляющих завершено, и решение готово к тестированию и стабилизации. Заказчики, потребители, персонал сопровождения и другие заинтересованные стороны получают возможность оценить решение и выявить все оставшиеся проблемы и неурегулированные вопросы, которые должны быть улажены до выпуска решения

36 SE.MSF.NET Фаза разработки 36 Результаты фазы разработки: Исходный и исполнимый код приложений Исходный и исполнимый код приложений Скрипты установки и конфигурирования Скрипты установки и конфигурирования Окончательная функциональная спецификация Окончательная функциональная спецификация Материалы поддержки решения Материалы поддержки решения Спецификации и сценарии тестов Спецификации и сценарии тестов

37 SE.MSF.NET Фаза разработки 37 Результаты фазы разработки(2):

38 SE.MSF.NET Фаза разработки 38 План занятия 1.Фаза разработки РазработкаРазработка ТестированиеТестирование 2.Стоимостный анализ 3.Software construction по SWEBOK 4.Configuration management по SWEBOK

39 SE.MSF.NET Фаза разработки 39 На каждой фазе работы над проектом осуществляется сверка с планами и расписанием Обратите внимание на то, что у каждого ролевого кластера есть свой конкретный план работы, также следует заметить, что деятельность кластеров согласована и открыта

40 SE.MSF.NET Фаза разработки 40 Диаграмма Ганта (MS Project)

41 SE.MSF.NET Фаза разработки 41 Стоимостный анализ Earned Value analysis По ходу проекта у менеджеров и заказчиков возникает необходимость в оценке эффективности капиталовложений в проект. Для этого вводят следующие интегральные характеристики: 1.EV (Earned Value, устаревшее название – BCWP – Budgeted Cost of Work Performed) - плановая стоимость выполненных работ (ПСВР) Называется также «фактическая выработка на дату»Называется также «фактическая выработка на дату» 2.PV (Planned Value, устаревшее название BCWS Budgeted Cost of Work Scheduled) - плановая стоимость запланированных работ (ПСЗР) 3.AC (Actual Cost, устаревшее название Actual Cost of Work Performed) 3.AC (Actual Cost, устаревшее название Actual Cost of Work Performed) Фактическая стоимость выполненных работ (ФСВР)

42 SE.MSF.NET Фаза разработки 42 Время Прокомментируйте проект Средства PV EV AC

43 SE.MSF.NET Фаза разработки 43 Стоимостный анализ (продолжение) Отклонения Отклонения CV=EV-ACCV=EV-AC SV=EV-PVSV=EV-PV Индексы Индексы CPI=EV/ACCPI=EV/AC SPI=EV/PVSPI=EV/PV Бюджет Бюджет BAC (Budget at Complete) – бюджетBAC (Budget at Complete) – бюджет

44 SE.MSF.NET Фаза разработки 44 Ожидаемая стоимость Приведенные характеристики позволяют менеджерам компаний судить об отклонениях от плановых затрат и предсказывать итоговые затраты (ожидаемая стоимость, EAC) на проект, которые стоит ожидать к моменту его завершения. Есть несколько методик расчета ожидаемой стоимости: Приведенные характеристики позволяют менеджерам компаний судить об отклонениях от плановых затрат и предсказывать итоговые затраты (ожидаемая стоимость, EAC) на проект, которые стоит ожидать к моменту его завершения. Есть несколько методик расчета ожидаемой стоимости: EAC = AC + ETCEAC = AC + ETC Общая формула. ETC означает Estimate to Complete – оценка стоимости оставшихся работ Общая формула. ETC означает Estimate to Complete – оценка стоимости оставшихся работ EAC = AC + BAC – EVEAC = AC + BAC – EV Наблюдавшиеся отклонения от плана были атипичны, и не будут (как ожидается) повторятся Наблюдавшиеся отклонения от плана были атипичны, и не будут (как ожидается) повторятся EAC = AC + ((BAC – EV)/CPI)EAC = AC + ((BAC – EV)/CPI) Наблюдавшиеся отклонения от плана были типичны, и будут (как ожидается) повторятся Наблюдавшиеся отклонения от плана были типичны, и будут (как ожидается) повторятся

45 SE.MSF.NET Фаза разработки 45 Earned value analysis Earned value analysis in its various forms is the most commonly used method of performance measurement. It integrates scope, cost (or resource), and schedule measures to help the project management team assess project performance. Earned value analysis involves calculating three key values for each activity: Earned value analysis in its various forms is the most commonly used method of performance measurement. It integrates scope, cost (or resource), and schedule measures to help the project management team assess project performance. Earned value analysis involves calculating three key values for each activity: The Planned Value (PV), previously called the budgeted cost of work scheduled (BCWS), is that portion of the approved cost estimate planned to be spent on the activity during a given period The Planned Value (PV), previously called the budgeted cost of work scheduled (BCWS), is that portion of the approved cost estimate planned to be spent on the activity during a given period The Actual Cost (AC), previously called the actual cost of work performed (ACWP), is the total of costs incurred in accomplishing work on the activity during a given period. This Actual Cost must correspond to whatever was budgeted for the PV and the EV (example: direct hours only, direct costs only, or all costs including indirect costs) The Actual Cost (AC), previously called the actual cost of work performed (ACWP), is the total of costs incurred in accomplishing work on the activity during a given period. This Actual Cost must correspond to whatever was budgeted for the PV and the EV (example: direct hours only, direct costs only, or all costs including indirect costs) The Earned Value (EV), previously called the budgeted cost of work performed (BCWP), is the value of the work actually completed The Earned Value (EV), previously called the budgeted cost of work performed (BCWP), is the value of the work actually completed

46 SE.MSF.NET Фаза разработки 46 Earned value analysis (продолжение) These three values are used in combination to provide measures of whether or not work is being accomplished as planned. The most commonly used measures are: These three values are used in combination to provide measures of whether or not work is being accomplished as planned. The most commonly used measures are: the cost variance (CV= EV – AC)the cost variance (CV= EV – AC) the schedule variance (SV = EV – PV)the schedule variance (SV = EV – PV) These two values, the CV and SV, can be converted to efficiency indicators to reflect the cost and schedule performance of any project These two values, the CV and SV, can be converted to efficiency indicators to reflect the cost and schedule performance of any project the cost performance index (CPI = EV/AC) is the most commonly used cost-efficiency indicator. The cumulative CPI (the sum of all individual EV budgets divided by the sum of all individual ACs) is widely used to forecast project costs at completionthe cost performance index (CPI = EV/AC) is the most commonly used cost-efficiency indicator. The cumulative CPI (the sum of all individual EV budgets divided by the sum of all individual ACs) is widely used to forecast project costs at completion the schedule performance index (SPI = EV/PV) is sometimes used in conjunction with the CPI to forecast the project completion estimatesthe schedule performance index (SPI = EV/PV) is sometimes used in conjunction with the CPI to forecast the project completion estimates

47 SE.MSF.NET Фаза разработки 47 Estimate at completion An Estimate at Completion (EAC) is a forecast of most likely total project costs. The most common forecasting techniques are some variation of: An Estimate at Completion (EAC) is a forecast of most likely total project costs. The most common forecasting techniques are some variation of: EAC = Actuals to date plus a new estimate for all remaining work. This approach is most often used when past performance shows that the original estimating assumptions were fundamentally flawed, or that they are no longer relevant to a change in conditions. Formula: EAC = AC + ETCEAC = Actuals to date plus a new estimate for all remaining work. This approach is most often used when past performance shows that the original estimating assumptions were fundamentally flawed, or that they are no longer relevant to a change in conditions. Formula: EAC = AC + ETC EAC = Actuals to date plus remaining budget (BAC – EV). This approach is most often used when current variances are seen as atypical and the project management team expectations are that similar variances will not occur in the future. Formula: EAC = AC + BAC – EVEAC = Actuals to date plus remaining budget (BAC – EV). This approach is most often used when current variances are seen as atypical and the project management team expectations are that similar variances will not occur in the future. Formula: EAC = AC + BAC – EV EAC = Actuals to date plus the remaining project budget (BAC – EV) modified by a performance factor, often the cumulative cost performance index (CPI). This approach is most often used when current variances are seen as typical of future variances. Formula: EAC = AC + ((BAC – EV)/CPI)this CPI is the cumulative CPIEAC = Actuals to date plus the remaining project budget (BAC – EV) modified by a performance factor, often the cumulative cost performance index (CPI). This approach is most often used when current variances are seen as typical of future variances. Formula: EAC = AC + ((BAC – EV)/CPI)this CPI is the cumulative CPI

48 SE.MSF.NET Фаза разработки 48 План занятия 1.Фаза разработки РазработкаРазработка ТестированиеТестирование 2.Стоимостный анализ 3.Software construction по SWEBOK 4.Configuration management по SWEBOK

49 SE.MSF.NET Фаза разработки 49 Software construction Software construction – создание программистом действующего, содержательного программного обеспечения, объединяющее кодирование, валидацию и тестирование (unit testing). Далекое от простой механической трансляции хорошего проекта в работающий программный продукт, software construction глубинный процесс в океане software engineering.

50 SE.MSF.NET Фаза разработки 50 Какой же мастер без инструмента Software construction tools (SCT) более широкий набор инструментов чем просто программы использующиеся непосредственно в процессе разработки. В SCT входят компиляторы, системы версионирования, отладки, генераторы кода, специализированные редакторы, системы анализа связей и документирования.

51 SE.MSF.NET Фаза разработки 51 Принципы разработки Уменьшение сложности (Reduction of Complexity) Уменьшение сложности (Reduction of Complexity) УстранениеУстранение АвтоматизацияАвтоматизация ЛокализацияЛокализация Ожидание нововведений ( Anticipation of Diversity ) Ожидание нововведений ( Anticipation of Diversity ) ОбобщениеОбобщение ЕкспериментЕксперимент ЛокализацияЛокализация Структурирование для проверки Структурирование для проверки ( Structuring for Validation ) Использование внешних стандартов Использование внешних стандартов ( Use of External Standards )

52 SE.MSF.NET Фаза разработки 52 Sоftware construction – три метода Лингвистический Лингвистический Формальный Формальный Визуальный Визуальный

53 SE.MSF.NET Фаза разработки 53 Для каждого из принципов применимы три метода

54 SE.MSF.NET Фаза разработки 54 Лингвистические методы Шаблоны проектирования ( Design patterns ) Шаблоны проектирования ( Design patterns ) Моделирование ( Software templates ) Моделирование ( Software templates ) Использование функций, процедур и блоков кода Использование функций, процедур и блоков кода Использование объектов и структур данных Использование объектов и структур данных Инкапсуляция и использование абстрактных типов Инкапсуляция и использование абстрактных типов Использование библиотек компонентов Использование библиотек компонентов Использование высокоуровневых и специализированных языков Использование высокоуровневых и специализированных языков Физическая организация кода Физическая организация кода Использование файлов и библиотек Использование файлов и библиотек Использование синтаксического анализа Использование синтаксического анализа Reduction in Complexity

55 SE.MSF.NET Фаза разработки 55 Формальные методы Использование функций и процедур Использование функций и процедур Функциональное программирование Функциональное программирование Логическое программирование Логическое программирование Использование техник конкурентного и экстремального программирования Использование техник конкурентного и экстремального программирования Spreadsheets Spreadsheets Использование генераторов программ Использование генераторов программ Использование библиотек математических функций Использование библиотек математических функций Reduction in Complexity

56 SE.MSF.NET Фаза разработки 56 Визуальные методы Объектно-ориентированное программирование Объектно-ориентированное программирование Визуальная разработка интерфейса Визуальная разработка интерфейса Визуальное программирование Визуальное программирование Визуальное форматирование Визуальное форматирование Использование сред разработки Использование сред разработки Reduction in Complexity

57 SE.MSF.NET Фаза разработки 57 Лингвистические методы Недокументированные возможности Недокументированные возможности (Information hiding ) Использование комментариев Использование комментариев Использование подхода необходимо и достаточно Использование подхода необходимо и достаточно Объектно-ориентированное программирование Объектно-ориентированное программирование Создание связанных языков Создание связанных языков Использование таблично-управляемого ПО Использование таблично-управляемого ПО Интернационализация Интернационализация Использование системы имен (венгерская нотация) Использование системы имен (венгерская нотация) Повторное использование кода Повторное использование кода Self-describing software and hardware Self-describing software and hardware (e.g., plug and play) Anticipation of Diversity

58 SE.MSF.NET Фаза разработки 58 Формальные методы Функциональная параметризация Функциональная параметризация Макро-параметризация Макро-параметризация Generics (заменители) Generics (заменители) Объектно-ориентированное проектирование Объектно-ориентированное проектирование Error handling (обработка ошибок) Error handling (обработка ошибок) Расширяемые математические структуры Расширяемые математические структуры Anticipation of Diversity

59 SE.MSF.NET Фаза разработки 59 Визуальные методы Классы объектов Классы объектов Visual configuration specification Visual configuration specification Объединение дизайна и функциональной реализации на стадии проектирования Объединение дизайна и функциональной реализации на стадии проектирования Anticipation of Diversity

60 SE.MSF.NET Фаза разработки 60 Лингвистические методы Модульное проектирование Модульное проектирование Структурное программирование Структурное программирование Оформление (Style guides) Оформление (Style guides) Поэтапное усовершенствование (Stepwise refinement) Поэтапное усовершенствование (Stepwise refinement) Structuring for Validation

61 SE.MSF.NET Фаза разработки 61 Формальные методы Теоретически обоснованное программирование (static and dynamic) Теоретически обоснованное программирование (static and dynamic) Учет машинной логики Учет машинной логики Введение избыточности в систему, самодиагностика, и самосохранение Введение избыточности в систему, самодиагностика, и самосохранение Анализ критических структур в коде и улучшение быстродействия Анализ критических структур в коде и улучшение быстродействия Численный анализ Численный анализ Structuring for Validation

62 SE.MSF.NET Фаза разработки 62 Визуальные методы Использование подходанеобходимо и достаточно при разработке классов Использование подходанеобходимо и достаточно при разработке классов Динамическая проверка визуальных запросов в визуальных языках ( валидаторы в WebMatrix ) Динамическая проверка визуальных запросов в визуальных языках ( валидаторы в WebMatrix ) Structuring for Validation

63 SE.MSF.NET Фаза разработки 63 Лингвистические методы Стандартизированные языки программирования (e.g., Ada 95, C++, etc.) Стандартизированные языки программирования (e.g., Ada 95, C++, etc.) Стандартизированные языки описания данных (e.g., XML, SQL) Стандартизированные языки описания данных (e.g., XML, SQL) Стандартизированные таблицы символов (e.g., Unicode) Стандартизированные таблицы символов (e.g., Unicode) Стандартизированный документооборот (e.g., JavaDoc) Стандартизированный документооборот (e.g., JavaDoc) Использование стандартов межпроцессного взаимодействия (e.g., COM, CORBA) Использование стандартов межпроцессного взаимодействия (e.g., COM, CORBA) Использование компонентного подхода Использование компонентного подхода Использование базовых классов (e.g., MFC, JFC) Использование базовых классов (e.g., MFC, JFC) External Standards

64 SE.MSF.NET Фаза разработки 64 Формальные методы Стандарты прикладной программной среды Стандарты прикладной программной среды Стандарты передачи данных Стандарты передачи данных Стандарты интерфейсов устройств Стандарты интерфейсов устройств Стандартизированные математические языки (e.g., MathML) Стандартизированные математические языки (e.g., MathML) Библиотеки математических функций Библиотеки математических функций External Standards

65 SE.MSF.NET Фаза разработки 65 Визуальные методы Стандарты на объектно- ориентированные языки Стандарты на объектно- ориентированные языки Standardized screen widgets (украшения) Standardized screen widgets (украшения) Визуальные языки разметки Визуальные языки разметки External Standards

66 SE.MSF.NET Фаза разработки 66 План занятия 1.Фаза разработки РазработкаРазработка ТестированиеТестирование 2.Стоимостный анализ 3.Software construction по SWEBOK 4.Configuration management по SWEBOK

67 SE.MSF.NET Фаза разработки 67 Configuration management (CM) Конфигурация системы – набор функциональных или физических характеристик технических и программных средств или их комбинаций, выраженных в технической документации и реализованных в конечном продукте. Также можно сказать, что это множество версий программного или аппаратного обеспечения и их комбинаций реализующих заданную функциональность Конфигурация системы – набор функциональных или физических характеристик технических и программных средств или их комбинаций, выраженных в технической документации и реализованных в конечном продукте. Также можно сказать, что это множество версий программного или аппаратного обеспечения и их комбинаций реализующих заданную функциональность Соответственно существует дисциплина, которая позволяет идентифицировать конфигурацию системы в определенных точках для систематического контроля изменений конфигураций, поддержки интеграции и отслеживаемости конфигураций в период жизненного цикла системы. CM формально определено IEEE как: A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. Соответственно существует дисциплина, которая позволяет идентифицировать конфигурацию системы в определенных точках для систематического контроля изменений конфигураций, поддержки интеграции и отслеживаемости конфигураций в период жизненного цикла системы. CM формально определено IEEE как: A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

68 SE.MSF.NET Фаза разработки 68 Легенда Проблема отсутствия должного конфигурационного управления неожиданно проявилась в погоне за успешный запуск опытного образца ракеты в 50-х годах. Будучи, как всегда, в жестких временных рамках, разработчики упростили и ускорили проведение изменений по устранению несовместимости частей ракеты, поставляемых многочисленными контрагентами. Когда, в итоге, был произведен успешный пуск, и представитель заказчика в эйфории сказал : "Постройте ка мне еще одну такую же штуку!", промышленники обнаружили себя в интересном положении: 1. Опытный образец отсутствует - (улетел). 2. Другой такой же экземпляр собрать не представляется возможным по причине отсутствия точной ведомости элементов (реальной конфигурации), хронологии проведения изменений и сведений об их завершенности.

69 SE.MSF.NET Фаза разработки 69 Виды SCM деятельности ( activities )

70 SE.MSF.NET Фаза разработки 70 Управление SCM процессами Определение структуры и связей (Organizational Context for SCM ) Constraints and Guidance for SCM (ISO, SEI/CMM) Планирование Назначение ответственных Анализ ресурсов и составление расписаний Выбор и внедрение инструментов Учет деятельности субподрядчиков Software Configuration Management Plan (Документ N1) 1. Введение (purpose, scope, terms used) 2. Управление (ответственные, авторы, инструкции и т.п.) 3. Деятельности 4. Расписания 5. Ресурсы (инструменты, средства, люди) 6. Поддержка Инспектирование Выбор критериев и проверка следованию Промежуточный аудит (In-process Audits)

71 SE.MSF.NET Фаза разработки 71 Определение конфигурации Идентификация единиц контроля Software Configuration - набор конкретных версий технических, программных и программно-технических частей системы, объединенных в соответствии с конкретными процедурами сборки для достижения конкретной цели Единица конфигурации (Software Configuration Item) Определение связей между единицами конфигурации Версионирование Baseline (Конфигурационный базис) - набор формально рассмотренной и утвержденной конфиграционной документации, устанавливающей согласованную основу для дальнейшего развития или разработки системы Исполнение Software Library Программа Документация

72 SE.MSF.NET Фаза разработки 72 Критерии выделения контролируемых единиц конфигурации независимая конечная функция; независимая конечная функция; необходимость в индивидуальном контроле или независимом эффективном управлении изменениями; необходимость в индивидуальном контроле или независимом эффективном управлении изменениями; компонента используется в нескольких системах/подсистемах; компонента используется в нескольких системах/подсистемах; компонента является интерфейсом между несколькими системами/подсистемами; компонента является интерфейсом между несколькими системами/подсистемами; имеется требование о взаимозаменяемости компонент данного уровня (например - между различными версиями или вариантами продукта); имеется требование о взаимозаменяемости компонент данного уровня (например - между различными версиями или вариантами продукта); имеется требование об индивидуальной поставке и /или установке компоненты; имеется требование об индивидуальной поставке и /или установке компоненты; наличие индивидуально определенных характеристик и требований по тестированию; наличие индивидуально определенных характеристик и требований по тестированию; разработка данной компоненты связана со значительным риском и требует индивидуального повышенного внимания со стороны руководства проектом разработка данной компоненты связана со значительным риском и требует индивидуального повышенного внимания со стороны руководства проектом

73 SE.MSF.NET Фаза разработки 73 Управление изменениями Requesting, Evaluating and Approving Software Changes Software Configuration Control Board Руководящий совет по конфигурационному контролю Software Change Request Process Формальная обработка запросов на изменение Внесение изменений Deviations and Waivers (Управление дефектами и отклонениями)

74 SE.MSF.NET Фаза разработки 74 Учет статуса конфигурации ( SC Status Accounting ) - это регистрация и предоставление информации для эффективного конфигурационного управления Сбор информации Анализ и отчет Примерами количественных оценок производительности и качества работ по проекту, формируемых в системе учета статуса конфигурации, могут служить сводные отчеты о количестве обнаруженных и исправленных дефектов, поступивших и реализованных запросов на изменения, динамике внесения изменений в конфигурацию продукта во времени и прочее, и прочее

75 SE.MSF.NET Фаза разработки 75 Аудит конфигурации - activity performed to independently evaluate the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures производится непосредственно перед выходом новой версии продукта, его части, патча или обновления за пределы организации -разработчика, т.е. практически всегда исходит из ответственности момента по тем или иным обязательствам перед Заказчиком Функциональный аудит конфигурации : подтверждение соответствия фактических характеристик конфигурации /единиц конфигурации продукта предъявляемым требованиям Физический аудит конфигурации: подтверждение взаимного соответствия документации и фактической конфигурации продукта Промежуточный аудит

76 SE.MSF.NET Фаза разработки 76 Software Release Management and Delivery Software Building activity of combining the correct versions of software items, using the appropriate configuration data, into an executable program for delivery to a customer or other recipient, such as the testing activity Software Release Management encompasses the identification, packaging and delivery of the elements of a product, for example, the executable, documentation, release notes, and configuration data

77 SE.MSF.NET Фаза разработки 77 Заключение Теперь Вы знаете Как подготовиться к фазе разработки Как подготовиться к фазе разработки Зачем нужны ежедневные билды Зачем нужны ежедневные билды Как тестировать код Как тестировать код Как разрабатывать документацию Как разрабатывать документацию Цель, вехи и результаты фазы разработки Цель, вехи и результаты фазы разработки Еще два раздела из SWEBOK Еще два раздела из SWEBOK

78 SE.MSF.NET Фаза разработки 78 В качестве фона к слайдам использовано изображение космического аппарата Океан- О. Такие спутники изготавливает расположенный в Днепропетровске завод ЮМЗ