![](/user_photo/2706_HbeT2.jpg)
- •Двусторонние шпоры по файзу
- •Печатай прямо этот файл
- •1. Общая характеристика процесса проектирования асоиу. Цели и этапы разработки консалтинговых проектов
- •2. Разработка системного проекта на основе стандарта iso 12207. Основные процессы жизненного цикла программного обеспечения асоиу.
- •3. Модели жизненного цикла программного обеспечения асоиу. Подход rad.
- •3. Методология rad
- •Основные принципы методологии rad
- •4. Структурный подход к проектированию информационной системы. Функциональная модель асоиу. Количественный анализ диаграмм idef0 и dfd.
- •5. Объектно-ориентированный подход к анализу и проектированию информационной системы. Унифицированный язык моделирования uml.
- •6. Моделирование бизнес-процессов спецификация требований на основе структурного подхода.
- •7. Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика rup.
- •8. Разработка модели защиты данных в асоиу
- •9. Управление проектом асоиу
- •10. Проектная документация асоиу. Требования госТов к документации, содержание документации.
- •11. Инструментальные средства проектирования асоиу.
- •12. Типизация проектных решений асоиу. Использование коробочных продуктов и адаптируемых интегрированных систем.
- •Самостоятельная разработка
- •Заказные системы
- •Тиражируемые (коробочные) продукты
- •Адаптируемые интегрированные системы
- •Адаптируемые интегрированные системы как платформа современных комплексных систем автоматизации
- •13. Графические средства представления проектных решений асоиу (idef, dfd, uml, erd и т.Д.)
- •14. Классификация ис
- •15. Рынок ис
- •16. Методы проектирования ис
- •17. Каноническое проектирование
- •18. Типовое проектирование
- •19. Предпроектное обследование предприятий
- •1. Анкетирование
- •2. Сбор документов
- •3. Интервьюирование
- •20. Этапы проектирования ис с применением uml
- •21. Модель процессов msf (тут же про опыт ibm)
- •22. Сертификация и оценка процессов создания по. Модель зрелости cmm.
- •23. Сертификация и оценка процессов создания по. Методика spmn.
- •9 Лучших навыков, рекомендованных spmn.
- •5. Качество продукта должно контролироваться на детальном уровне.
- •8. Конфигурационное управление.
- •24. Парадигма Бейзили
- •25. Проектирование бд
- •26. Распределенная обработка данных
- •27. Системное проектирование программных систем на основе стандартизации
- •28. 34 Компетенции для Управления Проектом
3. Модели жизненного цикла программного обеспечения асоиу. Подход rad.
Модель жизненного цикла - это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее распространение получили каскадная, а затем спиральная модели.
Каскадная модель разбивает процесс ЖЦ на пять этапов, выполняемых последовательно, один за другим:
Недостатки:
-
часто возникает потребность в возврате к предыдущим этапам для уточнения или пересмотра ранее принятых решений. В результате процесс принимает вид “модели с промежуточным контролем”
-
существенное запаздывание с получением результатов,
-
требования к ИС "заморожены" в виде технического задания на все время ее создания, и, в случае неточного изложения требований или их изменения за время создания ПО, модель автоматизируемого объекта устаревает к моменту реализации
Спиральная. Делает упор на начальные этапы ЖЦ - анализ и проектирование. Реализуемость технических решений проверяется на этих этапах путем создания прототипов.
Каждый виток спирали соответствует созданию фрагмента или версии ПО. Главная задача при работе по спиральной модели - возможно быстрее показать пользователю работоспособный продукт, чтобы активизировать процесс уточнения и дополнения требований.
Спиральная модель обладает рядом преимуществ:
-
Модель уделяет специальное внимание раннему анализу возможностей повторного использования.
-
Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта.
-
Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта.
-
Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта.
-
Модель позволяет контролировать источники проектных работ и соответствующих затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо затратить на каждую стадию.
-
Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего.
Недостатки:
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
3. Методология rad
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений - RAD (Rapid Application Development).
Методология RAD предполагает:
-
маленький коллектив 2 – 10 чел.
-
короткий график от 2 до 6 мес.
-
повторяющийся цикл
Основные принципы методологии rad
-
итерационность процесса разработки приложений;
-
необязательность полного завершения работ на каждом этапе;
-
максимальное вовлечение пользователей в разработку;
-
использование CASE - средств, обеспечивающих целостность проекта;
-
использование генераторов программного кода;
-
использование прототипирования для уточнения потребностей пользователей;
-
тестирование и развитие проекта одновременно с разработкой;
-
небольшие квалифицированные команды разработчиков;
-
четкое планирование и контроль на всех этапах работы.
Методология RAD дает хорошие результаты при выполнении относительно небольших проектов для конкретного заказчика.
Однако, ее нельзя использовать:
-
при разработке типовых систем, которые затем адаптируются к особенностям объектов внедрения;
-
для построения сложных расчетных программ, операционных систем, программ управления сложными объектами (системы АСУ ТП);
-
к приложениям, у которых интерфейсная часть не определяет логику работы системы;
-
к разработке систем, от которых зависит безопасность людей (например: управление самолетом или АЭС).
Оценка размера приложения, а значит и необходимого количества разработчиков ПО, производится, исходя из количества функциональных элементов в будущей системе.