- •Вопросы для экзамена по курсу “Проектирование асоиу”/ 12/2006
- •Общая характеристика процесса проектирования асоиу. Цели и этапы разработки консалтинговых проектов
- •Разработка системного проекта на основе стандарта iso 12207. Основные процессы жизненного цикла программного обеспечения асоиу.
- •Модели жизненного цикла программного обеспечения асоиу. Подход rad.
- •1. Каскадная модель
- •2. Спиральная модель
- •3. Методология rad
- •Основные принципы методологии rad
- •Структурный подход к проектированию информационной системы. Функциональная модель асоиу. Количественный анализ диаграмм idef0 и dfd.
- •Объектно-ориентированный подход к анализу и проектированию информационной системы. Унифицированный язык моделирования uml.
- •Моделирование бизнес-процессов спецификация требований на основе структурного подхода.
- •Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика rup.
- •Разработка модели защиты данных в асоиу.
- •Разработка пользовательского интерфейса.
- •Проектирование распределенной обработки данных.
- •Анализ и оценка производительности асоиу.
- •Управление проектом асоиу
- •Проектная документация асоиу. Требования госТов к документации, содержание документации.
- •Инструментальные средства проектирования асоиу.
- •Типизация проектных решений асоиу. Использование коробочных продуктов и адаптируемых интегрированных систем.
- •Самостоятельная разработка
- •Заказные системы
- •Тиражируемые (коробочные) продукты
- •Адаптируемые интегрированные системы
- •Адаптируемые интегрированные системы как платформа современных комплексных систем автоматизации
- •Графические средства представления проектных решений асоиу (idef, dfd, uml, erd и т.Д.)
- •Распределенная обработка данных.
- •Системное проектирование Программных систем на основе стандартизации.
- •Стандартизированные показатели качества сложных программных систем
- •Понятие и виды case-средств
- •Стандарты для информационных систем управления mrp, erp, csrp, crm
- •Аспекты внедрения erp-систем. Стратегии и типы производства
- •1 Производство на склад
- •2 Сборка под заказ.
- •3 Производство под заказ
- •4 Разработка под заказ
- •Стратегии производства и период поставки
- •Стратегии производства и методы планирования
- •Выбор типа управления производством
- •Эффективность внедрения корпоративной информационной системы. Традиционные финансовые методы
- •Эффективность внедрения корпоративной информационной системы.Качественные методы
- •Эффективность внедрения корпоративной информационной системы. Вероятностные методы
- •Характеристика рынка программного обеспечения по автоматизации деятельности организации. Состояние рынка программного обеспечения
- •Характеристика рынка программного обеспечения по автоматизации деятельности организации. Основные участники рынка информационных и телекоммуникационных технологий
- •Характеристика рынка программного обеспечения по автоматизации деятельности организации. Критерии выбора корпоративной информационной системы
- •Основные подходы внедрения кис
- •1. Эталонный процесс внедрения кис
- •Стратегии внедрения кис на примере “Баан”
- •Стратегии внедрения кис на примере корпорации “Парус”
-
Модели жизненного цикла программного обеспечения асоиу. Подход rad.
Модель жизненного цикла - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее распространение получили каскадная, а затем спиральная модели.
Рассмотрим каскадную и спиральную модели подробнее:
1. Каскадная модель
Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. [4]
Каскадная модель разбивает процесс ЖЦ на пять этапов, выполняемых последовательно, один за другим:
Рисунок 5. Каскадная схема разработки ПО
Недостатки:
-
часто возникает потребность в возврате к предыдущим этапам для уточнения или пересмотра ранее принятых решений. В результате процесс принимает вид “модели с промежуточным контролем”
Рисунок 6. Каскадная схема с промежуточным контролем
-
существенное запаздывание с получением результатов,
-
требования к ИС "заморожены" в виде технического задания на все время ее создания, и, в случае неточного изложения требований или их изменения за время создания ПО, модель автоматизируемого объекта устаревает к моменту реализации.
2. Спиральная модель
Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Делает упор на начальные этапы ЖЦ - анализ и проектирование. Реализуемость технических решений проверяется на этих этапах путем создания прототипов.
Рисунок 7. Спиральная модель жизненного цикла ПО
Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется качество и планируются работы следующего витка.
Главная задача при работе по спиральной модели - возможно быстрее показать пользователю работоспособный продукт, чтобы активизировать процесс уточнения и дополнения требований.
Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора):
“Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта.
Спиральная модель обладает рядом преимуществ:
-
Модель уделяет специальное внимание раннему анализу возможностей повторного использования. Это обеспечивается, в первую очередь, в процессе идентификации и оценки альтернатив.
-
Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта. Главные источники изменений заключены в целях, для достижения которых создается продукт. Подход, предусматривающий скрытие информации о деталях на определенном уровне дизайна, позволяет рассматривать различные архитектурные альтернативы так, как если бы мы говорили о единственном проектном решении, что уменьшает риск невозможности согласования функционала продукта и изменяющихся целей (требований).
-
Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта. Эти механизмы строятся на основе идентификации всех типов целей (требований) и ограничений на всех “циклах” спирали разработки. Например, ограничения по безопасности могут рассматриваться как риски на этапе специфицирования требований.
-
Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.
-
Модель позволяет контролировать источники проектных работ и соответствующих затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо затратить на анализ требований, планирование, конфигурационное управление, обеспечение качества, тестирование, формальную верификацию и т.д. Модель, ориентированная на риски, позволяет в контексте конкретного проекта решить задачу приложения адекватного уровня усилий, определяемого уровнем рисков, связанных с недостаточным выполнением тех или иных работ.
-
Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего. Этот аспект позволяет избежать часто встречающегося отношения к поддержке и сопровождению как ко второсортной” деятельности. Такой подход предупреждает большого количество проблем, возникающих в результате одинакового уделения внимания как обычному сопровождению, так и критичным вопросам, связанным с расширением функциональности продукта, всегда ассоциированным с повышенными рисками.
-
Модель позволяет решать интегрированный задачи системной разработки, охватывающей и программную и аппаратную составляющие создаваемого продукта. Подход, основанный на управлении рисками и возможности своевременного отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) сокращает расходы и одинаково применим и к аппаратной части, и к программному обеспечению.
Рисунок 8. Оригинальная спиральная модель жизненного цикла разработки по Боэму
Недостатки:
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла.
Переход с этапа на этап осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.