
- •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. Предпроектное обследование предприятия.
1. Программная инженерия — это интегрирование принципов математики, информатики и компьютерных наук с инженерными подходами, разработанными для производства осязаемых материальных артефактов[1].Также программная инженерия определяется как системный подход к анализу, проектированию, оценке, реализации, тестированию, обслуживанию и модернизации программного обеспечения, то есть применение инженерии к разработке программного обеспечения.
Основываясь на математике и компьютинге, программная инженерия занимается разработкой систематических моделей и надежных методов производства высококачественного программного обеспечения, и данный подход распространяется на все уровни — от теории и принципов до реальной практики создания программного обеспечения, которая лучше всего заметна сторонним наблюдателям.
программная инженерия – это наука, которая изучает вопросы создания, сопровождения и внедрения программного обеспечения с заданным качеством, в заданные сроки и в рамках заранее определенного бюджета.
2. Функциональный подход
Любой объект и система разбиваются на ряд элементов или функций, задач, которые в определенных границах могут рассматриваться как независимые процессы, функции, задачи, что позволяет их описывать, моделировать, отображать.
Определяются граничные условия и желательные входы и выходы, составляется подробный перечень функций или операций, которые должны выполняться.
Принципы:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
SADT
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
связность диаграмм (номера блоков);
уникальность меток и наименований (отсутствие повторяющихся имен);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных).
отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
3. SWEBOK
Назначение SWEBOK – в объединении знаний по инженерии ПО. В этом ядре были систематизированы разнородные знания в области программирования, планирования и управления.
SWEBOK включает 10 областей знаний (knowledge areas, KA), которые соответствуют процессам проектирования ПО и методам их поддержки а именно 1. Software requirements –требования к ПО. 2. Software design – проектирование ПО. 3. Software construction – конструирование ПО. 4. Software testing - тестирование ПО. 5. Software maintenance – сопровождение ПО. 6. Software configuration management –управление конфигурацией. 7. Software engineering management – управление в программной инженерии. 8. Software engineering process – процессы программной инженерии. 9. Software engineering tools and methods – инструменты и методы программной инженерии. 10. Software quality – качество ПО.
В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с которыми представлена как фундаментальная, важная и обоснованная для программной инженерии: 1. Computer engineering – разработка компьютеров. 2. Computer science – информатика. 3. Management – общий менеджмент. 4. Mathematics – математика. 5. Project management – управление проектами. 6. Quality management – управление качеством. 7. Systems engineering – системное проектирование.