Введение Глава 1: Почему в процессе разработки возникают риски Мини-проект выполнили:

Введение
Глава 1: Почему в процессе
разработки возникают риски
Мини-проект выполнили:
Козинов Евгений - лидер мини-проекта
Лялин Сергей – главный разработчик
Первая проблема:
Хотя всё выглядит просто и ясно, неизбежно
примешивается изрядная доля личного представления о
важности различных объектов на предприятии, следовательно
процесс проектирования не воспроизводим.
Вывод:
При любом самом изощрённом и теоретически
обоснованном методе проектирования нельзя игнорировать
управленческий опыт.
Вторая проблема:
В любом, достаточно крупном процессе разработки
программной системы присутствует элемент
случайности.
В результате:
Неопределённость может привести к тому, что процесс
разработки пойдёт «не туда», или серьёзно задержится во
времени из-за решения неотложных проблем, которые
появились «вдруг, откуда не возьмись».
Третья проблема:
Существует «человеческий фактор»:
•Неточность поставленной задачи.
•Возможность ошибок еще на начальном этапе
проектирования.
•Возможность ошибок при принятии ключевых
решений на всех этапах.
Результат:
Крах всего проекта в целом.
Возможное решение:
Построение «Прототипной модели», которая позволяет:
• Модель делает не существенным тот факт, что начальные
требования для программной системы были заданы не
точными.
• Позволяет оценить реализуемость программной системы или
некоторой её части.
• Снижает вероятность риска неправильного понимания
разработчиками требований к программному продукту на
начальных этапах проектирования.
• Снижает вероятность того, что придётся «сделать всё заново»
Пример
Для объектно-ориентированной системы главная
обязанность менеджера программного продукта –
управление как техническими, так и нетехническими
рисками.
Технический риск – решении таких проблем, как выбор
структуры наследования классов, обеспечивающий
наилучший компромисс между удобством и гибкостью
программного продукта.
Не технический риск – содержит в себе такие вопросы,
как контроль своевременности поставки программных
продуктов от третьих фирм или регулирование отношений
заказчика и разработчиков, что необходимо для выяснения
реальных требований к системе на стадии анализа.
Итого:
• Уделять внимание рискам жизненно необходимо для
программного проекта.
• Необходимо составлять «Прототипную модель» для
частичного сглаживания фактора неопределенности.
• Тема управления рисками актуальна не только при
разработке программного проекта, она возникает везде, где
есть неопределенности.
Вопросы?
Использованные материалы:
1. Гради Буч. Объектно-ориентированный анализ и
проектирование с примерами приложений на C++, 2-е
издание. М.: «Издательство Бином», СПб.: «Невский
диалект», 2001. – 560 с., ил.
2. http://www.sovnet.ru/pages/public/pm_risk.htm
3. http://www31.ipu.rssi.ru/0887.pdf
4. http://www.infosystem.ru/pj_managment/article/pj_risk_pj.html