- •2. Функциональный подход
- •4. Объектно-ориентированная методология. А
- •6. Диаграмма деятельности (Activity Diagram)
- •7. Системный подход к разработке по
- •8. Вид и назначение диаграммы компонент Component diagram.
- •9. Процессный подход к разработке по. Текущий, конкретный и стандартный процессы компании.
- •10. Моделирование данных. Методология idef1x. Диаграммы «сущность-связь».
- •11. Процессный подход к разработке по. Проблемы и пути решения: стратегии Organization pull и Technology push.
- •12. Вид и назначение диаграммы сценариев Use case diagram.
- •13. Процессный подход к разработке по. Стандарты CobIt, itil, Scrum.
- •14. Основные понятия объектно-ориентированной методологии (объект, класс, атрибут, метод).
- •15. Понятие жизненного цикла по. Три группы процессов
- •16. Понятие связности модуля
- •17. Водопадная модель жизненного цикла аис. Достоинства и недостатки.
- •18. Универсальный язык моделирования (uml). Назначение и характеристики.
- •19. Спиральная модель жизненного цикла аис. Достоинства и недостатки.
- •20. Функциональная методология idef0.
- •21. Инкрементная модель жизненного цикла аис. Достоинства и недостатки.
- •23. Тяжеловесные (прогнозирующие) и подвижные (облегченные, адаптивные) семейства процессов жц по
- •24. Базовые понятия erd-диаграмм: ключи, нормализация данных, домены, индексы, триггеры.
- •25. Принципы Agile Manifesto. Примеры процессов.
- •26. Case-средства. Средства проектирования.
- •27. Экстремальное программирование.
- •28. Вид и назначение диаграммы кооперации Collaboration diagram.
- •29. Стадии разработки аис в соответствие с гост 34.601-90 «Автоматизированные системы. Стадии создания».
- •30. Вид и назначение диаграммы последовательностей действий Sequence diagram.
- •31. Содержание технического задания в соответствие с гост 34.602-89 «Техническое задание на создание автоматизированной системы».
- •32. Case-средства. Средства управления требованиями.
- •33. Содержание стадий «Технический проект», «Рабочая документация», «Ввод в действие» в соответствие с гост 34.601-90 «Автоматизированные системы. Стадии создания».
- •34. Моделирование потоков работ. Методология idef3
- •35. Организационное моделирование. Схема организационного бизнес-моделирования. Полная бизнес-модель компании.
- •Полная бизнес-модель компании
- •36. Этапы проектирования аис с применением языка универсального моделирования (uml).
- •37. Инжиниринговый подход к бизнес-моделированию. Матрицы проекций. Case-средства. Средства тестирования.
- •38. Шаблоны разработки функционала, зон ответственности. Шаблон разработки миссии
- •Шаблон формирования бизнесов
- •39. Моделирование потоков данных. Методология dfd.
- •40. Бизнес процессы компании. Понятие. Классификация.
- •41. Вид и назначение диаграммы классов Class diagram.
- •42. Case-средства. Средства управления конфигурациями.
- •43. Предпроектное обследование предприятия.
37. Инжиниринговый подход к бизнес-моделированию. Матрицы проекций. Case-средства. Средства тестирования.
В последние годы на мировом рынке программных продуктов появилось много программных средств, называемых CASE-системами, CASE-инструментами или CASE-средствами (CASE-tools). Этопрограммные системы, позволяющие автоматизировать использованиеновых методов проектирования ПОдля разработки сложных систем на всехэтапах разработки (особенно на ранних стадиях разработки).Термин CASE трактуется весьма широко. Первоначально он расшифровывался какComputerAidedSoftwareIngeneering (компьютерная поддержкапроектирования ПО), и связано это было с автоматизацией разработкипрограммных систем. В дальнейшем понятие CASE приобрело новый смысл, все чаще его стали расшифровывать как ComputerAidedSystemIngeneering (компьютерная поддержка проектирования систем), аCASE-средства все больше стали ориентироваться на созданиеспецификаций, проектирование и моделирование сложных систем широкого назначения.
Применение CASE-продуктов позволяет отслеживать процесспринятия решений при разработке больших проектов, систематизироватьинформацию о проекте и его компонентах, упрощая тем самымверификацию проекта и сопутствующей ему документации. Важнымаспектом CASE-подхода является поддержка коллективной работы, при которой каждый из разработчиков создает свою подсистему, причем влюбой момент времени эти подсистемы могут быть объединены в общийпроект.
Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок. Регрессионное тестирование — это тестирование, проводимое после усовершенствования функций программы или внесения в нее изменений.
Одно из наиболее развитых средств тестирования QA (новое название — QualityWorks) представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.
QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.
В заключение приведем пример комплекса CASE-средств, обеспечивающего поддержку полного ЖЦ ПО. Нецелесообразно сравнивать отдельно взятые CASE-средства, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков (отметим, что рациональное комплексирование инструментальных средств разработки ПО ИС является важнейшим условием обеспечения качества этого ПО, причем это замечание справедливо для всех предметных областей). На сегодняшний день наиболее развитым из всех поставляемых в Россию комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, основанный на методологии и технологии DATARUN.