Начало проекта

Перед планированием проекта следует:

• установить цели и проблемную область проекта;

• обсудить альтернативные решения;

• выявить технические и управленческие ограничения.

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

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

Анализ риска. Исследование области неопределенности, анализ ее влияние на проект. В результате принимается решение – выполнять проект или нет.

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

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

В результате повторного планирования:

• могут быть перераспределены ресурсы;

• могут быть реорганизованы задачи;

• могут быть пересмотрены выходные обязательства.

6. Планирование проектных задач.

Эффективность руководства программным проектом целиком определяется правильностью планирования работ, которые необходимы для его выполнения. План помогает предвидеть возможные проблемы разработки ПО и ввести защитные меры для их предупреждения и решения. План создается на начальном этапе проекта (в ходе основной деятельности «планирование) и рассматривается менеджерами и инженерами-разработчиками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот начальный план должен максимально подробно описывать все этапы работы проекта. Как показано на рис. 2.2, планирование является многошаговым итерационным процессом. Очень важно, чтобы план регулярно пересматривался — ведь по мере работы в проект непрерывно поступают новые сведения. Важными факторами, которые должны учитываться при разработке плана, являются контрактные обязательства фирмы, требования заказчика, бюджетные и временные ограничения. Их изменения должны оперативно отражаться в плане работ программного проекта. Планирование начинается с оценки предметной области программной системы, ее размера, трудозатрат и времени на разработку. Формируется команда исполнителей, распределяются их функции. При этом учитываются ограничения по времени, бюджету, наличию и возможностям сотрудников, материально-техническому обеспечению. Затем определяются этапы разработки, контрольные вехи проекта и перечень артефактов — результатов каждого этапа. Напомним, в состав артефактов входит документация, макеты, отчеты, листинги, модели, программный код версий продукта и т. д. Составляется начальный план-график (расписание) работ команды. Далее начинается итерационная часть планирования. Выполняется текущий этап проекта. Его ход отслеживается и контролируется. Выявляются расхождения между реальным и плановым ходом работ. Если зафиксированы внутренние проблемы или заказчик изменил/расширил список требований, возможен пересмотр первоначальных оценок проекта. Такой пересмотр может привести к модификации начального (или уже промежуточно- го) графика работ. Если изменения влияют на сроки завершения или стоимость проекта, с заказчиком согласовываются новые ограничения проекта. После этого продолжают проект — переходят к следующему этапу работы. Конечно, опытные менеджеры закладывают в график резервы на случай не- приятностей. Иными словами, в планах фиксируются пессимистические графики работ. Но, разумеется, невозможно построить план, учитывающий все реальные проблемы, поэтому и возникает необходимость периодической коррекции этого руководящего документа.

Эмпирический закон:

30% - анализ и проектирование

40% - реализация проекта

30% - откладка и тестирование

7. Размерно-ориентированные метрики.

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте.

Исходные данные для расчета этих метрик сводятся в таблицу (табл. 2.1).

Проект	Затраты, чел.-мес	Стоимость, тыс. $	KLOC, тыс. LOC	Прогр. док- ты, страниц	Ошибки	Люди
ааа01	24	168	12,1	365	29	3
bbb02	62	440	27,2	1224	86	5
ссс03	43	314	20,2	1050	64	6

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте aaa01 показывает: 12 100 строк программы были разработаны за 24 человеко-месяца и стоили $168 000. Кроме того, по проекту aaa01 было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект aaa01 три человека.

На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):

;

;

;

.

Достоинства размерно-ориентированных метрик:

1) широко распространены;

2) просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

1) зависимы от языка программирования;

2) требуют исходных данных, которые трудно получить на начальной стадии проекта;

3) Меньшее число строк кода проще поддерживать. Программа с меньшим количеством строк может быстрее работать. Мера не отражает реальную сложность решения.

8. Функционально-ориентированные метрики.

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

Здесь идёт ориентация не на количестве работы, которую сделал программист, а на тех функциях, которые он выполнил.

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

100 строк кода на С++

8 страниц документации – для редактора

Нарисованных изображений – для дизайнера

1 ф.т – небольшая утилита. Работа она 1-2 дня. Тот, кто не может справить с функциональной точкой, не может претендовать на полноценного члена команды

10 ф.т – небольшое приложение ( до месяца работы)

100 ф.т – это приложение (6 месяцев в команде, считается, что это предел для одиночки.

Американский программист пишет в год порядка 7,7 тыс. строк кода, выполняя при этом в среднем 63 функциональных точек. Европейский программист пишет 16,7 тысяч строчек кода, проходя при этом менее 30 функциональных точек. Основное отличие заключается в качестве сопровождаемости полученного кода и распределении обязанностей. Дело том, что программист не только разрабатывает программное обеспечение, но и сам должен его документировать, в европе для таких целей принято нанимать технических писателей. Вся зависит от того, как мы именно определим функциональную точку в рамках нашего проекта.

Достоинства функционально-ориентированных метрик:

1. Не зависят от языка программирования.

2. Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик:

1. Результаты основаны на субъективных данных

FP=UI*(0.65+0.01*E[F(i)])

1. UI - оценка сложности пользовательского интерфейса,

2. F(i) ("эф итое") – коэффициенты регулировки сложности, основанные на эмпирической оценке ряда системных параметров и принимающие целые значения в диапазоне от 0 до 5.

3. E[F(i) - сумма всех коэффициентов по i параметру.

9. Выполнение оценки проекта на основе LOC- и FP метрик.

Цель этой деятельности — сформировать предварительные оценки, которые позволят:

• предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;

• составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

• в качестве оценочных переменных, определяющих размер каждого элемента продукта;

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

Обсудим шаги процесса оценки.

• Шаг 1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально:

f₁, f₂,…,f_n.

• Шаг 2. Для каждой функции f_i, планировщик формирует лучшую LOC_лучшi (FР_лучшi), худшую LOC_худшi (FР_худшi) и вероятную оценку LOC_{вероятнi} (FР_{вероятнi}). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

• Шаг 3. Для каждой функции/ в соответствии с -распределением вычисляется ожидаемое значениеLOC- (или FP-) оценки:

LOC_ожi =(LOC_лучшi + LOC_худшi +4x LOC_{вероятнi} )/ 6.

• Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.

Используется один из трех подходов:

1) для всех функций принимается одна и та же метрика средней производительности ПРОИЗВ_ср, взятая из метрического базиса;

2) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ПРОИЗВ_i =ПРОИЗВ_срх(LOC_ср /LOC_ожi),

где LOC_cp — средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

3) для i-й функции настраиваемая величина производительности вычисляется по аналогу, взятому из метрического базиса:

ПРОИЗВ_i =ПРОИЗВ_анiх(LOC_анi /LOC_ожi).

Первый подход обеспечивает минимальную точность (при максимальной простоте вычислений), а третий подход — максимальную точность (при максимальной сложности вычислений).

• Шаг 5. Вычисляется общая оценка затрат на проект: для первого подхода

;

для второго и третьего подходов

.

• Шаг 6. Вычисляется общая оценка стоимости проекта: для первого и второго подходов

,

где УД_СТОИМОСТЬ_ср — метрика средней стоимости одной строки, взятая из метрического базиса.

для третьего подхода

где УД_СТОИМОСТЬ_анi — метрика стоимости одной строки аналога, взятая из метрического базиса. Пример применения данного процесса оценки приведем ниже.

10. Классические методы анализа.

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

Структурный анализ

Диаграммы потоков данных

Метод анализа Джексона

Методы анализа, ориентированные на структуры данных.

11. Структурный анализ.

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

12. Диаграммы потоков данных и их описание.

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

движении от входа к выходу системы. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем,

DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.

Диаграммы потоков данны (DFD - Data Flow Diagramm) строятся из следующих элементов:

Функция – функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»)

Имя

Функции

Поток данных - Объект, над которым выполняется действие.

Имя объекта

Хранилище данных - Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.

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

Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных.

Декомпозиция. В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий.

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

• хранилища данных – это электронные таблицы и базы данных,

• внешние сущности – клиенты или другие базы данных, в том числе, из других программ (интеграция и обмен данными),

• процессы – это выполняемые функции и модули в системе.

Базовые средства диаграммы не обеспечивают полного описания требований к

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

— потоки данных, и преобразователи— процессы. Для этих целей используются словарь требований (данных) и спецификации процессов. Словарь требований

(данных) содержит описания потоков данных и хранилищ данных.

Большинство

словарей

содержит следующую информацию.

1.

Имя (основное имя элемента данных, хранилища или внешнего объекта).

2.Прозвище (Alias) — другие имена того же объекта.

3.Где и как используется объект — список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память).

4.Описание содержания — запись для представления содержания.

5.Дополнительная информация — дополнительные сведения о

типах данных, допустимых значениях, ограничениях т.д.

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

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

13. Методы анализа, ориентированные на структуры данных.

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

Методы, ориентированные на структуры данных, обеспечивают:

1.Определение ключевых информационных объектов и

операций.

2.Определение иерархической структуры данных.

3.Компоновку структур данных из типовых конструкций — последовательности, выбора, повторения.

4.Последовательность шагов для превращения иерархической структуры данных в структуру программы.

Наиболее известны два метода: метод Варнье–Орра и метод Джексона.

В методе Варнье–Орра для представления структур применяют диаграммы Варнье. Для построения диаграмм Варнье используют три базовых элемента:

последовательность, выбор, повторение