Управление содержанием и сроками программного проекта

1.

Управление содержанием и
сроками программного
проекта

2. 2.5. Коммерциализация результатов

Тип рынка, переменные сегментирования, целевые
сегменты рынка (не менее 2), критерии привлекательности,
выбор целевого сегмента.
Конкуренты
и
конкурентные
преимущества:
сравнение по характеристикам: функциональность, цена,
качество, сервисы…..
Позиционирование:
типы
потенциальных
потребителей, их потребительские предпочтения, выбор
стратегии позиционирования ПП.
Инструментов
продвижения
коммуникационного сообщения.
ПП,
текста
Стратегия ценообразования, рыночная цена продажи ,

3.

Международный стандарт
PMBOK 5-th Edition
Этапы ЖЦ программного проекта
инициация
планирование
исполнение
завершение
мониторинг и управление

4.

Международный стандарт PMBOK 5-th Edition
процессы (область знаний) по управлению проектами:
1) управление интеграцией проекта (Project Integration Management);
2) управление содержанием проекта (Project Scope
Management);
3) управление сроками проекта (Project Time Management);
4) управление стоимостью проекта (Project Cost Management);
5) управление качеством проекта (Project Quality Management);
6) управление человеческими ресурсами проекта (Project Human
Resource Management);
7) управление коммуникациями проекта (Project Communi-cations
Management);
8) управление рисками проекта (Project Risk Management);
9) управление закупками проекта (Project Procurement Ma-nagement);
10) управление заинтересованными сторонами проекта (Project
Stakeholder Management).

5.

Схема управления проектом
Сведения о ходе
выполнения плана
Календарный план
Требования
Мониторинг
выполнения
плана
Планирование
проекта
Анализ
выполнения
плана
Управление
изменениями
Отклонения незначительны
Отклонения значительны

6. Планирование

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

7. Планирование

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

8.

Мониторинг состояния
выполнения проекта
Контроль
отклонений
плановых и
фактических
характеристик
проекта
содержание
сроки
бюджет
качество
Упреждающий
контроль
прогнозирование
состояния будущих
работ
«Что произойдет,
если тенденция по
реализации проекта
будет сохраняться?»
Традиционный
контроль
контроль
выполнения работ
на конкретную дату

9.

Анализ выполнения плановых заданий
Сравнение плановых и фактических характеристик проекта
определение
критических
отклонений
Содержание
Сроки
Бюджет
Качество
Варианты решений
корректировка плана работ за счет перераспределения либо
привлечения ресурсов
разработка нового варианта календарного плана

10.

Мониторинг исполнения
бюджета проекта
Метод освоенного объема-основы
текущее состояние проекта:
по освоению бюджета- фактическим затратам
по выполнению календарного плана проекта;
фактические затраты и исполнение календарного
плана измеряются в денежном выражении.

11.

Метод освоенного объема
Показатели - исходные
плановые бюджетные затраты (ПБЗ) — плановая
стоимость (объем) запланированных работ проекта -утвержденная расходная часть бюджета проекта -нарастающим итогом
освоенный бюджет (ОБ) — плановая стоимость объема
выполненных работ проекта, представленных в бюджете
проекта -- нарастающим итогом
фактический бюджет (ФБ) — фактическая стоимость
выполненных работ проекта в соответствии с
календарным планом проекта -- нарастающим итогом

12.

Динамика изменения параметров бюджета проекта
Стоимость
Прогноз фактической стоимости будущих работ
Отклонение
по объему
работ
ПБЗ
ФБ
Прогноз стоимости работ
при плановых затратах
Отклоне-ние
по стоимости
ОБ
Текущая дата
Дата завершения Текущий прогноз
по плану
даты завершения
по плану
ПБЗ — плановые бюджетные затраты; ФБ — фактический бюджет;
ОБ — освоенный бюджет
Динамика параметров бюджета проекта
Время

13.

Метод освоенного объема
Показатели текущего состояния проекта
Отклонение по стоимости на данный период времени -- CV=
OБ+ФБ выполнение плана по стоимости проекта — сравнение
реально выполненных работ по плановым (бюджетным) и
фактическим расходам.
CV> 0 - экономия бюджета, CV < 0 --перерасхода бюджета
Отклонение по срокам SV= ОБ +ПБЗ выполнение календарного
плана проекта— сравнение выполненного объема работ и
объема работ, который должен быть выполнен согласно
календарному плану проекта.
SV > 0 - опережение календарного плана работ
SV < 0 -срыва календарного плана выполнения работ.

14.

Метод освоенного объема
Показатели состоянии проекта
в будущих периодах времени
Пессимистическая оценка фактической стоимости (бюджета) проекта к
моменту его завершения ЕАС=ПБЗ/ CPI—отставания (как по бюджету, так
и по срокам) на момент контрольной даты, будут продолжаться с такой
же интенсивностью и в оставшейся части проекта, ПБЗ — величина
плановых бюджетных затрат нарастающим итогом на момент окончания
проекта.
Оптимистическая оценка фактической стоимости (бюджета) проекта к
моменту его завершения - ЕАС = ФБ – ПБ- отставания, которые были
допущены, не будут повторяться, и оставшаяся часть проекта будет
исполняться в соответствии с планом, ПБ — остаток планового бюджета
проекта на текущий момент времени .
Прогнозная оценка стоимости выполнения оставшихся работ проекта от
момента анализа до окончания проекта -- суммы денежных средств ЕТС,
которые предстоит дополнительно израсходовать для завершения
проекта: ЕТС = ЕАС – ФБ.

15.

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

16.

Оценка качества процессов управления проектом
«Какими признаками должна обладать
профессиональная организация
по разработке ПП?»
Стандарт CMM
Capability Maturity Model (for Software)
модель технологической зрелости процессов
управления разработками программного
обеспечения

17.

Уровни технологической зрелости
Начальный
Управления разработкой программных проектов в
основном не регламентированы. Успех проекта зависит
от компетенции отдельных сотрудников
Повторяемый
Базовые
процессы
управления
программным
проектом. Соблюдается
регламент выполнения
работ и обеспечивается возможность
его
повторения
при
выполнении
аналогичных
проектов.

18.

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

19.

Уровни технологической зрелости
Оптимизируемый
Совершенствование
процессов
управление
программным проектом происходит постоянно как
на основе количественного анализа эффективности
процессов,
так
и
использовании
новых
методологий иинструментальных средств

20.

Структурная декомпозиция работ и формирование
календарного плана реализации программного
проекта
Постановка задачи
Команда разработала концепцию рыночного
программного продукта, нашла источники
финансирования и приняла решение о
разработке сбалансированного по бюджету и
срокам календарного
плана реализации
проекта.

21.

Управление содержанием и сроками
Структурная
декомпозиции проекта
определение множества
процесов, работ, задач
Оценка рисков
связанных с выполнением
работ
Определение
зависимостей
между работами, определение
функциональных ролей и
исполнителей для каждой
работы
Разработка календарного
плана проекта
плана распределения
ресурсов, бюджетного плана,
плана управления рисками
Оценка трудозатрат
и длительности
выполнения работ

22.

Структурная декомпозиция
проекта -Стандарты ЖЦ, Архитектура ПП,
Модели разработки

23.

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

24.

Модели ЖЦ разработки
ГОСТ Р ИСО/МЭК 12207-2010
стадия, процесс, действие, задача
Стандарт IEEE 1074
фазы, процессы, действия
ГОСТ 19.102-77 ЕСПД «Стадии разработки»
стадии, этапы, работы
РМВОК - Свод знаний по управлению проектами
процессы (области знаний), этапы (фазы)

25. Элементы ЖЦ

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

26.

ГОСТ Р ИСО/МЭК 12207-2010
процессы разработки
анализ требований к системе;
проектирование системной архитектуры;
анализ требований к программным средствам;
проектирование программной архитектуры;
техническое проектирование программных средств;
программирование и тестирование программных средств;
сборка программных средств;
квалификационные испытания программных средств;
сборка программной системы;
инсталяция на программно- аппаратных средствах заказчика;
квалификационные испытания системы;
ввод в действие программных средств;
обеспечение приемки программных средств.

27. Проектирование программной архитектуры -задачи

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

28. . Определить нормативный перечень работ по созданию ПП

Ознакомиться с содержание стандарта
ГОСТа Р ИСО/МЭК 12207-2010
«Информационная технология.
(приложение1). Определить с учетом
целей и задач, описанных в концепции
перечень работ создания ПП
.

29.

Физическая архитектура программных систем
архитектура «файл-сервер»;
многозвенная архитектура «клиент-сервер»;
архитектура Веб-приложений;
архитектура распределенных систем;
сервис-ориентированная архитектура;
многоагентная архитектуры.

30.

Архитектура программного продукта
Программный продукт
Программный
комплекс
Программный
комплекс
Программа
Программа
Программный
модуль
Программный
модуль

31.

ЭЛЕМЕНТЫ АРХИТЕКТУРЫ
Программный
комплекс
совокупность двух и более взаимосвязанных
программ, в которых функционирование
одного из них зависит от результатов
функционирования другого.
Программа
совокупность программных модулей,
реализующих конкретный бизнес-процесс.
Программный
модуль
совокупность программных кодов,
реализующих элементарную функцию
бизнес-процесса.

32.

33. Описание архитектуры ПП.

Представить архитектуру программного
продукта в виде совокупности
программных комплексов (программ,
программных модулей) и интерфейсов.

34. Онлайн-платформа для организации дистанционного обучения “Доценс”;

Сервер базы данных: пользователей, учебных
программ; модуль авторизации пользователей.
Клиент
модуль создания учебных программ и заданий;
модуль загрузки файлов на сервер, путем разбиения
файлов на чанки и переводом их в base64 для
ускорения загрузки;
модуль создания личного дневника с оценками для
каждого ученика;
модуль личного взаимодействия путем чата между
учениками, родителями и учителями.

35.

Элементы архитектуры:
Web-ГИС-сервер, предназначенное для обеспечения web-доступа к
средствам хранения и анализа данных ЭГП.
Web-ГИС-клиент, предназначенное для обеспечения графического
интерфейса конечного пользователя ЭГП.
Хранилище пространственно-временных данных, предназначенное для
обеспечения централизованного ведения пространственных и
атрибутивных описаний объектов ЭГП.
ПО информационной безопасности, предназначенное для обеспечения
информационной защищенности пространственных и атрибутивных
данных ЭГП.
Электронный документооборот предназначенное для обеспечения
организационно-распорядительного механизма развития ЭГП.

36.

Нормативный перечень работ по элементам архитектуры
Объекты
Задачи
Программный
продукт
1. Разработка функциональных
требований к ПП
+
2. Разработка системных требований
к ПП
+
Программный
комплекс
Программный
модуль
Программа
1
2
1
2
+
+
+
+
1, 2
3. Разработка технического задания
на ПП
4. Проектирование архитектурного
дизайна как многоуровневой структуры
ПП
6. Проектирование архитектуры
программных комплексов, программ
+
7. Программирование программных
модулей
++
8. Разработка технической
документации на модуль
++
9. Модульное тестирование
10. Сборка программы
11. Разработка пользовательской
документации на программу
12. Тестирование программ
++
+
+
+
+
+
+

37.

Нормативный иерархический список работ
программного проекта
1 Разработка программного продукта
1.1 Разработка функциональных требований к ПП
………………………………………….
1.4 Проектирование архитектурного дизайна ПП
1.4.1 Разработка программного комплекса 1
1.4.1.1 Проектирование архитектуры программного комплекса 1
1.4.1.1.1 Разработка программы 1
1.4.1.1.1.1 Проектирование архитектуры программы 1
1.4.1.1.1.1.1 Разработка программного модуля 1
1.4.1.1.1.1.1.1 Программирование модуля 1
1.4.1.1.1.1.1.2 Разработка документации на модуль 1
1.4.1.1.1.1.1.3 Тестирование модуля 1
1.4.1.1.1.1.2 Разработка программного модуля 2
1.4.1.1.1.1.2.1 Программирование модуля 2
………………………………………………
1.4.1.1.1.2 Сборка программы 1
………………………………………………………………….
1.4.2 Разработка программного комплекса 2
1.4.2.1 Проектирование архитектуры программного комплекса 2
1.4.2.1.1 Разработка программы 1
1.4.2.1.1.1 Проектирование архитектуры программы 2
………………………………………………………..
1.19. Ввод в эксплуатацию ПП

38.

Древовидная структуры зависимостей между задачами
Программный продукт
Программный
комплекс
Разработка
функциональных
требований
Проектирование
архитектуры
Тестирование
Программа
Проектирование
архитектуры
Сборка
Программный
модуль
Программирование
Документирование
Модульное
тестирование

39. 1. Выбор модели разработки ПП.

На основе анализа характеристик
процессов разработки вашего
программного продукта выбрать по
методике одну из моделей разработки:
инкрементную, прототипирования,
спиральную.
.

40.

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

41.

Методика выбора модели
разработки ПП
Особенности процесса выявления требований к ПП
Квалификации команды
Участия в проекте коллектива пользователей
Сложность проекта
RAD
Нет
Да

42.

Характеристики модели
в зависимости от особенностей процесса выявления требований к ПП
Требования
Каскадная
V-образ-
ная
Прототипирование
Спиральная
RAD
Инкрементная
Являются ли требования легко
определимыми и/или хорошо известными?
Да
Да
Нет
Нет
Да
Нет
Могут ли требования заранее определяться
в цикле?
Да
Да
Нет
Нет
Да
Да
Часто ли будут изменяться требования?
Нет
Нет
Да
Да
Нет
Нет
Нужно ли демонстрировать требования с
целью определения?
Нет
Нет
Да
Да
Да
Нет
Требуются ли для демонстрации
возможностей ПП проверка концепции?
Нет
Нет
Да
Да
Да
Нет
Будут ли требования отражать сложность
системы?
Нет
Нет
Да
Да
Нет
Да
Обладает ли требование функциональными
свойствами на раннем этапе?
Нет
Нет
Да
Да
Да
Да

43.

Характеристики модели
в зависимости от квалификации команды разработчиков
Команда разработчиков проекта
Спиральная
RAD
ная
Прототипирование
Инкрементная
Нет
Нет
Да
Да
Нет
Нет
Является ли технология предметной
области проекта новой для
большинства разработчиков?
Да
Да
Нет
Да
Нет
Да
Являются ли инструменты,
используемые проектом, новыми для
большинства разработчиков?
Да
Да
Нет
Да
Нет
Нет
Изменяются ли роли участников
проекта во время жизненного цикла?
Нет
Нет
Да
Да
Нет
Да
Могут ли разработчики проекта пройти
обучение?
Нет
Да
Нет
Нет
Да
Да
Является ли структура ПП более
значимой для разработчиков, чем
гибкость?
Да
Да
Нет
Нет
Нет
Да
Будет ли менеджер проекта строго
отслеживать прогресс команды?
Да
Да
Нет
Да
Нет
Да
Важна ли легкость распределение
ресурсов?
Да
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Нет
Да
Являются ли проблемы предметной
области проекта новыми для
большинства разработчиков?
Приемлет ли команда равноправные
обзоры и инспекции,
менеджмент/обзоры заказчика, а также
стадии?
Каскад-
V-образ-
ная

44.

Характеристики модели
в зависимости от участия в проекте коллектива пользователей
Каскадная
V-образная
Прототипирование
Спиральная
RAD
Инкрементная
Будет ли присутствие
пользователей ограничено
в жизненном цикле?
Да
Да
Нет
Да
Нет
Да
Будут ли пользователи знакомы
с определением системы?
Нет
Нет
Да
Да
Нет
Да
Буду ли пользователи
ознакомлены с проблемами
предметной области?
Нет
Нет
Да
Нет
Да
Да
Будут ли пользователи вовлечены
во все фазы жизненного цикла?
Нет
Нет
Да
Нет
Да
Нет
Будет ли заказчик отслеживать ход
выполнения проекта?
Нет
Нет
Да
Да
Нет
Нет
Коллектив пользователей

45.

Характеристики модели в зависимости от сложности проекта
Каскадная
V-образная
Прототипирование
Спиральная
RAD
Инкрементная
Будет ли проект идентифицировать новое
направление продукта для организации?
Нет
Нет
Да
Да
Нет
Да
Будет ли проект иметь тип системной
интеграции?
Нет
Да
Да
Да
Да
Да
Будет ли проект являться расширением
существующей системы?
Нет
Да
Нет
Нет
Да
Да
Будет ли финансирование проекта
стабильным на всем протяжении жизненного
цикла?
Да
Да
Да
Нет
Да
Нет
Ожидается ли длительная эксплуатация
продукта в организации?
Да
Да
Нет
Да
Нет
Да
Должна ли быть высокая степень
надежности?
Нет
Да
Нет
Да
Нет
Да
Будет ли система изменяться, возможно, с
применением непредвиденных методов, на
этапе сопровождения?
Нет
Нет
Да
Да
Нет
Да
Является ли график ограниченным?
Нет
Нет
Да
Да
Да
Да
Являются ли «прозрачными» интерфейсные
модули?
Да
Да
Нет
Нет
Нет
Да
Доступны ли повторно используемые
компоненты?
Нет
Нет
Да
Да
Да
Нет
Являются ли достаточными ресурсы (время,
деньги, инструменты, персонал)?
Нет
Нет
Да
Да
Нет
Нет
Тип проекта и риски

46.

Постановка задач
R 1,..r..,6 - множество моделей жизненного цикла ПП
r R - группами характеристик I 1,.. j.., 4
j 1,.. j.., n - множество показателей входящих в состав
каждой группы
X r x , i l ,4, j 1, n - множество нормативных показателей r-ой
r
ij
r
ij
x
модели ЖЦ
- характеризуется наличием либо отсутствием j-ого
свойства модели в i-ой группе и оценивания в качественной
шкале -- (да, нет)

47.

Постановка задач
R 1,..r..,6 - множество моделей жизненного цикла ПП
r R - группами характеристик I 1,.. j.., 4
j 1,.. j.., n - множество показателей входящих в состав
каждой группы
X r x , i l ,4, j 1, n - множество нормативных показателей r-ой
r
ij
r
ij
x
модели ЖЦ
- характеризуется наличием либо отсутствием j-ого
свойства модели в i-ой группе и оценивания в качественной
шкале -- (да, нет)

48.

Сетевая модель архитектурыприоритеты, связность
элементов.

49.

Приоритезация требований
Карл Вигерс, Джой Битти. Разработка требований к программному
обеспечению. 3-е изд., дополненное / Пер. с англ. М.: Издательство
«Русская редакция»; СПб.: БХВ-Петербург, 2014. 736 стр.

50.

Приоритезация требований
Приоритет - численная интегральная оценка
относительной важности реализации требования
О
Определить методом экспертных оценок
приоритеты для каждого элемента архитектуры:
выбрать критерии оценки,
измерительные шкалы,
провести оценивание,
рассчитать приоритеты.

51. Критерии и измерительные шкалы

Бизнес-ценность-- ценность для бизнеса (влияние на
результат) с точки зрении команды проекта и заказчика –
ранговая (порядковая) шкала или шкала интервалов
Трудозатраты - усилия команды на реализацию требования
в человеко-днях /часах (минимальные-максимальные) –
абсолютная шкала с переводом в шкалу отношений
Волатильность требований - вероятность изменения
требования в течении очередной итерации – шкала
интервалов
Связность -количество прямых зависимостей для
реализации других требований - абсолютная шкала с
переводом в шкалу отношений …….
Гудков П.А. Методы сравнительного анализа: Учеб. пособие.
Пенза: Изд-во Пенз.гос. ун-та, 2008. 81 с.

52. Виды зависимостей между элементами архитектуры

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

53.

Сетевая модель архитектуры
Каждый модель представляется как точка (вершина графа) на
плоскости и соединяется с другой вершиной связью типа «дуга» или
«ребро» .
Связь типа «дуга» -- если между модулями существуют технологическая
завимимость.
Связь типа «ребро» если модули независимы.
Смешанный граф
—
, где X — множество модулей Ū, и U ,
G (X ,U ,U )
множество ребер и дуг.

54.

Смешанный граф
Н
(i1 , z1 )
(i1 , z2 )
(i1 , z4 )
(i2 , z1 )
(i2 , z2 )
(i2 , z3 )
(i3 , z1 )
(i3 , z3 )
(i3 , z4 )
К
Задача определения календарного плана состоит в
формировании из графа G ( X , U , U ) ориентированного графа ,
( X , U )
G
путем замены по правилу предпочтения ребер на
направленные дуги.

55.

Ориентированный граф G
Н
(i1 , z1 )
(i1 , z2 )
(i1 , z4 )
(i2 , z1 )
(i2 , z2 )
(i2 , z3 )
(i3 , z1 )
(i3 , z3 )
(i3 , z4 )
К

56. Алгоритм построения ориентированного графа

1 Выделить из множество вершин ( модулей) , в которые не входит
ни одна дуга. Определим это множество как «множество
ожидаемых работ».
2 Если множество ожидаемых работ пусто , то переход к шагу 7.
3 Выбрать из множества ожидаемых работ предпочтения работу
c max P(x) .Переместим ее в множество «последовательностьочередность реализации».
4 Определить множество вершин смежных с данной вершиной и
связанных с ней технологической зависимостью типа
«ребро».
5 Заменить все ребра, соединяющие данной вершиной со
смежными , на исходящие из нее дуги..
6. Удалить текущую работу работу из множества ожидаемых
работ, добавим новую. Переход к шагу 3.
7 Конец

57. Алгоритм определения очередности реализации моделей

1 Выделить из множество вершин ( модулей) , в которые не входит
ни одна дуга. Определим это множество как «множество
ожидаемых работ».
2 Если множество ожидаемых работ пусто , то переход к шагу 6.
3 Выбрать из множества ожидаемых работ работу c max P(x)
.Переместим ее в множество «последовательностьочередность реализации».
4 Определить множество вершин связанных с данной вершиной
технологической зависимостью, удалить связи.
5. Удалить текущую работу из множества ожидаемых работ, в
случае необходимость добавим новую. Переход к шагу 3.
6 Конец

58. Онлайн-платформа для организации дистанционного обучения “Доценс”;

Сервер базы данных: пользователей, учебных
программ; модуль авторизации пользователей.
Клиент
модуль создания учебных программ и заданий;
модуль загрузки файлов на сервер, путем разбиения
файлов на чанки и переводом их в base64 для
ускорения загрузки;
модуль создания личного дневника с оценками для
каждого ученика;
модуль личного взаимодействия путем чата между
учениками, родителями и учителями.

59. Определить очередность реализации модулей

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

60.

Функциональные роли,
оценка трудозатрат

61.

Функциональные роли
Программист
Системный аналитик
Специалист по тестированию в
области информационных
технологий
Архитектор
программного обеспечения
Технический писатель
Специалист по
информационным ресурсам
Администратор
баз данных
Менеджер продуктов
в области информационных
технологий

62.

Методы оценки трудозатрат
«сверху–вниз»
«снизу–вверх»
«по аналогии»
«метод функциональных точек»

63.

Оценка трудозатрат
Инженерный метод оценки трудозатрат
метод PERT-анализа
(Project Evaluation and Review Technique)
Т= (П+4Р+О)/6
П – пессимистическая оценка
Р – реалистическая оценка
О – оптимистичесая оценка

64.

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

65.

ВРЕМЕННЫЕ ЗАВИСИМОСТЕЙ МЕЖДУ РАБОТАМ
Взаимосвязь «финиш — финиш»
предшествующая работа должна заканчиваться не ранее чем
τ
за t единиц времени до окончания последующая
работ
Временя опережения
начала выполнения последующей работы определяется
вычитанием от момента начала либо окончания последующей
работы определенного количества периодов времени
Параллельно-последовательное выполнение работ
н
t ij
τ
к
t ij
н
н
t ij+ 1 = tij +τ

66.

ВРЕМЕННЫЕ ЗАВИСИМОСТЕЙ МЕЖДУ РАБОТАМ
Взаимосвязь «финиш — старт»
предшествующая работа должна заканчиваться до того
как последующая работа может начаться
Временя задержки
последующая работа должна начинаться не ранее чем через t
единиц времени после окончания предшествующей работы
Последовательное выполнение работ
н
t ij
к
t ij
τ
τ
+
н
к
t ij+ 1 = tij +
τ

67. Метод функциональных точек

Метод функциональных точек (Function Point FP) --- размеры программной системы
оцениваются в категориях количества и
сложности бизнес-процессов (функций),
реализуемых в конкретном программном коде
Ехлаков, Ю. П. Технико-экономическое обоснование стоимости программных
систем: Методические указания по выполнению экономической части
дипломного проекта [Электронный ресурс] / Ю. П. Ехлаков, Б. А. Рыбалов.
— Томск: ТУСУР, 2011. — 86 с. — Режим доступа:
https://edu.tusur.ru/publications/969

68.

Метод функциональных точек
(Function point, FP)
Архитектура ПП - многоуровневая совокупность
диаграмм бизнес-процессов предметной области.
Элементарный бизнес-процесс (функция):
обработка входных и выходных данных,преобразование
данных , обработка внешние интерфейсы.
Функциональная точка - количество
элементарных действий бизнес-процесса: ввод,
вывод , процедуры обработки файлов, структуры
данных, интерфейсы.

69. Таблица определения количества функциональных точек

№
п.п.
Категории простых
функций
Простые
Средние
Сложные
Количество
функциональных
точек
1
Количество выводов
11 X11
12 X12
13 X13
X
1
2
Количество вводов
21 X 21
22 X 22
23 X 23
X
3
Количество опросов
вывода
31 X 31
32 X 32
33 X 33
X
4
Количество опросов ввода
41 X 41
42 X 42
43 X 43
X
5
Количество файлов
51 X 51
52 X 52
53 X 53
X
6
Количество интерфейсов
61 X 61
62 X 62
63 X 63
X
Общее количество функциональных точек
2
3
4
5
6
i 6
Xi
i 1

70.

Трудозатраты на создание программного кода на
конкретном языке программирования
Количество строк кода
R( LOC)=R(F)* LOC, где
LOC — количество строк конкретного языка программирования, для
реализации одной функциональной точки
R(F) – количество функциональный точек
Трудозатраты
Регрессионная модель COCCMO (модель конструктивных затрат ):
Т= A*R( LOC)n

71.

Соответствие числа строк программы на
языке Ассемблер к одной строке другого языка
Язык программирования
1. Basic Assembler
2. Macro Assembler
3. DELPHI
4. Pascal
5. C++
6. Java
7. Oracle, Sybase
8. Access
9. Языки баз данных
10. Oracle Developer/2000
11. Smalltalk
12. Cobra
13. HTML 3.0
14. SQL (ANSI)
15. Excel
Количество строк кода
На одну
Ассемблер
функциональную
(LOC)
точку
3
1
11
3
3,5
6
6
8
8
11
14
15
16
22
25
4
320
29
107
91
53
53
40
40
29
23
21
20
15
13

72.

Структурная декомпозиция
работ проекта

73. Процедура формирования беклога (работ) спринта

Разбить в соответствии с сетевой моделью архитектуры процесс
реализации ПП на несколько (минимум 2) интервалов планирования –
(спринтов).
Сформировать-выделить состав моделей очередного спринта из сетевой
модели архитектуры.
Сформировать из нормативного списка работ с учетом особенностей
модели разработки перечень работ по реализации каждого модуля.
Назначить исполнителя по выполнению каждой работы.
Определить по формуле трудозатраты на выполнение работ.
. Результаты представить в виде таблицы 1.
Перейти к определению работ очередного спринта.

74.

Разработка
календарного плана проекта
ПП « Open Project».

75. Инструментальные средства управления программными проектами

Jira — платформа для управления проектами, задачами, отслеживания ошибок,
доступна в веб-версии и в виде десктопного приложения.
EvaProject - российская замена Jira для управления задачами и
проектами., облачная и серверная версии Доступна веб-версия,
мобильное приложение и десктоп-версия
Trello - облачная программа для управления проектами небольших групп,
использует для управления проектами парадигму «Канбан».
YouGile (российский аналог Trello ) – система управления проектами и общения
в команде, поддержка чат в каждой задаче на привычных agile-досках.
Доступна веб-версия, мобильное приложение и десктоп-версия.
Yandex Tracker – Российкий облачный сервис для небольших и средних команд описание бизнес-процессов, управление проектами и ресурсами. Доступен в
виде веб-версии, есть мобильное приложение для iOS и Android.
Redmine — открытое серверное двуязычное веб приложение для управления
проектами и задачами на основе фреймворка Ruby on Rails

76.

Формирование календарного плана реализации
программного проекта
Порядок выполнения работы
Р
на основе структурной декомпозиции работ составить скелетный план проекта;
установить (назначить)
длительность и бюджет выполнения каждой работы;
установить типы взаимосвязи между работами ( старт –финиш, финиш- старт ) ;
установить необходимые задержки;
установить нормативные трудозатраты, срок и бюджет разработки проекта указанные
в концепции;
сформировать календарный план проекта с учетом нормативных ограничений по
трудовым ресурсам и срокам проекта;
провести анализ загрузки трудовых ресурсов и в случае необходимости провести
процедуры балансировки;
отобразить календарный план проекта в виде сетевого графика и диаграммы Ганта;
представить отчеты по загрузке трудовых ресурсов, бюджету проекта и сравнить их
с нормативными;
перечислить номера работ входящих в критический путь, выбрать 3-4 проблемных
работы ( затратные по бюджету , времени выполнения, и т. д., привести их
наименование).

77.

Представление календарного плана проекта в форме диаграммы Ганта
6
7
6
6
5
5
4
4
3
3
2
2
1
1
1
2
3
4
5
6
7
9
11
13 14
16
18

78. Выводы.

Представить отчеты по загрузке трудовых ресурсов,
бюджету проекта;
Провести анализ: использования трудовых ресурсов,
сравнить нормативные и фактические трудозатраты
выполнения работ и бюджет проекта.
Перечислить работы входящих в критический путь,
выбрать и обосновать 3-4 наиболее проблемных
работы затратные по бюджету , времени выполнения,
и т. д.
При подготовке отчета делать скриншоты
результатов и оформлять текст отчета в MS
Word,

79. Определение критического пути

80.

Формальное представление проекта
в виде сетевой модели на «языке работ»
2
12
1
4
6
3
6
4
5
1
3
10
7
2

81.

Алгоритм определения критического пути
Шаг 1
для каждой работы , начиная с начальной, вычисляются
ро рн
ранние даты начала и окончания t рн
=
0,
t
i
i =ti +ti , i= 1,n.
Шаг 2
для каждой работы , начиная с последней, определяются
поздние даты окончания и начала t по =T, t по =tпо − t , i= п,1.
i
i− 1
i
i
Шаг 3
для всех работ проекта вычисляется
полный резерв времени Rпi = tiпо− tiро , i= 1,n.
Шаг 4
определяется критический путь проекта - совокупность
взаимосвязанных работ, которые имеют нулевой полный резерв
времени t рн = tпн , t ро = t по
{i
i
i
i
}

82.

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

83.

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

84.

Полный резерв времени
Максимально допустимое время, на которое можно
отложить момент окончания выполнения работы
(отложить время ее начала), при этом общая
длительность выполнения проекта остается
неизменной.
Величина полного резерва времени вычисляется как
разность между поздним и ранним временем
начала выполнения работы.

85.

86.

Пример расчета характеристик сетевой модели
№
работы
Длительность
работы
Ранние сроки
Поздние сроки
Начала
окончания
начала
окончания
Полный
резерв
времени
1
4
0
4
0
4
0
2
12
4
16
4
16
0
3
10
4
14
6
16
2
4
3
4
7
7
10
3
5
1
4
5
9
10
5
6
6
7
13
10
16
3
7
2
16
18
16
18
0
Расчеты проводились при взаимосвязи «финиш — старт» и времени задержки равной нулю.
Критический путь: работы: 1, 2 , 7
Длина критического пути - продолжительность реализации проекта - 18 единиц.

87. Контрольная работа

88. Постановка задачи – 10 баллов

IT-компания в рамках реализации
проекта планирует разработать три
модуля .
Заданы : структура работ , перечень
специалистов, привлекаемых к
выполнению работ, время выполнения
работ.
Требуется рассчитать календарный план
выполнения работ , выделить работы
критического пути.

89.

Исходные данные
Последовательность выполнения работ
Задания
Модуль
Модуль1
Модуль 2
Модуль 3
Требования --бизнесаналитик
z1
Программирова
ние программисты
z2, z3
Тестирование -тестировщик
z4
i1 , z1
i1 , z 2
i1 , z 4
i2 , z1
i2 , z2
i2 , z3
i3 , z1
i3 , z3
i3 , z 4

90. Контрольное задание

1. Описать модель реализации проекта в виде
смешанного графа выполнения работ.
2. Построить на основе правила предпочтения
ориентированный граф выполнения работ проекта.
3. Провести расчет календарного плана выполнения
проекта , результаты представить в виде таблицы
4. Определить работы лежащие на критическом
пути.

91.

Процедура построения смешенного графа
Каждая работа представляется как точка (вершина графа) на
плоскости и соединяется с другой вершиной связью типа «дуга» или
«ребро» .
Две вершины следует соединить связью типа «дуга» если между ними
существуют технологическая связь между предыдущей и последующей
работами.
Две вершины следует соединить связью типа «ребро» если между ними
существуют ресурсная связь, работы используют однотипный ресурс
(выполняются одним и тем же специалистом).
Смешанный граф
G (X ,U ,U )
множество ребер и дуг.
, где X — множество работ Ū, и U , —

92.

Формальное представление структуры работ
Работа как точка на плоскости представлена в виде следующего кортежа:
н
к
i, z , d (i, z ), t (i, z ), t (i, z ) .
Технологическая взаимосвязь - последующая работа начинается после
полного завершения всех предшествующих ей работ.
Если i 1≠ i 2 и z z , - работы
1
2
связью типа «дуга».
(i 1 ,z1 ) и (i 2 ,z2 )
следует соединить
Ресурсная взаимосвязь - работы выполняются одним специалистом.
Если i1 i2 и z1 z2
связью типа «ребро».
Смешанный граф
- работы
G=( X,U ,U )
(i 1 ,z1 ) и (i 2 ,z1)
следует соединить
, X — множество работ Ū, и U , —
множество взаимосвязей между работами.

93.

Смешанный граф
Н
(i1 , z1 )
(i1 , z2 )
(i1 , z4 )
(i2 , z1 )
(i2 , z2 )
(i2 , z3 )
(i3 , z1 )
(i3 , z3 )
(i3 , z4 )
К
Задача определения календарного плана состоит в
формировании из графа G ( X , U , U ) ориентированного графа ,
путем замены по правилу предпочтения ребер на G ( X , U )
направленные дуги. определении
времен начала и
окончания выполнения всех работ.

94.

Функция предпочтения –аналититчское выражение определяющее правило
выбора из исходного множества очередной работы
Правило - SIO
«Кратчайшей операции»
первой выбирается работа с наименьшей длительностью выполнения.
Правило - FIFO
«первым пришел — первый обслуживается»
первой выбирается работа с наименьшей резервом времени.
Правило - LIFO
«последним пришел — первым обслуживается»
первой выбирается работа с наибольшим резервом времени.

95. Функция предпочтения –аналитическое выражение определяющее правило выбора из исходного множества очередного элемента

Условие
Правило
1. Выбор работы с минимальными трудозатратами
1. Кратчайшей операции – SIO-1
2. Выбор работы с максимальными трудозатратами
2. Длинной операции – SIO-2
3. Выбор работы с максимальным текущим временем 3. Наибольшего оставшегося времени
завершения проекта
завершения проекта – LRT -1
4. Выбор работы с минимальным текущим временем
завершения проекта
4. Наименьшего оставшегося времени
5. Выбор работы с минимальным временем
окончания предшествующей работы
5. Первым пришел – первым
6. Выбор работы с максимальным временем
окончания предшествующей работы
6. Последним пришел – первым
7. Выбор работы с максимальным риском нарушения
нормативных сроков
7. Работы с максимальным риском
выбора первой
завершения проекта – LRT-2
обслуживается – FIFO
обслуживается – LIFO
F i, z max F i, z
'

96. Алгоритм построения ориентированного графа

1 Выделим множество вершин ( работ) , в которые не входит ни
одна дуга: Определим это множество как множество ожидаемых
работ.
2 Если множество ожидаемых работ пусто , то переход к шагу 7.
3 По правилу предпочтения P(x) выберем из множества
ожидаемых работ работу c min или max P(x) .
4 Определим множество вершин (работ) смежных с данной
вершиной и связанных с ней технологической зависимостью.
5 Заменим все ребра, соединяющие данной вершиной со
смежными , на исходящие из нее дуги. Удалим работу из
множества ожидаемых работ. Переход к шагу 3.
6 Конец

97.

Ориентированный граф G
Н
(i1 , z1 )
(i1 , z2 )
(i1 , z4 )
(i2 , z1 )
(i2 , z2 )
(i2 , z3 )
(i3 , z1 )
(i3 , z3 )
(i3 , z4 )
К

98. Определение критического пути

99.

Алгоритм определения критического пути
Шаг 1
для каждой работы , начиная с начальной, вычисляются
ро рн
ранние даты начала и окончания t рн
=
0,
t
i
i =ti +ti , i= 1,n.
Шаг 2
для каждой работы , начиная с последней, определяются
поздние даты окончания и начала t по =T, t по =tпо − t , i= п,1.
i
i− 1
i
i
Шаг 3
для всех работ проекта вычисляется
полный резерв времени Rпi = tiпо− tiро , i= 1,n.
Шаг 4
определяется критический путь проекта - совокупность
взаимосвязанных работ, которые имеют нулевой полный резерв
времени t рн = tпн , t ро = t по
{i
i
i
i
}

100.

Формальное представление проекта
в виде сетевой модели на «языке работ»
2
12
1
4
6
3
6
4
5
1
3
10
7
2

101.

Пример расчета характеристик сетевой модели
№
работы
Длительность
работы
Ранние сроки
Поздние сроки
Начала
окончания
начала
окончания
Полный
резерв
времени
1
4
0
4
0
4
0
2
12
4
16
4
16
0
3
10
4
14
6
16
2
4
3
4
7
7
10
3
5
1
4
5
9
10
5
6
6
7
13
10
16
3
7
2
16
18
16
18
0
Расчеты проводились при взаимосвязи «финиш — старт» и времени задержки равной нулю.
Критический путь: работы: 1, 2 , 7
Длина критического пути - продолжительность реализации проекта - 18 единиц.