Создание сайта для МБОУ ДОД «Детско-юношеская спортивная школа № 3» г. Прокопьевска

 

 

 

 

 

 

 

 

 

 

 

5. Управление требованиями

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

Цель управления требованиями состоит в том, чтобы гарантировать что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц. Требование определяется как «условие или особенность, которой должна удовлетворять система».

Требованием может быть:

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

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

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

 

1. Пирамида требований

 

Проект имеет ограничения – это «сроки», «стоимость» и «содержание работ» проекта. Эти ограничения обычно называют тройственными и изображают в форме треугольника.

Рисунок 1- Пирамида требований

 

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

• Управление временем (необходимо уложиться в срок);

• Управление стоимостью (мы не должны превысить бюджет);

• Управление содержанием (нам нужно уточнить желания заказчика и правильно их реализовать);

• Управление качеством;

• Управление рисками;

• Управление закупками (если мы используем субподрядчиков);

• Управление персоналом;

• Управление коммуникациями;

• Управление интеграцией.

В зависимости от формата, источника и общих характеристик, требования могут быть разделены на различные типы. Типы требований, наиболее часто использующихся в проектах: Потребности заинтересованного лица: требование от заинтересованного лица. Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика. Сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий. Дополнительное требование: другое требование (обычно нефункциональное), которое не может быть охвачено сценариями использования. Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов. Сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования.    Сценарии использования Каждый сценарий использования сосредотачивается на описании того, как достигнуть цели или задачи. Для большинства программных проектов это означает, что потребуется множество сценариев использования, чтобы определить необходимый набор свойств новой системы. Степень формальности программного проекта и его стадии будет влиять на необходимый уровень детализации, для каждого сценария использования. Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования. Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Сценарии использования рассматривают систему как «черный ящик», и взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. Различают два вида сценариев: Деловой сценарий использования не затрагивает технологий, а рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми людьми, или системами, внешними к бизнесу для достижения своих целей. Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Сценарий использования должен: Не затрагивать деталей реализации. Иметь достаточный уровень детализации. Не описывать пользовательские интерфейсы и экраны. Это делается во время дизайна пользовательского интерфейса.

 

Рисунок 2. Главная страница сайта

 

Рисунок 3. Размещение и просмотр основных документов

 

Рисунок 4. Новостная лента, отражающая текущую деятельность учреждения

 

6. Команда проекта

 

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

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

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

 

 

 

 

 

 

 

Команда проекта
Проект	Создание сайта для МБОУ ДОД «ДЮСШ № 3» с 01.06.2014 г. по 01.09.2014 г.
РМ	Позднякова Ольга Александровна
ID	Имя	Роль в проекте	Должность	Отдел / департамент	Непосредственный начальник	Контактная информация	Предпочита-емый вид коммуника-ций
st-1	Вострелин Р.В.	Спонсор Заказчик	Начальник УФКиС	Административное управление	Глава города Прокопьевска	61-11-22	телефон
st-2	Черняк Н.И.	Пользователь	Директор ДЮСШ	Административное управление	Начальник УФКиС	61-22-33	телефон
st-3	Позднякова О.А.	Исполнитель	Менеджер	Программное обеспечение	Директор ДЮСШ	62-33-44	телефон
st-4	Макарова Н.В.	Пользователь	Методист ДЮСШ	Вспомогательный персонал	Директор ДЮСШ	61-33-44	телефон
st-5	Тараба М.В.	Пользователь	Заместитель директора по УВР	Административное управление	Директор ДЮСШ	61-33-44	телефон
st-6	Гавриленко О.М.	Пользователь	Заместитель директора по СМР	Административное управление	Директор ДЮСШ	61-33-44	телефон

 

 

 

 

 

 

 

 

 

7. Определение содержания, сроков и стоимости проекта

 

1. . Формирование иерархической структуры работ (work breakdown structure- WBS)

ИСР – ориентированная на результат поставки иерархическая декомпозиция работ, выполняемых командой проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. Ориентация на результат поставки включает как внутренние, так и внешние результаты поставки.

Разработка ИСР по сути является планированием содержания работ.

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

При создании ИСР необходима разумная глубина отражения в понятии «пакета работ».

Рисунок 5. «Пакет действий»

 

 

2. Определение перечня действий

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

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

 

Рисунок 6. Определение перечня действий

 

 

3. Определение последовательности действий

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

Рисунок 7. «Диаграмма Ганта»

 

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

Рисунок 8. «Сетевой график»

 

7.4. Определение ресурсов

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

Специализированное ПО Microsoft Project позволяет задавать список ресурсов для проекта и назначать один или несколько из них для каждого действия.

Рисунок 9. Исполнители

 

5. Определение продолжительности и стоимости

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

Главные рекомендации для оценки времени

Среди основных методов оценки времени иногда называют:

• Оценку одним человеком

• Оценку по аналогу

• Параметрическую оценку

• PERT

• Эвристическую оценку

• Анализ резервов

Мы использовали в своей курсовой работе метод PERT.

PERT (или «оценка по трем  точкам) – чрезвычайно полезный прием, позволяющий оценить продолжительность выполнения работ, комбинируя «оптимистичную», «пессимистичную» и «наиболее вероятную» оценки.  Целесообразно использовать PERT для тех работ, оценка которых затруднена и/или имеет высокий диапазон допущения. Этот метод оперирует тремя видами усредненных прогнозов – «пессимистичным», «оптимистичным» и «наиболее вероятным». Для этого нужно определить их (самостоятельно или с помощью экспертов) для каждой работы «достоверную» продолжительность которой вы собираетесь определить, а затем подставить в приведенные ниже формулы.

Согласно PERT предполагаемая длительность (или EAD) составит:

EAD = (P + 4M +O) / 6

где P – «пессимистичная оценка» , O – «оптимистичная оценка», M – «наиболее вероятная оценка».

Р=90 дней

О=40 дней

М=65 дней

EAD =(90+4*65+40)/6=65

С помощью PERT можно дополнительно уточнить и сам диапазон допущения:

1. Возможное отклонение (SD) составит:

SD = (P-O) / 6

SD =(90-40)/6=8

2. Диапазон колебания (range) составит:

• Оптимистичный прогноз = EAD – SD=65-8=57

• Пессимистичный прогноз = EAD + SD=65+8=73

  Точность создаваемых сейчас оценок должна быть достаточно высокой с погрешностью от 5 до 25%, или меньше, в зависимости от характера проекта.

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

 

 

6. Оценка стоимости

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