5. Оборудование

ПЭВМ IBM PC, операционная система Windows, OOo Writer (MS Word).

6. Задание на работу

1. Изучить предлагаемый теоретический материал.

2. Составить подробное описание программного проекта.

3. На основании описания системы провести анализ осуществимости. В ходе анализа ответить на вопросы:

• Что произойдет с организацией, если система не будет введена в эксплуатацию?

• Какие текущие проблемы существуют в организации и как новая система поможет их решить?

• Каким образом система будет способствовать целям бизнеса?

• Требует ли разработка системы технологии, которая до этого не использовалась в организации?

Результатом анализа должно явиться заключение о возможности реализации проекта.

4. Распределить роли в группе (руководитель проекта-разработчик, системный аналитик-разработчик, тестер-разработчик).

5. Заполнить разделы плана:

• Введение

• Организация выполнения проекта

• Анализ рисков

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

7. Составить отчет о проделанной работе.

7. Контрольные вопросы

1. Приведите отличия процессов разработки ПО от процессов реализации прочих технических проектов.

2. Опишите основные этапы процесса управления разработкой ПО.

3. Какие можно выделить роли в группе по разработке ПО?

4. Какие основные разделы должны содержать планы по разработке ПО?

5. Приведите известные Вам требования к программным системам.

6. Как Вы понимаете термин «анализ осуществимости реализации проекта»?

7. Проведите анализ осуществимости реализации какого-либо программного проекта.

Практическое занятие № 2 Разработка концепции проекта

1. Цель занятия

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

2. Порядок выполнения работы

- ознакомится с теоретическими сведениями;

- выполнить задание;

- оформить отчет;

- ответить на контрольные вопросы, заданные преподавателем.

3. Оформление отчета

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

4. Теоретические сведения

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

1. Цели и результаты проекта

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

Целями проекта могут быть:

Изменения в компании. Например, повышение эффективности основной производственной деятельности.

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

Выполнение контрактов. Например, обеспечение разработки программного обеспечения по заказу.

Разрешение специфических проблем. Например, обеспечение доработки программного продукта в целях приведения его в соответствие с изменениями в законодательстве.

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

Цели должны определять:

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

Высокоуровневые требования. Краткое описание и, при необходимости, ключевые свойства и/или характеристики продукта/услуги.

2. Допущения и ограничения

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

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

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

Специфические технические требования. Например, разработка под заданную программно-аппаратную платформу.

Специфические требования к защите информации.

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

3. Ключевые участники и заинтересованные стороны

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

Спонсор проекта ― лицо или группа лиц, предоставляющая финансовые ресурсы для проекта в любом виде.

Заказчик проекта ― лицо или организация, которые будут использовать продукт, услугу или результат проекта. Следует учитывать, что заказчик и спонсор проекта не всегда совпадают.

Пользователи результатов проекта.

Куратор проекта ― представитель исполнителя, уполномоченный принимать решение о выделении ресурсов и изменениях в проекте.

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

Соисполнители проекта ― субподрядчики и поставщики.

4. Ресурсы проекта

Для оценки стоимости проекта требуется определить и оценить ресурсы, необходимые для его выполнения:

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

Бюджет проекта. План расходов и, при необходимости, предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта.

Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этими расходами. На фазе инициации проекта хорошей считается оценка трудозатрат с точностью от –50% до +100% .

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

Прежде чем определять численность и состав проектной команды, не-обходимо сделать оценку трудоемкости разработки ПС [чел/час].

5. Сроки проекта

Ф. Брукс приводит исключительно полезную, эмпирическую формулу оценки срока проекта по его трудоемкости. Формула была выведена Барри Боэмом (Barry Boehm) на основе анализа результатов 63-х проектов разработки ПС, в основном в аэрокосмической области. Согласно этой формуле для проекта, общая трудоемкость которого составляет [ч.× м.] (человеко-месяцев), можно утверждать, что:

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

Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.

Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за 3 4 расчетного оптимального графика вне зависимости от количества занятых в нем специалистов. Кроме сроков завершения проекта необходимо еще определить его этапы — контрольные точки (вехи), в которых будет происходить переоценка проекта на основе реально достигнутых показателей.

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

Для программного проекта контрольные точки должны соответствовать выпуску каждой промежуточной версии ПС, в которой будет реализована и протестирована определенная часть конечной функциональности программного продукта. В зависимости от сложности и масштаба проекта продолжительность одной итерации может составлять от 2 до 8 недель.

6. Риски проекта

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

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

7. Критерии приемки проекта

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

8. Обоснование полезности проекта

Этот раздел концепции должен содержать краткое технико-экономическое обоснование проекта:

Для кого предназначены результаты проекта.

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

Каким образом результаты проекта решают эти проблемы. Насколько значимо для клиента решение данных проблем (оценка экономического эффекта).

Какие преимущества в итоге из этого может извлечь компания-исполнитель проекта.

Приоритет проекта определяется на основе оценки трех показателей:

Финансовая ценность.

Стратегическая ценность.

Уровень рисков.