надо. Методические указания к выполнению лабораторных работ по курсу «. Методические указания к выполнению лабораторных работ по курсу инструментальные средства информационных систем Для студентов бакалавриата
 Скачать 1.81 Mb.
|
|
Анализ рисков При анализе для каждого определенного риска подсчитывается вероятность его проявления и ущерб, который он может нанести. Не существует простых методов выполнения анализа рисков — в значи- тельной мере он основан на мнении и опыте менеджера. Можно при- вести следующую шкалу вероятностей рисков и их последствий. 1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%. 2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный. Результаты анализа рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного ущерба. В табл. 6 приведен упорядоченный список рисков, описанных в табл. 5.5; там же указаны вероятности этих рисков. Здесь вероятности рис- ков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, техноло- гии создания ПО, команде разработчиков и о самой организации. Таблица 5.6 - Список рисков после проведения их анализа Риск Вероятность Степень ущерба Финансовые затруднения в орга- низации привели к уменьшению бюджета проекта Низкая Катастрофическая Невозможно подобрать работни- ков с требующимся профессио- нальным уровнем Высокая Катастрофическая Ведущий разработчик заболел в самое критическое время Средняя Серьезная Программные компоненты, ис- Средняя Серьезная Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко пользуемые повторно, имеют дефекты, ограничивающие их функциональные возможности Изменения требований приводят к значительным повторным ра- ботам по проектированию систе- мы Средняя Серьезная В организации, выполняющей разработку ПО, произошла реор- ганизация, в результате чего из- менились приоритеты в управле- нии проектом Высокая Серьезная База данных, которая использу- ется в программной системе, не обеспечивает обработку ожидае- мого объема транзакций Средняя Серьезная Недооценки времени выполне- ния проекта Высокая Серьезная CASE-средства невозможно ин- тегрировать с другими средства- ми поддержки проекта Высокая Терпимая Первоначальная нечеткая фор- мулировка пользовательских требований привела к значитель- ным изменениям системных тре- бований, проявившихся на позд- них стадиях разработки проекта Средняя Терпимая Невозможно организовать необ- ходимое обучение персонала Средняя Терпимая Скорость выявления дефектов в системе ниже ранее спланиро- ванной Средняя Терпимая Размер системы значительно превышает первоначально рас- считанный Высокая Терпимая Программный код, генерируе- мый CASE-средствами, неэффек- тивен Средняя Незначительная Конечно, как вероятность рисков, так и возможный ущерб от них должны пересматриваться при поступлении дополнительной ин- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко формации об этих рисках и по мере реализации мероприятий по управлению ими. Поэтому подобные таблицы рисков должны пе- ределываться на каждой итерации процесса управления рисками. После проведения анализа рисков определяются наиболее зна- чимые риски, которые затем отслеживаются на протяжении всего сро- ка выполнения проекта. Определение этих значимых рисков зависит от их вероятностей и возможного ущерба. В общем случае всегда от- слеживаются риски с катастрофическими последствиями, а также рис- ки с серьезным ущербом, значение вероятности которых выше сред- него. В некоторых статьях рекомендуется определить и отслеживать "10 верхних" рисков, но это не всегда обоснованная рекомендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а может — пятна- дцать. Но, конечно, количество рисков, по которым проводится мони- торинг, должно быть обозримым. Большое количество отслеживаемых рисков потребует огромного количества собираемой информации. Из списка рисков, представленных в табл. 6, для мониторинга следует отобрать те риски, которые могут привести к катастрофическим и серьезным последствиям для вашего проекта. Планирование рисков Планирование заключается в определении стратегии управле- ния каждым значимым риском, отобранным для мониторинга после анализа рисков. Здесь также не существует общепринятых подходов для разработки таких стратегий — многое основывается на "чутье" и опыте менеджера проекта. В табл. 5.7 показаны возможные стратегии управления основными рисками, приведенными в табл. 5.6. Таблица 5.7 - Стратегии управления рисками Риск Стратегия Финансовые проблемы организации Подготовить краткий документ для руково- дства организации, показывающий важ- ность данного проекта для достижения фи- нансовых целей организации Проблемы неквалифи- цированного персонала Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы Болезни персонала Реорганизовать работу команды разработ- чиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко знать и понимать задачи, выполняемые другими сотрудниками Дефектные системные компоненты Заменить потенциально дефектные систем- ные компоненты покупными компонента- ми, гарантирующими качество работы Изменения требований Попытаться определить требования, наибо- лее вероятно подверженные изменениям; в структуре системы не отображать деталь- ную информацию Реорганизация компа- нии-разработчика Подготовить краткий документ для руково- дства компании, показывающий важность данного проекта для достижения финансо- вых целей компании Недостаточная произ- водительность базы данных Рассмотреть возможность покупки более производительной базы данных Недооценки времени выполнения проекта Рассмотреть вопрос о покупке системных компонентов, исследовать возможность использования генератора программного кода Существует три категории стратегий управления рисками. 1. Стратегии предотвращения рисков. Согласно этим стратеги- ям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия ис- ключения потенциально дефектных компонентов, описанная в табл. 7. 2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчи- ков (см. табл. 7). 3. Планирование "аварийных" ситуаций. Согласно этим страте- гиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 7 это стратегия поведения при возникновении финансовых про- блем у организации-разработчика. Мониторинг рисков Мониторинг рисков заключается в регулярном пересчете веро- ятностей рисков и ущерба, который они могут нанести. Для этого не- обходимо постоянно отслеживать факторы, которые влияют на веро- ятность рисков и возможный ущерб. Эти факторы зависят от типов Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко риска. В табл. 5.8 приведены признаки, которые помогают определить тип риска. Таблица 5.8 - Признаки рисков Тип риска Признаки Технологические риски Задержки в поставке оборудования или про- граммных средств поддержки процесса созда- ния ПО, многочисленные документированные технологические проблемы Риски, связанные с персоналом Низкое моральное состояние персонала, натя- нутые отношения между членами команды разработчиков, низкое качество выполненной работы Организационные риски Разговоры среди персонала о пассивности и недостаточной компетентности высшего ру- ководства организации Инструментальные риски Нежелание разработчиков использовать про- граммные средства поддержки, неодобри- тельные отзывы о CASE-средствах, запросы на более мощные инструментальные средства Риски, связанные с системными требо- ваниями Необходимость пересмотра многих систем- ных требований, недовольство заказчика ПО Риски оценивания Изменения графика работ, многочисленные отчеты о нарушении графика работ Мониторинг рисков должен быть непрерывным процессом, от- слеживающим ход выполнения мероприятий по управлению рисками, при этом каждый основной риск должен рассматриваться отдельно. Порядок выполнения работы 1. Изучить предлагаемый теоретический материал. 2. Построить временную и сетевую диаграммы для выбранного проекта. 3. Построить диаграмму распределения участников группы по этапам. 4. Построить список возможных рисков с указанием названия риска, его описание и типа. 5. Провести анализ рисков. 6. Описать стратегию планирования рисков. 7. Построить отчѐт, включающий все полученные диаграммы и описание стратегии планирования рисков. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Содержание отчета В отчете следует указать: 1. Цель работы 2. Введение 3. Программно-аппаратные средства, используемые при выпол- нении работы. 4. Основную часть (описание самой работы), выполненную со- гласно требованиям к результатам выполнения лабораторного практикума. 5. Заключение (выводы) 6. Список используемой литературы Литература: 1. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. – С-П.: Издательство «Питер», 2003. – 432 с. 2. Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом ―Вильямс‖, 2002. – 624 с. 3. Константайн Л., Локвуд Л. Разработка программного обеспе- чения. – СПб.:Питер, 2004. – 592 с. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Приложение А ТЕХНИЧЕСКОЕ ЗАДАНИЕ на разработку ИС «Система» Общие сведения 1.1. Наименование системы Аналитическая информационная система «Система». 2.1. Назначение и цели создания системы Система «Система» предназначена для информационного обеспечения процессов, которые происходят на кафедре связанных с учебно-методической, научной, общественной, организационно- методической и воспитательной работой. Характеристика объектов информатизации 3.1. Краткое описание работы кафедры К основным направлениям работы кафедры относятся: · Учебно-методическая работа; · Научная работа; · Организационно-методическая работа; · Работа со студентами заочниками; · Общественная работа; · Воспитательная работа. … 3.2. Описание объектов информатизации К основным объектам информатизации системы относятся: Кафедра · Наименование кафедры · Факультет, к которому относится кафедра · Веб-сайт кафедры · Заведующий кафедрой … 3.2.1. Учебно-методическая работа План учебно-методической работы кафедры · Учебный год · Заведующий кафедрой, составивший план · Кафедра Тема для учебно-методической работы · Названия работ · Сроки исполнения · Ответственные за выполнение темы … Требования к информационной системе 4.1. Базовые принципы разработки подсистем Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко При проектировании и разработке подсистем должны исполь- зоваться следующие базовые принципы: · Исключение дублирования ввода информации и повы- шение ее достоверности, за счет отождествления ранее введенной ин- формации; … Система должна удовлетворять следующим требованиям: · Пользовательский интерфейс системы должен быть сформирован в соответствии с навыками и профилем пользователей; … Система должна содержать: · Средства поиска информации; … Выбор прикладного программного обеспечения системы дол- жен удовлетворять следующим критериям: · Интеграция с базами данных, поддерживающих Web- технологии; … 4.2. Требования к архитектуре системы. Архитектура системы «Система» является трехзвенной. В ка- честве клиентского приложения выступает стандартный веб-браузер. … 4.3. Требования к способам и средствам связи для инфор- мационного обмена между компонентами (модулями) Системы Подсистемы должны взаимодействовать в пределах единой компьютерной сети (Интернет/Интранет), в которой происходит весь обмен информацией. … 4.4. Требования к характеристикам взаимосвязей системы со смежными системами Смежными системами для информационной системы «Систе- ма» являются: «Система2», … 4.5. Требования к режимам функционирования подсисте- мы Разрабатываемая система должна функционировать 24 часа в сутки, 365 дней в году… … 4.6. Требования к пользователям Система подразумевает четыре типа пользователя: Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко · Сотрудник – имеет доступ к просмотру общих данных по своей кафедре, а также к просмотру и редактированию личных данных, имеет возможность ; … 4.7. Требования по эргономике и технической эстетике Основными требованиями по эргономике и технической эсте- тике является адекватность времени реакции модулей системы на сложность запроса пользователя к базам данных: · При выполнении стандартных запросов пользователь дол- жен работать с системой в реальном режиме времени; … 4.8. Требования к численности и квалификации персонала системы и режиму его работы. Квалификация персонала, порядок его подготовки и контроль знаний и навыков. … 4.9. Требования к защите информации от несанкциониро- ванного доступа. Разрабатываемая система должна обладать специализирован- ной подсистемой разграничения доступа к информационным ресур- сам, функционирующей на основе системы пользователей и пользова- тельских групп. … 4.10. Требования к обмену данными · Обмен данными должен происходить по сети в среде Intranet/Internet с поддержкой протокола TCP/IP; … 4.11. Требования к внешней среде системы Сервер баз данных или сервер приложений должен обеспечи- вать: … 4.12. Требования к хранению данных База данных «Система» должна содержать следующие данные: · Данные о планировании учебно-методической работы; … 4.13. Требования к отдельным подсистемам 4.13.1. Учебно-методическая работа Функции заведующего кафедрой · Создание плана учебно-методической работы на учеб- ный семестр, заполнения, редактирования и удаления данных плана; … Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Состав и содержание работ по созданию Системы Разработать модель БД, позволяющую хранить и обрабаты- вать все необходимые… … Приемо-сдаточные испытания Системы После завершения всех работ по разработке компонентов, на- стройке подсистем и … Внесение корректировок в программный продукт, связан- ных с ошибками в Системе Все ошибки, которые будут выявлены в работе Системы в те- чении 12 месяцев … Тестирование Перед сдачей Модулей и Компонент Заказчику для выявления возможных сбоев в работе … Порядок контроля и приемки Системы Для проверки выполнения заданных функций Системы, опре- деления и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик Системы, выявления и устранения недостатков в действиях Системы и в разработанной документации, поэтапного контроля над ходом разработки должны быть проведены следующие виды испытаний: · Предварительные; … Процедуры тестирования и контроля качества При проведении испытаний должны использоваться следую- щие типы процедур тестирования и контроля качества: · функциональное тестирование - тестирование ПО на со- ответствие функциональным спецификациям; … Общие требования к приемке работ Сроки и место приемки, порядок приемки работ определяются в соответствии с настоящим ТЗ. … Требования к документированию 12.1. Требования к проектной документации Состав и комплектность проектной документации должна со- ответствовать требованиям ГОСТ 34.201-89. Перечень документации по созданию системы включает: Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко · Описание информационного обеспечения системы (П5); |