1 Менеджмент разработки программных изделий (руководство командой и управление проектом) И.Н. Скопин Основы менеджмента программных проектов. Курс лекций. - презентация

1 1 Менеджмент разработки программных изделий (руководство командой и управление проектом) И.Н. Скопин Основы менеджмента программных проектов. Курс лекций. Учебное пособие // М.: ИНТУИТ.РУ «Интернет-Университет Информационных технологий», с.

2 Содержание 1.Введение. Основные понятия. Функции и роли разработчиков программных проектов. Ключевые роли. Подбор кадров. Принцип осмысленности действий 2.Принципы построения системы деятельностей программного проекта 3.Жизненный цикл программного обеспечения и его модели 4.Производственные функции в моделировании жизненного цикла: модель фазы функции 5.Моделирование жизненного цикла объектно-ориентированных программных проектов 6.Технологические аспекты развития программных систем в моделях жизненного цикла 7.Особенности первой итерации объектно-ориентированного программного проекта 8.Жизненный цикл в методологиях быстрого развития проектов 9.Проблемы оперирования требованиями 10.Методическая поддержка оперирования требованиями. Примеры: работа с резюме, прием на работу 11.Результативность программистской проектной деятельности 12.Управление рисками 13.Организация коллективной работы 14.Взаимодействия разработчиков проекта 15.Конфликты в проектном коллективе 16.Планирование и контроль развития проекта 2

3 3 1.Введение. Основные понятия. Функции и роли разработчиков программных проектов. Ключевые роли. Подбор кадров

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

5 5 Исполнители Группы исполнителей Менеджер проекта Группа менеджеров по направлениям Служба менеджера Схема с одним менеджером Схема со службой менеджера Схема с группой менеджеров по направлениям Менеджер проекта Зависимость от масштаба проекта. Другие варианты схем Три схемы организации менеджмента проекта

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

7 Проектная деятельность и ее исполнители Проект нацелен на удовлетворение потребности автоматизации некоторой пользовательской деятельности проектная деятельность включена в систему деятельностей. В какую систему? Неполный ответ: –Автоматизируемая пользовательская деятельность + Изучение пользовательской потребности –Поставка пользователю оборудования и программного продукта –Обучение и поддержка пользователя + Разработка системы (реализация, разработка проекта) + Планирование и управление проектом –…–… Каким образом связаны деятельности системы? (Одна деятельность использует результаты другой, но не только это) Коллективность проектной деятельности распределение обязанностей между исполнителями, согласование работ и контроль их выполнения, планирование и корректировка планов, многое другое Производственная функция проекта – выделенная и локализованная в проекте деятельность, выполнение которой необходимо для развития проекта с целью получения результата, используемого в других деятельностях Исполнитель проекта – работник, выполняющий назначенные для него производственные функции Роль – совокупность различных требований к работнику, необходимых и достаточных для выполнения им определенных производственных функций Обязательные составляющие проектной деятельности отмечены «+» 7 Вопрос к слушателям: 1. В какую систему включена проектная деятельность? Предложите свои варианты системы деятельностей Обоснуйте каждый из них Вопрос к слушателям: 1. В какую систему включена проектная деятельность? Предложите свои варианты системы деятельностей Обоснуйте каждый из них Вопрос к слушателям: 2.А как еще могут быть связаны деятельности? Вопрос к слушателям: 2.А как еще могут быть связаны деятельности? Вопрос к слушателям: 3.Раскройте самостоятельно «многое другое» Вопрос к слушателям: 3.Раскройте самостоятельно «многое другое» Вопрос к слушателям: 4.Являются ли производственными функциями деятельность «Обед исполнителя»? деятельность уборщицы? Вопрос к слушателям: 4.Являются ли производственными функциями деятельность «Обед исполнителя»? деятельность уборщицы?

8 8 Декомпозиция проектной деятельности Проект большая производственная функция, выполнение которой требует осуществления многих различных деятельностей. Деятельности проекта взаимосвязаны, нуждаются в планировании, обеспечении ресурсами и др. От существования многих из них приходится абстрагироваться (несущественные?) Организованность совокупности проектных и внешних (косвенно связанных с проектом) деятельностей должна быть достигнута! Для построения нужной организованности применяются методологии развития проектов. Среди прочего они решают задачу декомпозиции. Это одно из назначений методологии. А какие они бывают? Производственные функции и исполнители как декомпозируемые сущности –можно структурировать выполнение функции, разбивая ее на составляющие, определяя назначение каждой из составляющих и связи между ними так, чтобы результат совместного выполнения совпадал с требуемым результатом разбиваемой функции –можно структурировать обобщенного исполнителя, иными словами, конкретизировать исполнителей, отвечающих за разные аспекты выполнения функции Оба разбиения допускают продолжение в глубину: –для исполнителей до конкретных индивидуумов –для функций до неделимых единиц действий

9 9 Элементы деятельностей Субъект: программисты, выполняющие проект, и др., инициаторы работ Субъект: программисты, выполняющие проект, и др., инициаторы работ Материалы и ресурсы: требования к программной системе, оборудование, вспомогательные ресурсы Материалы и ресурсы: требования к программной системе, оборудование, вспомогательные ресурсы Результат: программная система, документация к ней, методика работы, тесты, учебные материалы и др. Результат: программная система, документация к ней, методика работы, тесты, учебные материалы и др. Цель: решение проблем поль-зователя путем автоматизации его деятель- ности Цель: решение проблем поль-зователя путем автоматизации его деятель- ности Методы: стратегии развития, методологии, регламенты и соглашения Методы: стратегии развития, методологии, регламенты и соглашения кто в состоянии выполнять деятельность для чего выполняется деятельность из чего продуцируются результаты деятельности указывают на то, как выполнять деятель- ность фактически продуцируется в деятельности для чего выполняется деятельность Сопоставление цели и результата деятельности важная составляющая оценивания проектной деятельности (оценочная деятельность) Средства и инструменты: системы про- граммирования, библиотеки, CASE-средства Средства и инструменты: системы про- граммирования, библиотеки, CASE-средства с помощью чего продуцируются результаты деятельности Средства и инструменты и методы можно рассматривать совместно (но для нас полезно их разделять)

10 10 Любая деятельность есть часть некоторой общей системы деятельностей, охватывающей группу субъектов-исполнителей. Деятельности, субъекты которых не попадают в выделенную группу, являются окружением данной системы. Окружение связано с системой следующими способами: –из окружения поставляются элементы деятельностей системы; –деятельностям окружения передаются результаты деятельностей системы; –система в целом и ее отдельные деятельности являются элементами деятельностей окружения Системы деятельностей Субъект Д Материалы Результат Цель Методы Средства … … … Вопросы к слушателям: 1.А как это связано с исполнителями проекта? 2.В каких деятельностях они участвуют и в каком качестве? Соотнесите свои ответы с понятием роли Д2Д2 Субъект Материалы Цель МетодыСредства Результат Средства Результат Цель Результат Материалы Цель МетодыСредства Д1Д1 Субъект Результат Субъект Результат Субъект Материалы Цель МетодыСредства Д3Д3 Результат …

11 11 Деятельность менеджера и составляющие системы проектных деятельностей Цель направление других проектных деятельностей так, чтобы они продвигали проект к выполнению (задаваемых вне системы) работ в условиях ограничений по времени, финансам и качеству = достижение целей деятельности, задающей проект в целом. Согласование параметров проекта: объем работ, сроки, запрашиваемые финансы (внешняя по отношению к работам проекта деятельность) Менеджмент проекта обеспечение предоставления продукта для его использования, разработка которого –требует выполнения определенного объема работ область действия, –использует затраты (в определенных пределах) ресурсы, –старается укладываться в заданные рамки времени план-график работ, и должна удовлетворять приемлемому уровню качества. Это хорошо известный треугольник менеджмента «хорошо-быстро- дешево»: из трех параметров выбери два получишь третий! Задание: 1. Конкретизировать элементы деятельности менеджера и их связи с другими деятельностями; 2. Сопоставить свой результат с полученным другими; 3. Объяснить различия.

12 12 Треугольник менеджмента проектов иллюстративная модель В р е м я В ы е п о л н н и е Ресурсы О б ь л а с т д е й с т в и й П л а н - г р а ф и к Качество Затраты X Y Z x min x-x- x+x+ x max x*x* Другие подобные модели см. в книге

13 13 Несколько методических положений Делегирование полномочий инструмент разделения труда (не только менеджера) Персонифицированная и деперсонифицированная ответственность Абстрактное действующее лицо и конкретный сотрудник Виды деятельности: –продукционная деятельность (производство результата, нужного для проекта) –управляющая деятельность (производство траектории развития) –наблюдательная деятельность (производство познавательного результата) Три варианта целей разработки программного обеспечения: –производство программ, прямо не связанное с получением дохода –производство рыночного продукта –производство программ под заказ Главная и постоянная задача менеджмента проекта: продвижение проекта к получению результатов, обозначенных в начале развития проекта как его цели Роль заказчика, пусть даже лишь виртуального очень значительна!

14 Типовые функции (кодирование, анализ требований, тестирование, отладка и т.д.) –Распределение функций между разработчиками проекта роли исполнителей (объединение родственных функций) –Поручения разовые или систематические задания, из которых складываются действия, необходимые для выполнения функции Технологичные функции такие, для которых –определен регламент выполнения (как последовательность заданий), –этот регламент не требует дополнительных разъяснений для исполнителя (зависят от исполнителей, не путать с технологией!) Функции подразделяются на –организационные создают условия для выполнения проектных заданий –производственные непосредственно связаны с выполнением этих заданий Участники разработки и функциональные роли в коллективе разработчиков Этапы развития проекта жизненный цикл (программного изделия) Задача менеджмента: в части управления – организационно-управленческая деятельность, поддерживающая процесс разработки программного изделия на всех этапах его жизненного цикла (возможность методов, методик, методологий и технологий) в части руководства – искусство взаимодействовать с людьми (возможность методов, методик, но не методологий и технологий) 14 Функции, выполняемые разработчиками проекта

15 Задача обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции: управление проектом, выработка архитектуры решения, контроль производственного процесса, административные службы. Задача построение решения в соответствии со спецификацией. Области компетенции кластера: технологическое консультирование, проектирование и осуществление реализации, разработка приложений, разработка инфраструктуры. Задача одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Области компетенции кластера: разработка тестов, отчетность о тестах, планирование тестов. Задача повышение эффективности использования продукта. Области компетенции кластера: общедоступность, интернационализация, обеспечение технической поддержки, обучение пользователей, удобство эксплуатации (эргономика), графический дизайн. Задача обеспечение эффективного использования продукта. Области компетенции кластера: инфраструктура, сопровождение, бизнес-процессы, управление выпуском готового продукта. 15 Ролевые кластеры модели проектной группы MSF Ключевая цель кластера обеспечивать удовлетворение заказчика. Для ее достижения кластер должен содержать области компетенции: планирование продукта, планирование доходов, представление интересов заказчика, маркетинг.

16 Вне проекта Заказчик (Customer) Планировщик ресурсов (Planner) Проектная группа (коллектив разработчиков) Менеджер проекта(Project Manager) Руководитель команды(Team Leader) Архитектор (Architect) Проектировщик подсистемы (Designer) Разработчик (Developer) Разработчик информационной поддержки (Information Developer) Специалист по пользовательскому интерфейсу (Human Factors Engineer) Эксперт предметной области(Domain Expert) Тестировщик(Tester) Библиотекарь(Librarian) Катализатор(Сatalyst) Функциональные роли в программном проекте 16 внешняя роль административная роль руководитель проекта проектировщики разработчики эксперты обслуживающий персонал неявные функции

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

18 18 Совмещение ролей в программном проекте Менеджер и архитектор Менеджер и руководитель команды Руководитель команды и проектировщик п/с Менеджер и разработчик Различные разработчиков Разработчики документации (все работники) Специалист по интерфейсу и менеджер Эксперт предметной области и менеджер Специалист по интерфейсу и эксперт предметной области Эксперт предметной области и разработчик Специалист по интерфейсу и разработчик Библиотекарь и один из разработчиков Тестировщики и другие члены команды –желательно –противоречиво –нежелательно –не допускается –обычное дело –распределяется –разумно –зачастую разумно –редко бывает эффективно –бывает полезно –часто полезно –допустимо –только перекрестно Программист один разрабатывает проект для себя предельный случай полного совмещения Заказчик и планировщик с другими ролями экзотика Игра Давайте угадаем, что будет написано справа от указанных пар ролей; посмотрим и сравним с вашими ответами; поспорим. Соглашаться никто не обязан! Сделаем выводы самостоятельно!

19 19 Лидер коллектива один из работников ключевых ролей или сам менеджер Ситуации, в которых действует менеджер при подборе кадров Менеджерский коллектив потенциальных исполнителей недостаточен: среди его сотрудников не все обладают нужной квалификацией; Лидер есть В поле зрения менеджера есть независимые потенциальные исполнители, из которых можно сформировать коллектив для работы над проектом; Лидера нет Менеджеру приходится прибегать к найму рабочей силы со стороны. Лидера нет Лидер есть У менеджера есть коллектив потенциальных исполнителей, готовый приступить к работе над проектом; Задача поиска лидера

20 20 Решение задачи определения кадровых ресурсов проекта Кадровые потребности проекта Оценка распределения кадровых потребностей по времени Возможности подбора кадров на проект График привлечения сотрудников к проекту Критические ролевые позиции проекта Заполнение вакансий До официального начала выполнения проекта Утверждение кадровой политики проекта По мере необходимости в ходе выполнения проекта Задача определения кадровых ресурсов проекта никогда не может быть решена окончательно!

21 Тренинг: когда возможно, чтобы > 3 или < 3? Ответ:Параллельно выполняемые работы Командная деятельность лучший пример такой работы, При условии слаженности коллективных действий и эффективного их распараллеливания три исполнителя выполнят больше, чем они выполнили бы поодиночке, т.е > 3, иначе = 3 или даже < 3 Эффекту роста производительности способствуют кооперация и специализация (учет квалификации, склонностей и пр.) Для организации коллективной работы необходимы: –Определение функций, необходимых для выполнения работы –Определение ролей, назначаемых исполнителям –Правильное распределение ролей –Планирование деятельности –Четкое следование плану –Своевременная корректировка отклонений от траектории целевой деятельности 21

22 Вычислительная машина на человеческой элементной базе Задача из истории: во Франции в связи с переходом на метрическую систему требовалось точно и как можно быстрее пересчитать по известным формулам артиллерийские поправки прицеливания на дальность, ветер и др. Условие: Много формул, типов оружия, результаты нужны как можно скорее Карно предложил использовать две роты солдат, каждому из которых поручено выполнять одну арифметическую операцию с аргументами, получаемыми от соседей, и передавать результат одному из них. В каждой роте было выделено по три группы солдат: 1) для приема входных данных, 2) для счета, 3) для вывода Это действительно вычислительная машина (не арифмометр!)), у которой в «памяти» записана программа, каждый элемент «памяти» активен, когда появляются входные данные: р аспределенные вычисления, управление потоками данных, высокая степень параллелизма, защита от сбоев Общая задача для каждой группы участников: –Написать программу для проведения вычислительных расчетов (любую!) –Выполнить два варианта расчетов с заданной точностью 22

23 Условия, правила и соглашения игры Соревноваться будут N команд (~ 4 – 5 человек). N+1-ая команда – наблюдатели (следят за соблюдением правил, собирают материал для анализа, готовят итоговый отчет) 1.5 минут: Определить N лидеров. Результат – имена лидеров 2.15 минут: Лидер подбирает исполнителей. Результат – списки команд и их исполнителей 3.10 минут: Первичное определение ролей (любое!) и распределе-ние их между исполнителями в команде. Результат – N ролей 4.5 минут: предъявление задачи. Результат – понимание задания 5.15 минут + перерыв (10 минут): Коллективно написать программу решения предъявленной задачи. Откорректировать роли и их распределение. Результат – N откорректированных ролей и их распределения N программ 6.< 25 минут: Соревнование на скорость: проведение расчетов для двух комплектов входных данных. Неверные ответы – дисквалифи-кация команды. Наблюдатели анализируют процесс. Результат: N*2 комплектов полученных данных + список команд, упорядочен-ных по времени выполнения минут: Итоговый анализ результатов игры. 23

24 Задача для коллективного решения Любым способом решить систему уравнений с точность до двух знаков после запятой: ax + by = e cx + dy = f для трех комплектов входных данных (три последовательности, каждая из 6 чисел : a 1 b 1 c 1 d 1 e 1 f 1, a 2 b 2 c 2 d 2 e 2 f 2 и a 3 b 3 c 3 d 3 e 3 f 3 ). Решение складывается из следующих этапов: 1.Составление программы. Метод, алгоритм, язык, распределение вычислений по исполнителям, а также роли и распределение ролей выбираются коллективно и утверждаются лидером команды. Время выполнения этапа ограничено! 2.Счет I. Получение данных выполнение программы передача результата наблюдателям. Если результат неверен, команда выбывает из игры 3.Счет II. Получение данных выполнение программы передача результата наблюдателям. Если результат неверен, команда выбывает из игры 4.Счет III. Получение данных выполнение программы передача результата наблюдателям. Если результат неверен, команда выбывает из игры При нарушении условий, правил и соглашений игры команда дисквалифицируется Оцениваются (критерий1 > критерий 2 > критерий 3): –суммарное время выполнения этапов 2 и 3 – критерий 1 (основной); –степень загруженности исполнителей при выполнении этапов 2 и 3 – критерий 2; –качество определения ролей и их распределения (предварительного и окончательного) – критерий 3; 24

25 Задача для коллективного решения Любым способом решить систему уравнений с точность до двух знаков после запятой: ax + by + cz = pdx + ey + fz = qgx + hy + iz = r для входных данных, состоящих из трех последовательностей по 12 чисел: a 1 b 1 c 1 d 1 e 1 f 1 g 1 h 1 i 1 p 1 q 1 r 1, a 2 b 2 c 2 d 2 e 2 f 2 g 2 h 2 i 2 p 2 q 2 r 2, a 3 b 3 c 3 d 3 e 3 f 3 g 3 h 3 i 3 p 3 q 3 r 3. Решение складывается из следующих этапов: 1.Составление программы. Метод, алгоритм, язык, распределение вычислений по исполнителям, а также роли и распределение ролей выбираются коллективно и утверждаются лидером команды. Время выполнения этапа ограничено! 2.Счет I. Получение данных выполнение программы передача результата наблюдателям. Если результат неверен, команда выбывает из игры 3.Счет II. Получение данных выполнение программы передача результата наблюдателям. Если результат неверен, команда выбывает из игры 4.Счет III. Получение данных выполнение программы передача результата наблюдателям. Если результат неверен, команда выбывает из игры При нарушении условий, правил и соглашений игры команда дисквалифицируется Оцениваются (критерий1 > критерий 2 > критерий 3): –суммарное время выполнения этапов 2 и 3 – критерий 1 (основной); –степень загруженности исполнителей при выполнении этапов 2 и 3 – критерий 2; –качество определения ролей и их распределения (предварительного и окончательного) – критерий 3; 25

26 26 Принцип осмысленности действий Принцип: всякий раз, когда работнику приходится выполнять какую-либо работу, он должен четко осознавать, зачем он это должен делать и делает Почему он далеко не всегда выполняется? Подмена целей –Тот, от кого исходит предложение или приказ, скорее всего, осознает, зачем ему это нужно –Но надо еще сопоставить свое «зачем» с системой целей и приоритетов работника, которая, очевидно, не совпадает с его целями. –Предлагающий работу часто полагает, что это не так, и он может быть искренне убежден, что, раз уж работнику объяснили нечто, он это обязательно воспринял, и обязательно будет соблюдать предписанные правила. Осмысленность и целенаправленность –Целенаправленность: цель действий определена и известна работнику –Осмысленность: соответствие целей задания (внешних) внутренним целям и установкам (индивидуальным). Подмена целей когда это не так. Мотивация к цели имеет косвенное отношение (может сформировать цель), но не обязательно соответствующую цели задания. Опасность вместо выполнения получить его имитацию. Необходимы приемы и методы доведения заданий до разработчиков. Нужно учитывать варианты подмены целей, включая как простое недопонимание, с одной стороны, а с другой прямой, но невысказанный саботаж. Требуются особые подходы. Это один из существенных аспектов квалификации. Принцип осмысленности действий не сводится только к индивидуальным воздействиям: –коллективное обсуждение, –открытое распределение обязанностей и др. –Но не в случае авторитарного и директивного руководства! –Осознанность – это, когда решения приняты на индивидуальном уровне, всеми участниками Мы ратуем за консенсус в руководстве коллективом эффективно стимулируют осмысленность действий («на миру и смерть красна!»).

27 27 2.Принципы построения системы деятельностей программного проекта

28 Эпиграф (тест) Требуется за одну минуту и предоставить решение следующей задачи Найти площадь прямоугольного треугольника со сторонами 5, 7 и 9 единиц длины Ответы: (1) 17.5 (2) (3) 17.5, если гипотенуза = 8.6 (4)Условие задачи противоречиво! Чтобы принимать решение осознано, нужно знать –Для чего это делается? Цель, ожидаемые результаты, критерии успеха –Из чего это делается?Какие ресурсы и материалы доступны –Какие средства и инструменты есть в распоряжении? –Как это делается?Какие методы можно или нужно применять для использования средств и инструментов +Для чего это делается?Как используются получаемые результаты? +Для кого это делается?Кто использует получаемые результаты? +В каком качестве предполагается использование? S = ? Составляющие элементы деятельности Окружение деятельности

29 29 Декомпозиция проектной деятельности Проект большая производственная функция, выполнение которой требует осуществления многих различных деятельностей. Деятельности проекта взаимосвязаны, нуждаются в планировании, обеспечении ресурсами и др. От существования многих из них приходится абстрагироваться (несущественные?) Организованность совокупности проектных и внешних (косвенно связанных с проектом) деятельностей должна быть достигнута! Для построения нужной организованности применяются методологии развития проектов. Среди прочего они решают задачу декомпозиции. Это одно из назначений методологии. А какие они бывают? Производственные функции и исполнители как декомпозируемые сущности –можно структурировать выполнение функции, разбивая ее на составляющие, определяя назначение каждой из составляющих и связи между ними так, чтобы результат совместного выполнения совпадал с требуемым результатом разбиваемой функции –можно структурировать обобщенного исполнителя, иными словами, конкретизировать исполнителей, отвечающих за разные аспекты выполнения функции Оба разбиения допускают продолжение в глубину: –для исполнителей до конкретных индивидуумов –для функций до неделимых единиц действий

30 30 Элементы деятельностей Субъект: программисты, выполняющие проект, и др., инициаторы работ Субъект: программисты, выполняющие проект, и др., инициаторы работ Материалы и ресурсы: требования к программной системе, оборудование, вспомогательные ресурсы Материалы и ресурсы: требования к программной системе, оборудование, вспомогательные ресурсы Результат: программная система, документация к ней, методика работы, тесты, учебные материалы и др. Результат: программная система, документация к ней, методика работы, тесты, учебные материалы и др. Цель: решение проблем поль-зователя путем автоматизации его деятель- ности Цель: решение проблем поль-зователя путем автоматизации его деятель- ности Методы: стратегии развития, методологии, регламенты и соглашения Методы: стратегии развития, методологии, регламенты и соглашения кто в состоянии выполнять деятельность для чего выполняется деятельность из чего продуцируются результаты деятельности указывают на то, как выполнять деятель- ность для чего выполняется деятельность Средства и инструменты: системы про- граммирования, библиотеки, CASE-средства Средства и инструменты: системы про- граммирования, библиотеки, CASE-средства с помощью чего продуцируются результаты деятельности Средства и инструменты и методы можно рассматривать совместно (но для нас полезно их разделять) фактически продуцируется в деятельности Сопоставление цели и результата деятельности важная составляющая оценивания проектной деятельности (оценочная деятельность)

31 31 Любая деятельность есть часть некоторой общей системы деятельностей, охватывающей группу субъектов-исполнителей. Деятельности, субъекты которых не попадают в выделенную группу, являются окружением данной системы. Окружение связано с системой следующими способами: –из окружения поставляются элементы деятельностей системы; –деятельностям окружения передаются результаты деятельностей системы; –система в целом и ее отдельные деятельности являются элементами деятельностей окружения Системы деятельностей Субъект Д Материалы Результат Цель Методы Средства … … … Нужно всегда знать место методики (методологии) в системе проектных деятельностей Нужно всегда знать место всех деятельностей, на которые возможно и следует влиять, чтобы система проектных деятельностей (проект) развивалась успешно! Недостаточно говорить только о процессах (обычно этим и ограничиваются см. слайды про PMBOK)! Д2Д2 Субъект Материалы Цель МетодыСредства Результат Средства Результат Цель Результат Материалы Цель МетодыСредства Д1Д1 Субъект Результат Субъект Результат Субъект Материалы Цель МетодыСредства Д3Д3 Результат …

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

33 33 Понятие требований (к проекту, программной системе и др.) Замысел, основная идея проекта желаемый результат. Что такое «желаемый результат»? Ответ в требованиях ( к проекту, процессу разработки к квалификации исполнителей и др.) Что такое требования? Много разночтений. –Пользовательские требования что должна делать система, какие функции она должна выполнять, какие возможности взаимодействия с ней должны быть предложены и др. + дополнения (например, языковая среда пользователей) и ограничения часто об этом умалчивают –Системные требования как система должна работать, (1) характеристики производительности при выполнении функций, эргономичности и др., (2) описание необходимого окружения: оборудование, программы и др. (3) совместимость, переиспользуемость и др. + ограничения Иногда дополняют это. Например так: –Проектная спецификация «обобщенное описание структуры программной системы [?], которое будет основой для более детального проектирования системы и ее последующей реализации» И. Сомервилл Как требования возникают, как они задаются, как учитываются в разработке и др.? Подробности в дальнейшем.

34 34 Сопоставление со стандартом PMBOK PMBOK Project Management Body of Knowledge (институт менеджмента проектов PMI) «Процесс это серия действий, приводящая к результату» (действие ?, результат ?) «Процесс любая деятельность, в которой используются ресурсы для преобразования входов в выходы» (ISO 9000) Деятельность шире процесса! Группы процессов PMBOK: –процессы инициации –процессы планирования –процессы исполнения –процессы контроля –процессы завершения Процессы инициации Процессы планирования Процессы контроля Процессы завершения Процессы исполнения

35 35 PMBOK-процессы и система деятельностей разработки программных проектов Схема иллюстрирует сущность менеджмента проекта на самом абстрактном уровне как деятельность, направленную на организацию и поддержку целенаправленного развития обозначенных на ней групп процессов Более конкретная интерпретация системы деятельностей по разработке программных проектов включает: –…–… –анализ предварительных требований, –конструирование архитектуры, –составление программного кода, –проверка кода, –…–… Эти деятельности зависят между собой, поставляя свои результаты друг другу, они не могут выполняться в произвольном порядке. Дальнейшая конкретизация проектировочных видов деятельности должна следовать выбранной для проекта методической установке. Отделение существенного от несущественного важный аспект формирования системы как объекта управления. Это именно деятельности, а не просто процессы! Нужно иметь ввиду (учитывать, планировать и т.п.) все элементы каждой деятельности!

36 IDEF0 – методология функционального моделирования (1993 – федеральный стандарт в США, 2000 – стандарт РФ) Процессы вместе с взаимосвязями и взаимодействиями представляют сеть процессов организации. 36 Деловой процесс – это совокупность процессов (операций, действий) и взаимодействий между ними, результатом (выходом) которой является продукция и/или услуги, поставляемые потребителям, а входами – материальные, информационные и трудовые ресурсы, поставляемые внешними поставщиками. Функциональная модель делового процесса охватывает процессы жизненного цикла, а также связанные с ними вспомогательные процессы и процессы менеджмента, входящие в состав деятельности организации. Это полностью согласуется с требованиями МС ИСО семейства 9000 версии 2000 года. Деловой процесс в швейном ателье

37 Пример детализации IDEF0 диаграммы 37

38 Ограниченность процессного и деятельностного представлений поведения системы Процессы Последовательное выполнение Зависимость: Связи входов с выходами Параллельное выполнение Возможность синхронизации Барьеры Конвейерное выполнение Нет средств отображения (дополнительный процесс не существует)! Деятельности Последовательное выполнение Зависимость: Поставка элементов (любых!) Параллельное выполнение Возможность синхронизации Барьеры Конвейерное выполнение За счет разделения поставки и использования элемента (внутри звездочки!) 38 … …

39 39 Процессы и система деятельностей разработки программных проектов Процесс ассоциируется с понятием времени (хотя и без привязки к нему) Звездочка деятельности – нет, но только потому, что время нельзя рассматривать изолированно от других деятельностей (как и процессы). Виды деятельностей в системе (условно): Продукционная – производит какой-то продукт Проектировочная – в качестве продукта производит план выполнения некоторой продукционной деятельности Наблюдательная – следит (?) за ходом продукционной деятельности Управляющая – наблюдательная, которая имеет средства воздействия на продукционную с тем, чтобы достигалось соответствие с плану. Событие – воспринимается в наблюдательной деятельности, она может продуцировать протокол продукционной деятельности (последовательность событий), т.е. локальное время. Глобальное время не существует! Это условность, удобная для примитивной приблизительной синхронизации. События – основа адекватного отслеживания времени в системы (контрольные точки, вехи – элементы синхронизации деятельностей проекта с точки зрения его менеджмента

40 40 Вопросы и задания Для всех: Какими деятельностями мы занимаемся, изучая предмет нашего курса? –Указать субъектов с их целями и другими элементами деятельностей –Соотнести цели с получаемыми результатами Что такое «польза»? Для тех, кто считает нужным сертифицироваться в PMI: Сопоставить процессы с системой проектных деятельностей –найти все элементы деятельностей PMBOK-процессов –найти все влияния их на окружения Характеризовать методики, которые предлагаются PMBOK для выполнения их процессов с точки зрения

41 41 Деятельность менеджера и составляющие системы проектных деятельностей Цель направление других проектных деятельностей так, чтобы они продвигали проект к выполнению (задаваемых вне системы) работ в условиях ограничений по времени, финансам и качеству = достижение целей деятельности, задающей проект в целом. Согласование параметров проекта: объем работ, сроки, запрашиваемые финансы (внешняя по отношению к работам проекта деятельность) Менеджмент проекта обеспечение предоставления продукта для его использования, разработка которого –требует выполнения определенного объема работ область действия, –использует затраты (в определенных пределах) ресурсы, –старается укладываться в заданные рамки времени план-график работ, и должна удовлетворять приемлемому уровню качества. Это хорошо известный треугольник менеджмента «хорошо-быстро- дешево»: из трех параметров выбери два получишь третий! Задание: 1. Конкретизировать элементы деятельности менеджера и их связи с другими деятельностями; 2. Сопоставить свой результат с полученным другими; 3. Объяснить различия.

42 42 Треугольник менеджмента проектов иллюстративная модель В р е м я В ы е п о л н н и е Ресурсы О б ь л а с т д е й с т в и й П л а н - г р а ф и к Качество Затраты X Y Z x min x-x- x+x+ x max x*x* Другие подобные модели см. в книге

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

44 44 Выяснение отклонений и корректировка траектории Воздействия Вынесенная траектория деятельности менеджера Автокорректировка

45 45 Определение этапов проекта: последовательное развитие проекта Этап 2 Контрольные точкиНачало проектаОкончание проекта Этап 1Этап 3Этап 4 Корректировка результатов работ этапа 2 Постановка задачи каждого этапа характеризуется: субъектом-исполнителем; сроками выполнения; выделенными ресурсами; средствами, методами и инструментами; контрольными мероприятиями. Разбиение этапа на локальные этапы, работы, задания. Параллельное выполнение их. Деятельность менеджеров по направлениям Сокращение объема конуса за счет использования более мелких конусов Это всего лишь иллюстративная стратегия, а не решение!

46 Сужение текущей задачи проекта: итеративное наращивание возможностей 46 Начало проекта Окончание проекта Движение (развитие) требований Последняя итерация … Вторая итерация Первая итерация Требования, назначенные к реализации на итерации Реализованные требования Это всего лишь иллюстративная стратегия, а не решение!

47 47 Жесткие и гибкие стратегии в методологиях программирования Жесткие / тенденция стандарта (СММ, МО США) Жесткие тяжеловесные монументальные Анализ и обобщение Опыт Метод Методика = методология Где и когда их можно применять? Р е ш е н и я Быстрые / agile development Быстрые гибкие шустрые облегченные Agile Manifesto Индивидуумы и взаимодействия важнее процессов и инструментов; Работоспособное ПО важнее обширной документации; Сотрудничество с заказчиком важнее заключения контракта; Готовность к изменениям важнее следования плану.

48 48 Императивные и креативные деятельности Жесткие методологииБыстрые методологии Предсказуемость проектаНепредсказуемость проекта Детерминированный процессНедетерминированный процесс Выбор стратегии развития проекта Императивные деятельности выполняются в известных ситуациях, в которых могут использоваться известные предписания, регламенты и методы, с тем, чтобы операционные маршруты не приводили к недопустимым траекториям. Креативные деятельности допускают ситуации, в которых известные предписания, регламенты, методы могут не срабатывать, а потому предполагают конструирование новых методов, которые обеспечивают допустимость траекторий операционных маршрутов. Это более высокий уровень знаний и умений! Методологии регламентируют не одну, а комплекс деятельностей, потому говорить строго об императивных или креативных методологиях неправомерно, но … Преимущественно императивныеПреимущественно креативные

49 49 Сопоставление жесткой и быстрой стратегий в методологиях программирования Жесткие стратегииБыстрые стратегии Ориентация на предсказуемые процессы с хорошо обозначенными целями Осознание того, что процессы разработки в принципе непредсказуемы Распознавание ситуаций и применение готовых методов Распознавание ситуаций и конструирование методов для работы в них Планирование, в котором определяются этапы Соблюдение баланса между параметрами проекта Заказчик внешний по отношению к проекту субъект Заказчик (его представитель) член команды разработчиков Ролевое разделение труда работниковСовместная деятельность работников Дисциплина и подчинениеСамодисциплина и сотрудничество Обезличенный процесс, исполнители которого определяются только по квалификационным требованиям Процесс, ориентированный на максимально полный учет человеческих особенностей исполнителей

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

51 51 Вопросы и задания Является ли разработка методологии креативным процессом? Можно ли жесткую методологию сделать гибкой? Ответ обосновать. Может ли гибкая методология стать жесткой? Ответ обосновать. Исследовать какую-либо традиционную жесткую методологию с точки зрения ответа на вопрос, какие методики предлагаются для поддержки креативных деятельностей в программных проектах. Выяснить, для какого типа проектов нерационально использовать какую-либо гибкую методологию (например, Extreme Programming).

52 52 3. Жизненный цикл программного обеспечения и его модели

53 53 Мотивация изучения жизненного цикла и его моделей Жизненный цикл база методологий Жизненные циклы технических и программных разработок (конструкционные материалы и окружение ПО, старение, продолжающаяся разработка (сопровождение): Причины изучения моделирования жизненного цикла: –для непрофессионалов понимание реальных возможностей; –основа адекватного применения инструментов и методов разработки; –общие знания ориентиры для планирования, аргументированность решений; –правильное распределение обязанностей в коллективе Соглашения, предписания, регламенты разработки и цена их игнорирования Разработка Использование Продолжающаяся разработка (сопровождение)

54 54 Жизненный цикл программного обеспечения: определение Цикл разработки, Издержки после завершения разработки Жизненный цикл это проекция пользовательского понятия «время жизни» на понятие разработчика «технологический цикл (цикл разработки)». Происхождение термина жизненный цикл Последовательное развитие и итеративное наращивание и модели жизненного цикла. ООП реальная основа итеративной схемы (не только оно возможно)

55 55 Жизненный цикл: последовательные и итеративные схемы Традиционные схемыОбъектно-ориентированная схема Полностью завершенные фазы проектирования и программирования Итеративно наращиваемые возможности Традиционные фазы распределяются по итерациям Продукт в конце периода разработкиРабочие продукты на каждой итерации Техническое описание как итог конструирования Рабочее описание, дополняемое на каждой итерации Последовательная разработкаВозвратно-поступательная разработка Модули действий, операцийИерархии классов объектов Структурная, пошаговая детализацияНаследование, переопределение, полиморфизм Сегодня это самый популярный вариант итеративной схемы

56 56 Задача методологии и жизненный цикл Методологии это инструменты, с помощью которых создание программного продукта превращается в упорядоченный процесс, а работа программиста становится более прогнозируемой и эффективной планирование процесса В материальном производстве:замысел чертежи проектные решения точное воспроизводство плана Расчет времени и стоимости, определение требуемой квалификации и др. В традиционном производстве: рост технологичности & снижение креативности Перенос в программирование. Разграничение двух видов деятельности: –проектирование (креативность) –производство (технологичность) Задача методологии: минимизировать творческий элемент в рутинных случаях стремление разграничить: –план и конструирование программы –спецификации пользовательской потребности и план, –выбор инструментов работы программиста и саму работу Появление соглашений, регламентов и предписаний, следование которым уменьшает вероятность ошибочных решений Форма представления жизненных циклов в разных методологиях различна, но в основе любых представлений разработки и сопровождения программных изделий лежат общие процессы, которые ведут проекты от замыслов к удовлетворению пользовательской потребности. Любая методология предписывает организацию этих общих процессов Полностью избежать креативности не получится! креативность

57 57 Модели процесса и продукта Моделируемый объект Модель процесса разработки: Целенаправленное развитие объекта под воздействием разработчиков Ключевые понятия:развитие, система деятельностей, субъект объект, этапы деятельностей, инструменты деятельности, цели, результаты и продукты Модели продукта (различные): Как устроен (построен) продукт? Для чего нужен? Один из типов моделей продукта: проекция модели процесса, в которой игнорируется все, связанное с субъектом возможна реконструкция модели процесса, которая необязательно совпадает с исходной моделью процесса! Иллюстративность модели : явное выделение некоторых аспектов для облегчения их понимания Инструментальность модели : использование ее в качестве инструмента некоторой деятельности (т.е. способствует целенаправленному развитию). Нельзя смешивать иллюстративные и инструментальные модели Вопросы в связи с моделью: Что будет, если…? и Соответствует ли…?

58 58 Общепринятая модель жизненного цикла программного обеспечения Определение требований Спецификации требований Проектирование Реализация Тестирование Сопровождение Развитие Фаза разработки Фаза эксплуатации и сопровождения

59 59 Общепринятая модель источник базовых понятий Начало разработки идентификация потребности Определение требований определяются: контекст задачи, ожидаемые функции ограничения. Проекта еще нет. Спецификации системы в соответствии с требованиями Определяется поведение системы: что она должна делать. Фактическое начало работ Проектирование (конструирование, дизайн) определяется декомпозиция системы /архитектура & результат ее построения/: как достигается соответствие спецификациям Реализация (кодирование) разрабатываются модули (в модели нет этапа интеграции): что обеспечивает требуемый результат Тестирование проверка соответствия спецификациям Сопровождение поддержка использования продукта Развитие поддержка эволюции системы (новый проект?)

60 60 Классическая итерационная модель Определение требований Спецификации требований Проектирование Реализация Тестирование и отладка Эксплуатация и сопровождение Отражает потребность исправления ошибок пройденных этапов!

61 61 Исправление ошибок или адаптивность проекта? Классическая итерационная модель абсолютизация возможности возвратов для исправления ошибок, т.е. Идея завершенности пройденных этапов предсказуемость Стратегия итеративного наращивания возможностей ослабляет требование завершенности ООП + CASE-системы принципиальная возможность поддержки итеративного наращивания (не более!) Адаптивность проекта альтернатива предсказуемости Адаптивность должна закладываться в проект на самых ранних этапах его развития Задание: Приведите примеры, когда a.адаптивность вредна для разработки, b.поддержка адаптивности не помогает справиться со сложностью разработки. Ответы обоснуйте!

62 62 Каскадная модель Определение требований подтверждение Спецификация требований: системные требования подтверждение требования к программам подтверждение, обзоры Проектирование верификация Реализация: кодирование и автономная отладка тестирование интеграция и комплексная отладка аттестация Эксплуатация и сопровождение переаттестация Чем заканчи- ваются этапы

63 63 Каскадная модель: новые понятия Характерные черты каскадной модели: завершение этапов проверкой полученных результатов циклическое повторение пройденных этапов Чем заканчиваются этапы? Подтверждение разного рода документальные согласования Обзор документ, предоставляемый для согласования Проверка полученных результатов на соответствие целям: –Верификация отвечает на вопрос, правильно ли создана (декомпозиция, программная система и др.) –Аттестация отвечает на вопрос, правильно ли работает, т.е. будет использоваться (в первую очередь программная система) –Переаттестация аттестация, которая устанавливает насколько хорошо система соответствует пользовательским запросам

64 64 Строгая каскадная модель Определение требований подтверждение Спецификация требований: системные требования подтверждение требования к программам подтверждение, обзоры Проектирование верификация Реализация: кодирование и автономная отладка тестирование интеграция и комплексная отладка аттестация Эксплуатация и сопровождение переаттестация Чем заканчи- ваются этапы Удалены «лишние» возвраты За счет чего это достигается?

65 65 Строгая каскадная модель: дополнительные требования к разработке проекта Минимизация возвратов за счет ликвидации переходов через уровни –ужесточение проверок (барьеров) –переход вниз сопровождается передачей исходного материала для следующего этапа задание на разработку Причины невыполнения задания: i.оно противоречиво, т.е. содержит несовместные или невыполнимые требования; ii.не выработаны критерии для выбора одного из возможных вариантов решения (i и ii) ошибка предыдущего этапа он возобновляется: a.ошибка ликвидируется переход к следующему этапу (через барьер) b.невозможность исправления это ошибка более раннего этапа он возобновляется Два существенных момента (отражающих реальности разработок проектов): –точное разделение работ, заданий и ответственности разработчиков и тех, кто инициирует переход к следующему этапу шаг к осознанию фактического разделения труда –малые циклы между соседними этапами, в результате достигается компромиссное задание совместное выполнение соседних этапов, т.е. их перекрытие Однако в каскадной модели оба момента отражаются лишь косвенно

66 66 Каскадная модель MSF Вехи (контрольные точки) используются в качестве точек оценки и перехода от одной фазы к другой. Все задачи одной фазы должны быть завершены до того, как начнется следующая фаза. Вехи Фазы (этапы) Каскадная модель работает, когда на начальном этапе проекта можно четко определить неизменный набор требований к разрабатываемому решению. Оценка: Слабее рассмотренной ранее строгой каскадной модели, но применимость характеризуется верно

67 67 Вопросы и задания Какие из рассмотренных моделей можно сделать инструментальными, а какие не допускают этого? Ответ обосновать. С какими видами документов, используемых в качестве барьеров вы сталкивались? Ответ поясните.

68 68 4.Производственные функции в моделировании жизненного цикла: модель фазы функции

69 69 Модель фазыфункции Гантера: Анализ осущест- Конструиро- вание Программирование Оценка Фазы (этапы) 5 Спецификации утверждены 4 Спецификации составлены 3 Требования утверждены 2 Требования сформулированы 1 Ресурсы распределены 0 Необходимость разработки признана Компоновка завершена 6 Независимые испытания начались7 Начато использование изделия 8 Изделие передано на распространение 9 Изделие снято с производства 10 Конт- рольные точки (события): фазовое измерение вимости Использование Исследо- вания Обосновываются необходимые ресурсы и формулируются требования Определяется осуществимость проекта с технической, эргономической и экономической точек зрения Определяется архитектура системы, составляются спецификации компонентов, распределяются задания на программирование компонентов, фиксируется процедура интеграции системы Реализация программ компонентов с последующей сборкой изделия. Завершается, когда заканчивается документирование, отладка и компоновка, и система передается службе, выполняющей независимую оценку результатов работы Буферная зона между началом испытаний и практическим использованием. Этап начинается после внутренних (силами разработчиков) испытаний и заканчивается, когда подтверждается готовность системы к эксплуатации Этап продолжается, пока изделие интенсивно эксплуатируется. Внедрение, обучение, настройка и сопровождение, возможно, модернизация. Этап заканчивается, когда прекращается деятельность по сопровождению и поддержке Это традиционное последовательное выполнение проекта с перекрытием этапов

70 70 Основной тезис: На разных этапах функции имеют различное содержание, требуют различной интенсивности, при реализации проекта совмещаются. Модель фазыфункции Гантера: предпосылки функционального измерения (производственные функции классы функций) Планирование Разработка Обслуживание Выпуск документации Испытания Поддержка Сопровождение Классы родственных функций можно считать выполняемыми в течение всего хода развития проекта; Содержание (цели) функции на различных этапах претерпевает изменение Интенсивность функции меняется как при переходе от этапа к этапу, так и в рамках работ одного этапа В конкретных проектах это понятие доопределяется (трактуется так, как полезно, например, как потребность или расходование ресурсов).

71 71 10 Модель фазыфункции Гантера: функциональное измерение Программирование Оценка Фазы: 0 Планирование Разработка Обслуживание Выпуск документации Испытания Поддержка Сопровождение Использование Функции: Контрольные точки Анализ осущест- Конструиро- вимости вание Исследо- вания

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

73 73 Учет итеративности в модели фазыфункции Программирование Оценка Использование Фазы (этапы) Контрольные точки Конструиро- вимости вание Исследо- вания Анализ осущест- Расщепление линии развития проекта (жизненного цикла): 1.Приостановка процесса (в любой момент, если обеспечена корректность слияния) традиционная реакция на ошибку 2.Действительное расщепление появляются два (и более?) процесса. Для корректности нужно оценивать ресурсы, планировать новые контрольные точки и определять содержание существующих контрольных точек Слияние расщепленных процессов в случае 2 должно планироваться! Действительное расщепление обязано быть регламентированным!

74 74 5.Моделирование жизненного цикла объектно- ориентированных программных проектов

75 75 Принципы объектно-ориентированного проектирования 1.Итеративность развития возможность перейти от последовательного развития к стратегии итеративного наращивания возможностей 2.Изменение функциональности пересмотр требований при развитии проекта 3.Формирование системы понятий проекта развивающийся глоссарий проекта 4.Наращивание функциональности в соответствии со сценариями реализация выделенных сценариев; последующие итерации реализуют другие сценарии 5.Ничто не делается однократно отказ от завершенности работ классических этапов, повторное прохождение их на новых итерациях (с новым набором сценариев) 6.Оперирование на размножающихся фазах подобно обычные этапы при выполнении любой итерации развития проекта: Определение требований, или планирование итерации; Анализ; Моделирование пользовательского интерфейса /новое/; Конструирование; Реализация (программирование); Тестирование; Оценка результатов (итерации) Вне итераций: 1.Начальная фаза проекта: требования, ближайшая и перспективные задачи, критерии оценки результатов; 2.Фаза завершения проекта: поставка и сопровождение + выделение переиспользуемых компонентов

76 76 Моделирование при объектно- ориентированном проектировании 1.Распределение реализуемых требований по итерациям: Совокупность сценариев, реализуемых на очередной итерации + набор ранее реализованных сценариев образуют законченную, хотя и неполную версию системы, предлагаемую пользователям модели уровня анализа 2.Особый стиль наращивания возможностей системы и ее развития : Основа декомпозиции проекта при ООП подходе набор связанных различными отношениями классов; новая итерация расширяет этот набор. Это расширение строится на базе построения моделей уровня конструирования Моделирование организационно- техническая (производственная) функция всего процесса развития проекта, а не один из этапов! Следствие : Пополнение базового окружения проекта дополнительный этап (вложенный в оценку), содержание которого анализ возможного переиспользования накапливаемых компонентов ПО как для проекта, так и для будущего

77 5 Спецификации утверждены 6 Автономная проверка завершена, комплексное тестирование началось Программирование Оценка Использование Фазы (этапы) Тестирование завершилось, начата подготовка век подготовка новой итерации 7 Конт- рольные точки (события): Итеративное зацикливание Пополнение базового окружения проекта Общие требования и общий план составлены, ближайшая и перспективная задачи, критерии оценки результатов определены Окончание работ Начало проекта Исследования Завершение проекта Анализ осуществимо- сти вание Конструиро- Жизненный цикл при объектно-ориентированном развитии проекта (фазовое измерение) 0 Необходимость разработки признана 1 Ресурсы распределены 4 Спецификации реализуемых сценариев составлены 3 Требования к очередной итерации утверждены 2 Требования к очередной итерации сформулированы Требования к новой итерации приняты 8 Начато использование изделия 9 Изделие или его версия передано на распространение 10 Извещение о прекращении поддержки изделия (версии) выпущено 11 Изделие (версия) снято с производства 12 Взаимодействие с планировщиком с целью выяснения возможностей предоставления ресурсов для проекта. Планирование предоставления ресурсов Начала стационарного цикла развития проекта. Различия первой и последующих итераций: формирование и корректировка критериев предпочтения того, что считается целесообразным для реализации Все, что представляет проект (итерацию) как развивающуюся разработку утверждается. Важно: это момент подведения первых итогов проекта (итерации) Декомпозиция решаемых проектом (итерацией) задач. Построение архитектуры, подготовка реализуемых сценариев для утверждения, определение реализуемых модулей Архитектура утверждена, задачи распределены между разработчиками (группами) Начало этапа пополнения базового окружения проекта: выделение общих лишь для данного проекта переиспользуемых компонентов выделение общих, не привязанных к проекту переиспользуемых компонентов Сбор сведений для новой итерации Оформление принимаемых для новой итерации требований. Одновременное существование двух (возможно, более) версий системы. Время для ревизии априорных гипотез, корректировка показателей и нормативов проекта Оповещение о прекращении сопро- вождения и сворачивание деятель-ности по поддержке версии или всех версий к определенному сроку Возможно откладывание события (на определенный или неопределенный срок) Начало работ над проектом (замысел). Цель указать на потребность проектных результатов, фиксировать стратегию, обозначить ресурсные потребности, планы формирования команды исполнителей и др. У разработчиков появилась возможность проверки априорных суждений о проекте (итерации) на практике. Важно: слияние контрольных точек 3, 4, 5 и объявление точки 6 как вехи в быстрых методологиях не означает ликвидации соответствующих процессов! Начало Фазы завершения (бета-тестирование): поставка сопровождение этап окончания работ Новое качество: у версии появляются пользователи, нуждающиеся в обслуживании 77

78 78 Контрольные точки и вехи Контрольные точки (check points) точки линии жизни жизненного цикла проекта, в которых возникают определенные события. Эти события рассматриваются как существенные, поскольку их необходимо отслеживать с целью управляемого развития проекта (такого, которое оставляет траекторию в рамках области допустимых операционных маршрутов) Вехи (mail stones) это контрольные точки, прохождение которых сопровождается определенными планируемыми мероприятиями. Без успешного (результат соответствует цели) проведения таких мероприятий, прохождение вехи блокируется с целью выполнения активностей, направленных на исправление ситуации. Планирование получения результата и оценка полученного результата основное содержание деятельности, связанной с вехами Конкретизация контрольных точек и вех существенная задача, которую приходится решать в рамках выполнения функции планирования. Эта конкретизация делается на основе знания специфики выполняемого проекта и процесса его выполнения (т.е. приятой для проекта методологии). Специфика проекта и процесса определяет необходимость и количество вех. В жестких методологиях к прохождению вехи приурочивается утверждение соответствующих ей рабочих продуктов, в том числе и документов; В быстрых методологиях вехи служат лишь ориентирами продвижения в своем развитии (мероприятия не имеющие отношения к процедурам утверждения)

79 79 Для каждой итерации должны быть определены: Общие требования что требуется от проекта в целом в данный момент Общий план как предполагается достигать цели (стратегия) Ближайшая задача набор конкретных реализуемых требований и сценариев критерии предпочтения того, что планируется реализовывать Перспективные задачи те, которые рассматриваются (в данный момент) как основа для планирования дальнейших итераций (в проектах жесткой отчетности) Критерии предпочтения: 1)Актуальность для пользователя 2)Полнота и функциональная замкнутость предлагаемых средств –Функциональная полнота –Реализационная полнота –Интерфейсная полнота 3)Системная значимость (внутрипроектные предпочтения) 4)Демонстрационная значимость 5)Скорость реализации Общие требования, общий план, ближайшая и перспективные задачи Характеристики значимости: Возможные ограничения: время, объем работ, затраты (треугольник менеджмента) Всегда лучше то, что актуально! Автоматизация деятельности в целом. Растет по мере увеличения объема уже выполненных работ Реализационные предпочтения. Конкурирует с (1). Более значим для начальных итераций Конкурирует с (1), (2) и (3) Максимально значимо для начальных итераций Лучше то, что быстрее. Если время фиксировано, то для реализации определяется пул работ. Иногда время не критерий, а ограничение Минимизация реализуемого является критерием лишь для некоторых методологий!

80 80 Жизненный цикл при объектно-ориентированном развитии проекта (функциональное измерение) Планирование Разработка Обслуживание Выпуск документации Испытания Поддержка Сопровождение Моделирование Планирование Разработка Обслуживание Выпуск документации Испытания Поддержка Сопровождение Моделирование Исследова- ния Программирование Оценка Использование Фазы (этапы) Итеративное зацикливание Пополнение базового окружения проекта 68 Окончание работ 1 Контрольные точки (события) Анализ осущест- Конструиро- вимости вание

81 81 Непрерывность поступления требований в моделях жизненного цикла Трассировка требований (в модели Гантера) Варианты поступления требований: –требование или группа требований обрабатываются до начала итерации (при разработке ее сценариев) –требование или группа требований поступают, когда работы итерации начались –требование или группа требований поступают, когда релиз системы передан в эксплуатацию Возможные результаты анализа требований: –требование отклоняется работа с требованием прекращается –требование принимается к реализации на текущей итерации –реализация требования откладывается до следующих итераций Функциональное измерение меняется, но учесть это вне контекста конкретного проекта нереально Почти все модели жизненного цикла слабо приспособлены к учету непрерывности поступления требований Укладывается в представ- ленную ранее схему модели фазы – функции Схема дополняется мини-циклом обработки требований До мини-цикла необходим предварительный анализ требований

82 82 (b) Решение о требовании принято 8 Контроль- ные точки (события): Программирование Оценка Использование Фазы (этапы) Итеративное зацикливание Пополнение базового окружения проекта Окончание работ Начало проекта Исследования Завершение проекта Анализ осуществимо- сти вание Конструиро- Жизненный цикл при объектно-ориентированном развитии проекта (фазовое измерение) (a) Требование поступило, начало мини-цикла Требование отклоняется Шаги обработки требования или группы требований: поступление в любой момент конструирования, программирования или оценки расщепление, переход к анализу анализ принятие решения /на общем участке этапов анализа и конструирования/ планирование срока или будущей итерации реализации Требование реализуется на более поздней итерации Требование реализуется на текущей итерации Варианты решения Анализ нового требования

83 83 Использование Проверка реализации Решение о реализации ама требований принято (c) Накопление, система- тизация и группировка требований Пополнение базового окружения проекта вание Анализ осуществи- Требования, поступающие в ходе эксплуатации (b) Решение о требовании принято 8 Программи- Оценка Фазы (этапы) Итеративное зацикливание Окончание работ Начало проекта Исследования Завершение проекта мости Конструиро Сообщение о требовании поступило (a) Требование отклоняется рование Первичный анализ Извлечение требования Решение реализовать: в другом проекте в следующих релизах в текущем релизе немедленная реакция в другом проекте в следующих релизах в текущем релизе немедленная реакция Период сопровождения Контроль- ные точки (события): Реализация требований

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

85 Действия, связанные с новыми проектными требованиями Требования, возникающие и изменяемые в течение этапов итерации, разделяются на принимаемые и отвергаемые Для каждого отвергаемого требования составляется мотивированное заключение о том, почему оно не принимается: –невозможно удовлетворить, –нецелесообразно принимать (достижимо иным путем), –запланировано в качестве перспективы, –может быть принято при изменении финансовых и календарных планов и др. Заключение согласовывается с автором требования и с заказчиком Для каждого из принимаемых требований (их элементарных составляющих) определяется, когда оно может быть удовлетворено и когда его целесообразно удовлетворять. Критериями служат: –приоритетность требования; –сложность рабочих продуктов и зависимостей рабочих продуктов от требования; Простые требования реализуются непосредственно в момент утверждения; Сложные требования откладываются до завершения конструкторских работ итерации, которое рассматривается как начало работ по учету комплекса предъявленных требований; Требования, откладываемые до последующих итераций, реализуются согласно общему плану проекта (корректируемому) Учитывается, что ранее принятое требование может оказаться отвергнутым вследствие принятия новых требований необходимо подготовить и согласовать с автором требования и заказчиком заключение об отказе от реализации требований, Изменения планов и объемов работ, возникающие и/или планируемые в связи с изменениями требований, всегда согласуются с заказчиком. 85

86 86 6. Технологические аспекты развития программных систем в моделях жизненного цикла

87 87 Модели жизненного цикла и задачи методологий разработки проектов 1.Первая задача: выяснить –способность моделей жизненного цикла отражать технологичные свойства процесса производства программного обеспечения, например, распараллеливание производственных операций и их распределение между исполнителями –возможность использования моделей жизненного цикла, согласованного с реальными процессами менеджмента и с другими инструментами, поддерживающими эти процессы 2.Вторая задача: показать возможности параллелизма выполнения проектных заданий Коллективный процесс разработки всегда подразумевает параллельное выполнение деятельностей: –совместная работа на смежных этапах (отмечалась ранее) –функциональное измерение (отражено в модели Фазы функции) +параллельное выполнение деятельностей в рамках отдельных этапов (естественное требование к процессу разработки обычно только про него и говорят) Итеративные схемы допускают еще один вид параллелизма: –одновременная разработка нескольких итераций (в известных пределах)

88 88 Планирование Параллельное выполнение итераций Пределы совмещения итераций в проекте ПлАнКоПрТеОц Совмещение не допустимо Совмещение возможно Совмещение рационально Последовательное выполнение ПлАнКоПрТеОц Последовательность итераций ПлАнКоПрТеОц ПлАнКоПрТеОц I II III АнализКонструированиеПрограммированиеТестированиеОценка

89 89 Пределы совмещения итераций в проекте Область недопустимого совмещения: когда выполнение одной работы непосредственно зависит от результатов другой Область возможного совмещения: когда зависимость ослаблена тем, что ожидаемые результаты предшествующей работы хорошо описаны (например, построены и проверены модели этапов конструирования, хотя программирование еще не выполнено) Область рационального совмещения: когда зависимость работ фактически тем или иным способом экранирована (предшествующая работа выполнена, хотя, быть может, не до конца проверена, составлен и проверяется протокол взаимодействия работ и др.) Недопустимость совмещения означает, что для планирования очередной итерации нет достаточно полной информации, следовательно, оно не может быть выполнено эффективно. Когда такая информация появляется, появляется и возможность активизации работ над новой итерацией Рациональное совмещение означает надежность параллельной работы. Разумнее всего начинать этап программирование новой итерации, когда рабочий продукт предыдущей итерации протестирован ПлАнКоПрТеОц Совмещение не допустимо Совмещение возможно Совмещение рационально Последовательное выполнение

90 90 Модели процесса и продукта (напоминание) Моделируемый объект Модель процесса разработки: Целенаправленное развитие объекта под воздействием разработчиков Ключевые понятия:развитие, система деятельностей, субъект объект, этапы деятельностей, инструменты деятельности, цели, результаты и продукты Модели продукта (различные): Как устроен (построен) продукт? Для чего нужен? Один из типов моделей продукта: проекция модели процесса, в которой игнорируется все, связанное с субъектом возможна реконструкция модели процесса, которая необязательно совпадает с исходной моделью процесса! Иллюстративность модели: явное выделение некоторых аспектов для облегчения их понимания Инструментальность модели: использование ее в качестве инструмента некоторой деятельности (т.е. способствует целенаправленному развитию). Нельзя смешивать иллюстративные и инструментальные модели Вопросы в связи с моделью: Что будет, если…? и Соответствует ли…?

91 91 Требования к инструментальной модели жизненного цикла давать картину разработки и развития проекта (уровни организации планирования процесса для определения графика работ, для отслеживания их ресурсной обеспеченности и др. ); давать средства декомпозиции процесса разработки, т.е. согласованного разбиения этапов на вложенные этапы и работы (поддержка планирования); обеспечивать переход от этапов к работам этапов и доступ к истории; позволять видеть текущее состояние проекта и варианты развития; позволять оперировать своими элементами, а через это влиять на ход моделируемого процесса выполнения проекта Способ сгладить противоречие ориентация на определенные типы жизненного цикла (отказ от универсальности моделей) Относительность качества инструментальности модели параметры оценки, нормирование оценки. Качественное (не количественное) оценивание Реальная и принципиальная возможность использования модели Целесообразно рассматривать принципиальную возможность инструментального использования моделей Модель должна: Однако это может приводить к потере наглядности модели

92 92 Параметры оценки инструментальности 1.Атрибутивность с элементами модели связаны определенные атрибуты, необходимые для управления проектом. Их можно задавать или извлекать, т.е. размещать информацию о проекте в некотором хранилище и получать информацию из него; 2.Расширяемость допускается пополнение элементов модели, в результате она становится более детализированной, точнее отражающей реальный процесс. Для жизненного цикла это возможность дополнения элементами, указывающими на составляющие процесса разработки, т.е. на добавляемые этапы и на продолжения дробления процесса на задачи, работы и др.; 3.Масштабируемость возможность увидеть модель с разной степенью детализации от охвата всего процесса и до конкретной работы; 4.Интегрированность с другими инструментами поддержки. Это качество не самой модели, а CASE-средств, совместно с которыми она используется. Мера, в которой модели обладают этими свойствами, может служить основой для сравнения их инструментальных возможностей Из ранее рассмотренных моделей только строгая каскадная модель и матрица Фазы функции могут претендовать на то, чтобы их можно было считать инструментальными: 1.Расширяемость (дополнительные блоки, вложенные этапы и др., расщепление линии жизни) 2.Атрибутивность матрица Фазы функции выше, чем у каскадной модели (функциональное измерение) 3.Масштабируемость каскадной модели более развита, чем у матрицы Фазы функции 4.Интегрированность выше у к аскадной модели, но принципиально возможна для обеих моделей Из ранее рассмотренных моделей только строгая каскадная модель и матрица Фазы функции могут претендовать на то, чтобы их можно было считать инструментальными: 1.Расширяемость (дополнительные блоки, вложенные этапы и др., расщепление линии жизни) 2.Атрибутивность матрица Фазы функции выше, чем у каскадной модели (функциональное измерение) 3.Масштабируемость каскадной модели более развита, чем у матрицы Фазы функции 4.Интегрированность выше у к аскадной модели, но принципиально возможна для обеих моделей

93 93 Сравнение инструментальности различных моделей Календарный план Диаграммы Гантта Каскадная модель Спираль развития Буча Инструментальная спиралевидная модель Боэма Модель RUP Модель процессов MSF Модифицированная модель Гантера (матрица фазыфункции)

94 94 Календарный план документ, с помощью которого устанавливаются юридические отношения, касающиеся объема, сроков и (зачастую) ресурсных потребностей выполняемых работ, между всеми участниками разработки проекта, включая и заказчиков, и планировщиков. Внешние и внутренние функции календарного плана Разбиение проектного задания на этапы соответствие этапам разработки жизненного цикла модель жизненного цикла, урезанная до цикла разработки Попытка охватить все аспекты, которые нужно учитывать при выделении работ и отслеживании сроков их выполнения Календарный план Рубрикация зависит от уровня проработанности проекта. Возможно ее уточнение в ходе проекта Целесообразные сроки или самое раннее начало и самый поздний конец Кто и в какой роли отвечает (работает) Сроки привлечения работников (подмены) Подписи «Ознакомлен» Кто и в какой роли отвечает (работает) Сроки привлечения работников (подмены) Подписи «Ознакомлен» Неучтенное Особые сведения Другое (критичность и пр.) Неучтенное Особые сведения Другое (критичность и пр.) От каких поставок ресурсов зависит работа Подписи ответственных «Ознакомлен» От каких поставок ресурсов зависит работа Подписи ответственных «Ознакомлен»

95 95 Календарный план: обсуждение Удобен: Верхний уровень рубрикации должен совпадать с тем, что задается в техническом задании Дополнение новыми рубриками (в том числе в процессе выполнения) не вызывает трудностей Наглядность Недостатки: Тенденция к разрастанию Неприспособленность к учету загруженности сотрудников, потребностей и к перераспределению ресурсов. Рубрикация противоречит распараллеливанию работ Трудно увидеть показатели на определенный момент времени Непригодность для отражения итеративности развития проекта Оценка инструментальности: Атрибутивность относительна (рост числа отражаемых атрибутов снижение наглядности) Расширяемость одно из основных преимуществ Масштабируемость слабое место Интегрированность с другими инструментами возможна Развитие /и ограничение!/ календарного плана диаграммы Гантта как основа реальных инструментов поддержки управления проектами

96 96 Диаграммы Гантта Критерии инструментальности 1-4 выполняются (почти достаточно) Попытка отражать время, однако есть проблема расщепления времени, когда есть оперирование параллельными работами Для независимо действующих процессов нужно рассматривать множественное время + связи времен (синхронизация и др.) время как частично упорядоченное множество событий MS Project пример диаграмм Гантта. Это максимум того, что можно поддержать с помощью универсального инструментария // PERT-диаграммы (работы дуги, события вершины) используются реже (хуже отражают времена работ) // Скептическое отношение к моделям жизненного цикла вообще, исходящим из представления диаграмм Гантта (Брукс). Время Работа 21 Работа 3 Работа 31 Работа 33 Работа 4 Работа 32 Работа 22 Наименование работ (тема, этап, работа, задача, задание) Работа 1

97 97 Каскадная модель Определение требований подтверждение Спецификация требований: системные требования подтверждение требования к программам подтверждение, обзоры Проектирование верификация Реализация: кодирование и автономная отладка тестирование интеграция и комплексная отладка аттестация Эксплуатация и сопровождение переаттестация Чем заканчи- ваются этапы

98 98 Каскадная модель : ограниченность Схема последовательного (а не итеративного) развития проекта Ограниченные возвраты (ошибки прошлых этапов) Ориентация на вполне определенную методологию развития проекта (контроль прохождения этапов барьеры) Блоки каскадной модели можно раскрывать внутрь: дробление процесса на задачи, работы и др. возможно. При этом: –принципиально возможно вводить новые блоки и связи (расширяемость) –вертикальная ось времени –синхронизация

99 99 Каскадная модель: декомпозиция процесса на задачи, работы и др. (иллюстрация) Реализация кодирование и автономная отладка интеграция и комплексная отладка аттестация тестирование Реализация кодирование и автономная отладка интеграция и комплексная отладка аттестация Работа 1 тестирование Работа 2 тестирование Работа 3 тестирование Работа 5 тестирование Работа 4 тестирование

100 100 Каскадная модель: оценка инструментальности Расширяемость достигается как элемент выбранной методологии Атрибутивность относительна: показ дополнительных атрибутов может снижать наглядность Масштабируемость слабая: переход на другой уровень (вверх и вниз), но для выбранной методологии этого достаточно Интегрированность принципиально возможна (для выбранной методологии) Инструменты поддержки каскадной модели представлены среди CASE-средств (чаще фрагментарно, но приемлемо)

101 101 Спираль развития Буча Вариант Буча чисто иллюстративная модель Модификации: –Изображение итеративного зацикливания –Система координат «время предоставляемые возможности» –Изображение стандартных и, возможно, дополнительных этапов

102 102 Спираль развития Буча: обсуждение Как и у Буча, возможности, предоставляемые итерацией, никогда не отменяют ранее достигнутого уровня Можно показывать и отслеживать параллельное выполнение итераций Детализированное выделение этапов нарушает наглядность относительная расширяемость Слабо приспособлена для отражения этапов внедрения Согласуется с детализацией верхнего уровня декомпозиции для инструментальности нужна автоматизация перехода к другим уровням (к отдельной итерации) Масштабируемость в принципе достижима Атрибутивность на уровнях отдельных итераций Интегрированность в принципе достижима Необходимая расширяемость достижима Это уже другие модели

103 103 Инструментальная спиралевидная модель Боэма

104 104 Инструментальная спиралевидная модель Боэма : обсуждение Модель проработана с точки зрения процессов производства программ Возможна настройка модели на конкретные методологии. Модель явно указывает на действия, которые требуется выполнять при движении по спирали. Расширяемость основное достоинство Масштабируемость не очень существенна (взамен движение по спирали) Вполне определенная методика работы Конкретное планирование действий витков за рамками модели атрибутивность вне модели Интегрированность в принципе достижима Недостатки: плохо отображаются временные соотношения между сроками выполнения работ на разных витках плохо приспособлена к учету и распределению ресурсов

105 105 Модель выглядит как универсальная схема: она отражает то, что включается в любое производство программ Модель RUP 51% программных разработок применяют RUP RUP претендует на роль универсальной основы любых программных разработок Модель задается в виде матрицы интенсивностей функций, выполняемых на этапах (фазах), которые проецируются на итерации Проекция на итерации Интенсивности производственных функций Итерация в фазе Elaboration Работа с требованиями

106 106 Модель RUP : обсуждение Не конкретизируются виды работ на этапах Время условно Возможность совместного выполнения некоторых производственных функций не отражается Включение дополнительных этапов и функций, отражение специфики конкретного процесса или коллектива затруднительно (это нарушило бы фиксированную связь между жизненным циклом по RUP с моделями уровня проектирования ) Конкретизация модели разрушает универсальность Средства моделирования элементы языка UML, а не инструменты фиксированной методологии Предполагаемый выход: множество стандартных ситуаций, в которых можно воспользоваться предлагаемыми средствами Стремление RUP к универсальности привело к иллюстративной модели жизненного цикла и к появлению инструментов и методов их применения (весьма полезных!), не связанных с моделью жизненного цикла

107 107 Система моделей RUP Модель анализа Модель тестирования Модель развертывания Модель проектирования Х ok Модель ситуаций использования описывается в реализуется в распределяется в проверяется в реализуется в Модель реализации Анализ Конструирование Программирование Оценка Привязка моделей к традиционным этапам

108 108 Модель процессов MSF Цитата: «Модель процессов объединяет в себе лучшие принципы каскадной и спиральной моделей. Она сохраняет преимущества упорядоченности каскадной модели, не теряя при этом гибкости и творческой ориентации модели спиральной, учитывает необходимость постоянного пересмотра, уточнения и оценки проектных требований, стимулирует активное взаимодействие между проектной группой и заказчиком, который оценивает ход и результаты работы на протяжении всего проекта»

109 109 Модель процессов MSF : обсуждение Стремление к универсальности приводит к огрублению ситуации в конкретных случаях и к необходимости словесного дополнения схемы (что и сделали авторы MSF) Невозможность отслеживания временных соотношений Трудности дополнения специфичных этапов Нет механизмов задания оперирования ресурсами и контроля их использования (слабая атрибутивность) Модель является лишь иллюстративной

110 Планирование Разработка Обслуживание Выпуск документации Поддержка Испытания Сопровождение Моделирование Функции Модифицированная модель Гантера (матрица фазыфункции) Программирование Оценка Использование Фазы (этапы) Итеративное зацикливание Пополнение базового окружения проекта Окончание работ Анализ осущест- Конструиро- вимости вание Исследова- ния 9 Контрольные точки (события) Р1 Р2 Распространение идеи расщепления на функциональное измерение 110

111 Модифицированная модель Гантера: «азбука» шаблонов … Р1Р2 вание Конструиро- … Программирование Оценка а) Последовательное выполнение работ одним исполнителем б) Одновременно начинающиеся работы Р1 Р2 Р1 Р2 в) Одновременно завершающиеся работы е) Откладывание выполнения работы Р1 ж) Раннее завершение выполнения работы Р1 Дуги работ могут размещаться на функциональном измерении! Т.е. относится к тем или иным производственным функциям г) Зацикливание работы Р1 д) Параллельные и зацикливаемые работы Р1 Р2 ПФ1 ПФ2 111

112 Модифицированная модель Гантера: оценка инструментальности Расширяемость достигается за счет шаблонов Атрибутивность очень высокая: показ производственных функций, их интенсивностей, возможность добавления новых функций + перекрывающиеся этапы + размещение работ на функциональном измерении + … Масштабируемость слабое место: нуждается в дополнительной проработке способ показа уровней (итерации, работ и пр.) Интегрированность с разными инструментами вполне возможна Модель Гантера одна из возможных нотаций (а не «универсальная» методология). Это язык схем жизненных циклов, допускающий адекватную инструментальную поддержку Пример нестандартного применения: вместо функций можно задавать наименования рабочих групп (распределение работ по группам) Вопрос: А нужно ли это для управления проектами? Ответ: Возможно и другое, но не менее гибкое средство (язык!) 112

113 Итоги Универсальность модели (т.е. пригодность для отражения всех жизненных циклов) противоречит инструментальности. Надо ориентироваться на типовые жизненные циклы Иллюстративные модели можно рассматривать как основу построения инструментальных моделей лишь в редких случаях (следствие предыдущего) Специальные средства часто поддержаны инструментально (ER-диаграммы, IDEF-диаграммы и диаграммы классов RUP), но обычно это модели продуктов, а не процессов! Надо различать a)Информирующие получение сведений о ходе развития, b)Направляющие получение и оценка вариантов развития, c)Контролирующие автоматизация контрольных функций виды модели со своими инструментами для каждого из вариантов типов жизненных циклов Для каждого из типов жизненных циклов различна значимость (a, b, c) Что такое типы жизненных циклов? –Методология разработки проекта –Адаптация методологии к конкретным условиям (требования, персонал, концепции развития и т.д.) –Возможные операционные маршруты участников процесса (деятельность руководства проекта и разработчиков, а также ее регламенты) 113

114 Выводы Перспективность инструментальных моделей развития инструментов поддержки зависит от методологии проекта, ее адаптации к конкретным условиям Дает ли инструментальная модель возможность технологии? Нет! Это всего лишь средство поддержки Какие преимущества появляются при использовании инструментальной модели? Автоматизация деятельности по управлению развития проектами данного типа. Не так уж мало! Проблемы: –Признание необходимости инструментальной поддержки регламентированной разработки проектов –Выбор адекватных нотаций (RUP один из примеров) 114

115 Использованные источники 1.Боэм Б.У. Инженерное проектирование программного обеспечения. М.: Радио и связь, Бркус Ф.П. Мифический человеко-месяц, или как проектируются программные системы. СПб.: Символ-Плюс, Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс расзаботки программного обеспечения. СПб.: Питер, Гантер Р. Методы управления проектированием программного изделия. М.: Мир, Скопин И.Н. Основы менеджмента программных проектов. М.: ИНТУИТ.РУ «Интернет-Университет Информационных Технологий», Сомервилл И. Инженерия программного обеспечения. М.: Вильямс, Шафер Д.Ф. Фатрелл Р.Т., Шафер Л.И. Управление программными проектами: достижение оптимального качества при минимуме затрат. М.: Издательский дом «Вильямс», Boehm B. A Spiral Model of Software Development and Enhancement. IEEE Computer, 21 (5), pp Microsoft Solutions Framework

116 Особенности первой итерации объектно- ориентированного программного проекта

117 В пределах одной итерации процесс развития проекта остается последовательным: планирование, определение требований, анализ, конструирование, программирование, тестирование и оценка Мотивация особого подхода к выполнению первой итерации и сохраняет недостатки традиционных технологий велика неопределенность проекта не хватает критериев предпочтения одних решений перед другими Возрастает риск невыполнения проектного задания Итеративное наращивание серия коротких мини-циклов не хватает опыта у разработчиков 117

118 Метод « Сначала в глубину » разновидность нормального итеративного наращивания, приспособленного к задачам начального периода развития проекта Противоположный подход «Сначала в ширину» Главные преимущества подхода «Сначала в глубину»: Процесс разработки продвигается вперед довольно быстро Разработчики за короткое время начинают доверять методу Критерии можно определить позже Разработчики, особенно новые, быстрее вникают в проект 118

119 Рабочие продукты первой итерации как прототип будущей системы Первая реальная информация о фактических пользовательских потребностях далее процесс конструирования будет более целенаправленным и экономным; Возможность уточнить априорное распределение ресурсов всех видов; Прототип это –первый контакт с пользователями, по которому будут судить о будущих перспективах –первая возможность выставить для заказчика счет за проделанную работу. Первые достижения проекта, ревизия дальнейших планов. Целесообразно или нет дальнейшее развитие проекта. Чему научились: наличие конкурентных работ и сопоставление их с затратными и временными характеристиками проекта проектные требования понимаются правильнее по сравнению с первоначальным представлением о них правдоподобность сделанных априорно оценок (затратных, временных и др.) уровень сложности представляемого прототипа; фактическое потребление ресурсов в сравнении с их плановыми оценками Может оказаться, что данный проект значительно труднее реализуем (дороже, требует повышенной квалификации кадров и др.), чем это казалось ранее. 119

120 Переход от предварительного анализа к первой итерации Задачи менеджмента в контексте работ перехода к первой итерации. Меняется точка зрения на итерацию и на проектируемое изделие: вместо проблемно-ориентированных объектов реализационные объекты модели уровня анализа модели для декомпозиции появляются специфичные для реализационной среды классы, (к примеру, специфицируются интерфейсные и классы обращения к базам данных) конкретизируются и уточняются стратегии и методики, намеченные ранее Особенности первого для разработчиков перехода к первой итерации: Заканчивается предварительный анализ для всего проекта (общий план проекта и первые документы фазы анализа, строится общая база всех итераций); Начинается и заканчивается текущий анализ для итерации-прототипа (планирование) Работа над проектом перестает быть личным делом менеджера: –функции управления распределяются между исполнителями ключевых ролей, –функции контроля и согласования почти вытесняют все другие виды работ менеджера. Методы предварительного анализа должны предусматривать возможность конструирования, когда нет объективных данных для принятия тех или иных реализационных решений о проекте Схему Задание (выдает менеджер) Выполнение (деятельность работника) должна сменить организационная методология (методика) с более сложными связями в коллективе и более глубокими разделение труда и распределением ответственности 120

121 3 ' Автономная работа Совместная работа с выбранными сценариями Модели сценариев построены Интеграция Начата интеграция сценариев 5 5" Сценарии реализованы, базовый набор требований определен Анализ осуществи- мости Модель метода « Сначала в глубину » Констру- ирование Оценка Фазы (этапы) Конт- рольные точки (события): Исследова ния Начальная фаза проекта Мини-циклы реализации сценариев Выбор сценариев для реализации сделан 2 ' Требования к следующей ите- рации приняты Демонстрационные испытания завершены Переход к следующей итерации Продолжение проекта 9810 Пополнение базового окружения проекта Программирование 121

122 7. Жизненный цикл в методологиях быстрого развития проектов 122

123 123 Мотивация рассмотрения моделей жизненного цикла в методологиях быстрого развития Сторонники быстрого развития утверждают, что они не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта Отслеживание процесса не требует специальных документов о достигнутых результатах и проблемах. Деятельности менеджера в жестких методологиях противопоставляются самодисциплина и сотрудничество вместо дисциплины и подчинения; Особенности планирования, контрольных и других функций Все это позволяет менеджеру в большей мере сосредоточиться на руководстве командой, чем на управлении. Тем не менее, понятие жизненного цикла полезно для представления процесса разработки на концептуальном уровне Модели жизненного цикла быстрого развития не претендуют на инструментальность Понятия контрольных точек и контрольных мероприятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным, а выполнение рассредоточенным

124 Agile Manifesto Индивидуумы и взаимодействия важнее процессов и инструментов; Работоспособное ПО важнее обширной документации; Сотрудничество с заказчиком важнее заключения контракта; Готовность к изменениям важнее следования плану. 124

125 125 Общая модель жизненного цикла в методологиях быстрого развития Начальная фаза. Она выделена, поскольку приходится выполнить работы, которые не являются характерными для основного процесса; Серия максимально коротких итераций, состоящих из шагов: –выбор реализуемых требований (сценариев; в экстремальном программировании пользовательских историй), –реализация только отобранных требований, –передача результата для практического использования; –короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием); Фаза заключительной оценки разработки проекта Реальные быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками Сегодня есть тенденция к стандартизации agile процессов и появились первые группы с международными сертификатами Не станут ли agile методологии жесткими?

126 12 методик, относящихся к управлению и руководству. Бек подчеркивает, что все они должны быть внедрены 1.Упреждающее тестирование 2.«Путешествие налегке» 3.Общее владение кодом 4.Частые интеграции 5.Парное программирование 6.Сбор пользовательских историй 7.Заказчик как член команды 8.Игра в планирование 9.Менеджер наставник 10.«Стоячие» совещания Некоторые организационные правила и принципы. Утверждается, в частности, что при eXP «архитектор проекта не нужен». Почему? Как все это согласуется с общими понятиями жизненного цикла? Неявное (деперсонифициоранное, распределенное по времени и рассредоточенное по проектным работам) выполнение всего то же, что выполняется в любом проекте. слияние контрольных точек, облегченные подготовка к прохождению вех и само прохождение 126 Модель жизненного цикла экстремального программирования Достижение договоренности о том, что: нужно пользователю (заказчик, приоритеты см. 7); возможно сделать разработчиками (за что они берутся, за какой срок и пр.) Тесты составляются до программ Программный модуль считается принятым, если 100% прежних тестов прошли Новые тесты прошли Не стоит абсолютизировать переиспользование кода Функция интеграции кода распределена по всем разработчикам Каждая новая реализуемая возможность, специфицированная тестами требует интеграции непосредственно после прохождения всех тестов(см. 1) Программный модуль – сфера ответственности всей команды, но разрабатывается программистом, которому может потребоваться помощь. Он обращается к команде и получает квалифицированного коллеги. Пишут вдвоем (один пишет, другой наблюдает), возможно, по очереди. Вариант: устойчивые пары (самоорганизующаяся рабочая группа) Социальная специфика Основа разработки: то, что требуется пользователю для его работы, то, как он это видит. Это база для разработки тестов. Главная документация проекта Возможно просто составление тестов Пользовательские истории – часть базы данных тестов Обязательное условие. Он отвечает за (6) и (8), является экспертом в предметной области, способен выставить приоритеты пользовательским потребностям Функции менеджмента – помощь в трудных ситуациях, поддержка, советы, распределение ресурсов, (вехи – это праздники проекта) Обсуждение стоя способствуют краткости совещаний можно проводить ежедневно и оперативно Команда работает в одной комнате, индивидуальные рабочие места – визуально доступные отсеки Общая рабочая доска, на которой отмечаются текущие и будущие дела

127 127 Итерации Обслуживание и поддержка Модель жизненного цикла экстремального программирования 4 Обзор системы и процесса ее разработки Итоговая оценка Первый релиз Последующие релизы Исследова- Смерть ние Итерации Сбор пользовательских историй (сценариев) 11 6 ние 10 Внедрение Планирова- ние 3 Начальная фаза Серия итераций Планирова-

128 128 Адаптивная разработка (ASD Adaptive Software Development) по Хайсмиту ASD это не готовая методология, а базовая концепция для различных адаптивных разработок L3 L2 Инициация проекта Планирование адаптивного цикла L1 Совместное конкурирующее развитие возможностей L1 Совместное конкурирующее развитие возможностей Обзор качества Итоговый обзор качества и выпуск релиза СотрудничествоОбдумываниеОбучение Цикл обучения Цикл адаптации

129 129 Основные принципы адаптивного подхода Адаптивная природа всех быстрых методологий следствие непредсказуемости процесса разработки ПО (Хайсмит использует идеи из области теорией хаоса) Основа ASD три нелинейные перекрывающие друг друга фазы: обдумывание сотрудничество обучение В окружении, которое требует адаптивности, планирование парадокс (непредсказуемость) Обычно отклонения от плана ошибки, нуждающиеся в исправлении. В адаптивных разработках отклонения ведут к объективно обусловленным решениям их следует считать правильными Неопределенность в непредсказуемой среде преодолевается за счет активного сотрудничества разработчиков Внимание менеджмента направлено на обеспечение коммуникации Разработчики сами находят ответы на возникающие вопросы Повышенное внимание к обучению (в предсказуемых методологиях его роль часто занижается: все расписывается заранее, так что потом остается только следовать плану) «Основное, наиболее действенное и первостепенное, достоинство жизненного цикла ASD заключается в том, что этот процесс заставляет отказаться от интеллектуальных построений, которые являются источником самообмана. Он вынуждает оценивать собственные способности более реалистично» Семейство методологий Crystal: –разным проектам нужны разные методологии –градация проектов: по одной оси количество людей в проекте, по другой критичность ошибок –каждая из методологий семейства предназначена для определенной ячейки получившейся сетки «Проект, в котором занято 40 человек, и на котором можно позволить себе потерять некоторую сумму, будет работать по другой методологии, нежели проект для шести разработчиков, от которого зависит существование компании» (Коуберн)

130 8. Проблемы оперирования требованиями 130

131 131 Анализ требований Что такое требования к программному изделию? Два аспекта: Средства программного изделия, в которых нуждается пользователь для решения своих проблем или достижения определенных целей (Что?); Характеристики, которым должна обладать система в целом или ее компонент, чтобы удовлетворять соглашениям, спецификациям, стандартам или другой формально установленной документации (Как?).

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

133 Модельные представления уровня конструирования 7. Документные представления 6. Программные представления 3. Типизированные представления требований Глоссарий проекта Т абстр Т экон Т функ Т инт Т эфф Т a (a1,…,an a ), Т b (b1,…,bn b ),Т c (c1,…,cn c ), …,Т z (z1,…,zn z ) 2. Унифицированные представления требований 4. Модельные представления уровня анализа Трассировка требований 1.Исходное представление требований 1. Текстовое описание пожеланий к системе, заданное в свободной форме 2. Элементарные составляющие требований для единообразного использования 3. Элементарные составляющие требований, каждое из которых приписывается к некоторому типу (атрибуты распределяются по уровням иерархии типов) 6. Программные рабочие продукты и их фрагменты 5. Диаграммы классов и др. диаграммы 7. Фрагменты документных рабочих продуктов 4. Образы составляющих как элементы аналитических моделей системы

134 134 Трансформация требований 1.Исходное представление текстовое описание пожеланий к системе, заданное в свободной форме. 3.Типизированное представление элементарные составляющие требований, каждое из которых приписывается к некоторому типу (атрибуты на уровнях иерархии типов). 2.Унифицированные представления элементарные составляющие требований для единообразного использования. 4.Модельные представления уровня анализа образы составляющих как элементы аналитических моделей системы. 5.Модельные представления уровня конструирования диаграммы классов и др. 6.Программные представления программные рабочие продукты и их фрагменты. 7.Документные представления фрагменты документных рабочих продуктов. Глоссарий проекта

135 135 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

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

137 137 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

138 Понимание пользовательских потребностей Требования исходят из многих источников, их количество бывает значительно. Следовательно, необходима типизация требований. Уровни типов. Результат:система типов требований для данного проекта.

139 Модельные представления уровня конструирования 7. Документные представления 6. Программные представления 3. Типизированные представления требований Глоссарий проекта Т абстр Т экон Т функ Т инт Т эфф Т a (a1,…,an a ), Т b (b1,…,bn b ),Т c (c1,…,cn c ), …,Т z (z1,…,zn z ) 2. Унифицированные представления требований 4. Модельные представления уровня анализа Трассировка требований 1.Исходное представление требований

140 140 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

141 Преодоление сложности многофункциональности требований Требования характеризуют изделие с разных сторон многофункциональность Инициаторы работ (stakeholders) те, кто определяют главные требования. Представи- тель заказчика Представи- тель поль- зователя Инвестор Менеджер по продажам Покупатель менеджер проекта, эксперт предметной области, специалист по пользовательскому интерфейсу, архитектор и проектировщики подсистем, тестировщики. …

142 142 Методы преодоления сложности многофункциональности Интервью и мозговые штурмы, опросы и анкетирование, изучение прототипов Выполняется в течение всего проекта! Результат: перечень типизированных требований, описанных текстуально и/или графически, порядок которого соответствует приоритетности требований.

143 143 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

144 144 Результат:группа требований, выделенная в процессе оперирования для тех или иных целей. 4. Оперирование с многомерными требованиями одновременное оперирование с разными параметрами отбора требований для анализа Организация хранения и предъявления требований архитектор, проектировщики подсистем и менеджер проекта, разработчик информационной поддержки и библиотекарь Цель: организация помощи при отборе требований Параметры отбора: тип требования, приоритетность, … Тип требования набор атрибутов, атрибут набор значений. Оперирование с требованиями один из основных методов аналитической работы

145 145 Приемы работы с требованиями 1.Анализ проблем 2.Понимание пользовательских потребностей 3.Преодоление сложности многофункциональности 4.Оперирование с многомерными требованиями 5.Определение системы 6.Управление областью применимости системы 7.Детализированное определение системы 8.Использование метафор 9.Моделирование требований 10.Управление изменениями требований 11.Сохранение истории изменений требований 12.Организация работ с требованиями

146 Определение системы Результат: Точное и согласованное определение системы. Трансформация потребностей и перечня требований в описание для разработки. Общие соглашения: как понимаются требования и их приоритетность, оценка затрат и ресурсных потребностей, рисковые ситуации и стратегия управления рисками. Границы применения будущей системы. Виды рабочих продуктов, правила их построения, проверки и т.д. Внешние рабочие продукты и способы их использования в проекте: применение результатов, использование как прототипов и др. Форма представления определения системы: тексты, схемы, гипертекстовая структура и др. Перед составлением формализованных модельных описаний следует сначала представить их на естественном языке!