
- •1. История развития систем автоматизированной разработки пс.
- •2. Case-технология в разработке пс
- •3.Основные элементы объектной модели проектирования программного обеспечения (абстрагирование, инкапсуляция, модульность, иерархия). Особенности построения объектно-ориентированной системы.
- •4. Дополнительные элементы объектной модели проектирования программного обеспечения (типизация, параллелизм, устойчивость). Полиморфизм и наследование.
- •5. История появления, особенности и назначение унифицированного языка моделирования uml.
- •6.Назначение программного средства Rational xde. Основные окна и пункты меню Rational xde.
- •7.Сравнительный анализ программных продуктов Rational Rose и Rational xde
- •8. Назначение, особенности и построение диаграммы Use Case.
- •9. Назначение, особенности и построение диаграммы Deployment.
- •10. Назначение, особенности и построение диаграммы Statechart.
- •11. Назначение, особенности и построение диаграммы Activity.
- •12. Назначение, особенности и построение диаграммы Sequence.
- •13. Назначение, особенности и построение диаграммы Collaboration.
- •14. Назначение, особенности и построение диаграммы Component.
- •15, 16. Назначение, особенности и построение диаграммы Class.
- •17. Назначение и виды связей между классами на диаграммах Rational Rose. Особенности следующих связей: однонаправленная ассоциация, зависимость, ассоциированный класс, наследование, реализация.
- •19. Создание шаблона приложения с использованием библиотеки mfc. Структура и классы приложения.
- •20. Функциональные возможности Rational Rose: модуль Component Assignment Tool, компонент Model Assistant, обновление кода по модели и модели по коду.
- •21. Особенности генерации исходного кода в среде Rational xde. Способы синхронизации модели.
- •22. Сравнительный анализ процедур генерации исходного кода в Rational Rose и Rational xde
- •23. Назначение, возможности, особенности использования модуля Data Modeler.
- •24. Назначение, возможности, особенности использования модуля Data Modeler в Rational xde.
- •25. Назначение, возможности, особенности использования модуля Web Modeler.
- •26. Возможности и особенности построения Web-модели в среде Rational xde
- •27. Продукт Rational Unified Process (rup), его цели и назначение.
- •28. Статический и динамический аспекты rup.
- •29. Использование программного средства rup в сочетании с диаграммами uml
- •30.Принципы и стадии разработки пс в технологии Rational Unified Process.
- •31. Содержание и результаты первой и второй стадий в технологии Rational Unified Process
- •32. Содержание и результаты третьей и четвертой стадий в технологии rup.
- •33. Этапы и процессы создания пс в технологии Oracle.
- •34. Классический и быстрый подходы к разработке пс в технологии Oracle. Факторы, определяющие выбор подхода.
- •35. Этапы разработки пс в технологии Borland.
- •36. Принцип модульности при разработке пс
- •37. Управление рисками проекта. Процедуры идентификации и анализа рисков.
- •38. Управление рисками проекта. Ранжирование, планирование управления, разрешение и наблюдение риска.
- •39. Метрики объектно-ориентированных программных систем. Локализация. Инкапсуляция. Информационная закрытость
- •40. Метрики объектно-ориентированных программных систем. Инкапсуляция. Наследование. Абстракция.
- •41. Назначение и компоненты системной модели сапр. Обозначение, наименование, цели системы, общесистемные характеристики, входы-выходы, структура системы.
- •42. Критерии развития сапр. Функциональные и технологические критерии.
- •43. Критерии развития сапр. Экономический и эргономический критерии.
- •44. Перспективы развития технологий разработки программного обеспечения.
36. Принцип модульности при разработке пс
Современные компьютеры позволяют хранить в базах данных практически неограниченный объем информации. Отсюда возникает желание накапливать на электронных носителях знания для решения необходимых задач. Первым шагом для осуществления указанного требования является оформление программ в виде модулей, отвечающих некоторым стандартным соглашениям. Это обеспечивает возможность соединения ПМ для решения более крупных задач. Модульный принцип сочетается с синтезом программ на основе ориентированных графов. Заданный маршрут на графе ассоциируется с решением поставленной задачи, при этом следует учитывать вопросы передачи параметров между ПМ, поскольку для их совместного использования необходима программная стыковка модулей. Алгоритмы построения и изображение графов могут быть самыми различными, но смысловая нагрузка остается неизменной: порядок вызова программных модулей, входящих в синтезируемую программу. Кроме этого, для решения задачи составляется управляющая программа, которая в надлежащем порядке вызывает все программные единицы на выполнение. Построение управляющей программы требует детальных знаний свойств модулей и, прежде всего, знания функций, реализуемых ПМ. С ростом количества информации, хранимой в БД, выбор ПМ усложняется. Поэтому, с целью облегчения подбора модулей, последние снабжаются паспортами, в которых описываются их характеристики: идентификатор, назначение, язык программирования, способ обращения, входные и выходные данные с указанием их формата, технические сведения, параметры настройки.
Модульное программирование подразумевает умение разбить задачу на некоторое число самостоятельных подзадач, широкое использование стандартных модулей путем их параметрической настройки, автоматизацию сборки готовых модулей, создание и управление библиотеками готовых модулей.
В модульной технологии широко применяется техника макрогенераций. Принцип модульности требует, чтобы программное обеспечение удовлетворяло жестким требованиям стандартизации, унификации, а САSE-средства содержали компоненты, позволяющие производить разбиение алгоритмов на модули, проверять эффективность модуляризации, находить оптимальную степень интеграции модулей и их иерархичность.
37. Управление рисками проекта. Процедуры идентификации и анализа рисков.
Влияние риска вычисляют по приведенной формуле:
RE=P(UO)*L(UO), P(UO) – вероятность неудовлетворительного результата.
L(UO) – потери от неудовлетворительного результата, RE – показатель риска.
При разработке программного продукта неудовлетворительным результатом м. б.
Превышение бюджета
Низкая надежность
Некорректное функционирование
Управление рисками включает 6 действий:
Идентификация (выявление) риска.
Анализ риска – оценка вероятности и величины потери по каждому элементу риска
Ранжирование риска (упорядочивание по степени влияния)
Планирование управления риском (подготовка к работе с каждым элементом риска)
Разрешение риска (устранение или разрешение элемента риска)
Наблюдение риска (отслеживание динамики и выполнение корректировки действий)
1-3) Оценивание риска 4-6)Контроль риска
1) Формируется список элементов, специфичных для данного проекта. Выделяются 3 категории источников риска:
а) Проектный (выбор бюджета, плана, человеческих ресурсов, некорректные требования, сложность, размер и структура проекта, методика взаимодействия с заказчиком
б) Технический (трудности проектирования, программирования, тестирования и сопровождения, неточность спецификации)
в) Коммерческий (создание продукта не нужного на рынке, создание продукта, который опережает требования рынка; потеря финансирования)
Лучший способ идентификации – проверочные списки рисков, которые помогают выявить реальный риск. Например, проверочный список главных элементов программного риска может иметь вид:
1) дефицит персонала
2) нереальные расписания и бюджет
3) разработка некорректных функций
4) разработка неудачного интерфейса
…..
После идентификации элементов риска, количественно оценивают их влияние на проект, решая вопросы о возможных потерях.
2) В ходе анализа оценивается вероятность возникновения Pi и величина потери Li каждого выявленного элемента риска. Вероятности определяются на основе статистики или эксперта. Итог анализа можно свести в таблицу.
Элементы риска |
Вероятность(%) |
Потери(%) |
Влияние риска |