Фрагмент для ознакомления
2
Рис. 4. Шкала оценки близости риска
Идентификация рисков – деятельность по выявлению рисков, способных повлиять на проект, и документальное оформление их характеристик.
Таблица 1 – Идентификация рисков
Причина Условия Последствия Ущерб
Некачественно составленное ТЗ или его отсутствие со стороны заказчика Отсутствие определенного понятия, как должна выглядеть ИС Задержка начала разработки прикладного ПО. Большое количество переработок Дополнительные затраты сил и времени, в следствие чего, задержка сдачи проекта
Малое количество квалифицированных специалистов Код, алгоритм и архитектура низкого качества Большое количество ошибок. Большие затраты на исправление Дополнительные затраты сил и времени, в следствие чего, задержка сдачи проекта
Текучесть кадров Частая смена участников команды Низкая производительность из-за ввода новых участников в проект. Дополнительные затраты сил и времени, в следствие чего, задержка сдачи проекта
Вероятность Ранг риска
Воздействие 3 6 9 - высокий
2 4 6 - средний
1 2 3 - низкий
Рис. 5. Шкала вероятности риска проекта
2. Планирование реагирования на риски
Одним из методов будет принятие рисков.
Принятие риска. Стратегия означает решение команды не уклоняться от риска. При пассивном принятии команда ничего не предпринимает в отношении риска и в случае его возникновения разрабатывает способ его обхода или исправления последствий. При активном принятии план действий разрабатывается до того, как риск может произойти, и называется планом действий в непредвиденных обстоятельствах.
Заключение трудового договора, которые будет содержать определенные обязанности за каждым членом команды.
3. Критерии приемки
Работа будет принята заказчиком, только при, условие, то что данный проект будет сделан по определенному ТЗ, а так, же точно в срок, обговоренный на этапе процесса заказа, то есть в течении 2-4 недель.
При тестирование данной ИС заказчик должен увидеть точную модель, обговоренную на первом этапе, а так же, работающую систему.
4. Обоснование целесообразности проекта
Методология создания информационных систем заключается в организации процесса построения информационной системы (ИС) и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки.
К проектированию информационной системы непосредственное отношение имеют два направления деятельности:
1) собственно проектирование ИС конкретных организаций на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки;
2) проектирование упомянутых компонентов ИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.
Для обозначения первого направления используется термин «системная интеграция». В этом случае разработчик ИС должен быть специалистом в
Фрагмент для ознакомления
3
Список используемой литературы
1. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем [Текст]: учебник / А.М.Вендров. – М.: Финансы и статистика,2003. – 352с.
2. Грекул, В.И. Проектирование информационных систем [Текст]: Курс лекций. Учеб. пособие для вузов / В.И. Грекул. – М.: ИНТУИТ.ru (Интернет-Ун-т Информ. Технологий),2005. – 304 с.
3. Грекул, В.И. Управление внедрением информационных систем [Текст]: учебник / Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. – ИНТУИТ; БИНОМ. Лаборатория знаний, 2008. – 224 с.
4. Кознов, Д.В. Введение в программную инженерию. – М.: Национальный Открытый Университет «ИНТУИТ», 2009. – 390 с.
5. Нестеров, С.А. Анализ и управление рисками в информационных системах на базе операционных систем Microsoft – М.: Национальный Открытый Университет «ИНТУИТ», 2009. – 375 с.
6. Смирнова, Г.Н. Проектирование экономических информационных систем [Текст]: учеб.для вузов / Г.Н.Смирнова, А.А. Сорокин, Ю.Ф. Тельнов. – М.: Финансы и статистика,2005. – 512 с.