- •1.Технология создания по. Методы средства процедуры.
- •2. Распределение обязанностей в команде разработчиков
- •3. Стратегии конструирования по. Инкрементная модель
- •4. Стратегии конструирования по. Спиральная модель
- •7. Оценка программного проекта. Размерно-ориентированные метрики
- •8. Оценка программного проекта. Функционально-ориентированные метрики
- •9. Оценка программного проекта. Метод функциональных указателей
- •10. Конструктивная модель оценки стоимости. Модель композиции приложения
- •11. Модель раннего этапа проектирования
- •12. Модель этапа постархитектуры
- •14. Модели жизненного цикла проектирования по.
- •15. Унифицированный процесс разработки, его структура
- •16. Унифицированный процесс разработки. Рабочие потоки процесса
- •18. Унифицированный процесс разработки. Этап конструирование (Construction)
- •19. Управление риском при разработке по. Этап оценивания
- •20. Управление риском при разработке по. Этап контроля
- •40. Конструктивная модель стоимости cocomo’81
- •21. Понятие и принципы тестирования.
- •5. Проектирование на базе стандарта idef3.
- •40. Конструктивная модель оценки стоимости cocomo81.
- •10 Конструктивная модель оценки стоимости. Модель композиции приложений.
- •11 Конструктивная модель оценки стоимости. Модель раннего этапа проектирования.
- •12 Конструктивная модель оценки стоимости. Модель этапа пост-архитектуры.
- •6.Проектирование на базе стандарта dfd
- •22.Структурное тестирование по.
- •23.Способы тестирования базового пути.
- •24. Способы тестирования условий. Тестирования циклов
- •25. Функциональное тестирование по.
- •26. Тестирование с помощью диаграмм причинно-следственных связей.
- •27. Организация процесса тестирования. Тестирование элементов и интеграции.
- •28 Организация процесса тестирования. Тестирование правильности. Системное тестирование
- •19 Управление риском при разработке по. Этапы оценивания.
- •20 Управление риском при разработке по. Этапы контроля.
- •13.Проектирование на базе стандарта idef0.
- •29. Базовые понятия uml. Структурные предметы.
- •30. Базовые понятия uml. Предметы поведения, группирующие и поясняющие предметы. Отношения
- •31. Базовые понятия uml. Виды диаграмм, их краткая характеристика.
- •33. Статические модели uml. Отношение в диаграммах классов.
- •Вершины в диаграммах классов
- •Свойства
- •34. Моделирование поведения. Диаграмма схем состояния.
- •35. Моделирование поведения. Диаграммы деятельности.
- •36. Моделирование поведения. Диаграммы взаимодействия.
- •37. Моделирование поведения. Диаграммы последовательности.
- •38. Моделирование поведения. Диаграммы прецедентов.
- •39. Архитектурное моделирование.
- •32.Статические модели uml . Классы в uml.
18. Унифицированный процесс разработки. Этап конструирование (Construction)
Главное назначение этапа - создать программный продукт, который обеспечивает начальные операционные возможности.
Цели этапа КОНСТРУИРОВАНИЕ:
§ минимизировать стоимость разработки путем оптимизации ресурсов и устранения необходимости доработок;
§ добиться быстрого получения приемлемого качества;
§ добиться быстрого получения контрольных версий (альфа, бета и т. д.).
Основные действия этапа КОНСТРУИРОВАНИЕ:
§ управление ресурсами, контроль ресурсов, оптимизация процессов;
§ полная разработка компонентов и их тестирование (по сформулированному критерию эволюции);
§ оценивание реализаций продукта (по критерию признания из спецификации представления).
В итоге этапа КОНСТРУИРОВАНИЕ создаются следующие артефакты:
§ программный продукт, готовый для передачи в руки конечных пользователей;
§ описание текущей реализации;
§ руководство пользователя.
Реализации продукта создаются в серии итераций. Каждая итерация выделяет конкретный набор элементов риска, выявленных на этапе развития. Обычно в итерации реализуется один или несколько элементов Use Case. Типовая итерация включает следующие действия:
1. Идентификация реализуемых классов и отношений.
2. Определение в классах типов данных (для свойств) и сигнатур (для операций). Добавление сервисных операций, например операций доступа и управления. Добавление сервисных классов (классов-контейнеров, классов-контроллеров). Реализация отношений ассоциации, агрегации и наследования.
3. Создание текста на языке программирования.
4. Создание (обновление) документации.
5. Тестирование функций реализации продукта.
6. Объединение текущей и предыдущей реализаций. Тестирование итерации.
Этап ПЕРЕХОД (Transition)
Главное назначение этапа - применить программный продукт в среде пользователей и завершить реализацию продукта.
Этап начинается с предъявления пользователям бета-реализации продукта. В ней обнаруживаются ошибки, они корректируются в последующих бета-реализациях. Параллельно решаются вопросы размещения, упаковки и сопровождения продукта. После завершения бета-периода тестирования продукт считается реализованным.
19. Управление риском при разработке по. Этап оценивания
Существует множество определений риска как наличие неопределенности, связанной с наступлением нежелательного события, и ущерба, понесенного вследствие наступления этого события.
Риск (по определению SEI (Software Engineering Institute)) - это возможность понести потери.
Риск проекта ПО - это возможность:
1) снижения качества конечного продукта,
2) повышения стоимости его разработки,
3) задержки окончания разработки или срыва проекта (то есть, отказа от проекта)
Величина риска представляет собой R = V * P произведение величины потерь V от нежелательного события в проекте и вероятности P наступления этого события.
Величина потерь V рассматривается в контексте влияния нежелательного события на характеристики ПО, на сложность его последующего сопровождения, а также эффективность, стоимость и продолжительность процесса разработки ПО, а вероятность P - как степень определенности, с которой можно прогнозировать проявление риска в проекте, то есть перерастание данного риска в проблему для проекта.
Эффективное управление риском состоит в принятии (по каждому риску) компромиссных решений по:
· учету рисков и анализу старых проектов;
· оценке трудоемкости устранения определенного риска,
· величине потенциального отрицательного воздействия этого риска на проект,
· в правильной оценке взаимозависимости устраняемых рисков и возможного влияния принятых в определенный (текущий) момент времени решений на состояние проекта в будущем;
· резервировании в проекте времени на борьбу с рисками.
Оценивание риска ПО
Методология SRE предлагает формальный метод идентификации, анализа, контроля и устранения риска ПО, который применяется первоначально на самой ранней стадии разработки проекта ПО (еще до заключения договора с разработчиком) и затем периодически в ходе всего ЖЦ проекта. Предлагаемые SRE функции управления риском подразделяются на основные и обеспечивающие.
К основным функциям управления риском относятся:
· обнаружение,
· спецификация,
· оценивание,
· структурирование (консолидация)
· устранение рисков.
Выполнение функции обнаружения рисков обеспечивает систематический и полный охват всех потенциальных областей риска с применением адекватных инструментов и технологий, в частности, опросника TBQ.
Выполнение функции спецификации риска касается фиксации всех аспектов идентифицированного риска ПО. Спецификация риска представляет собой структуру, которая упрощает решение задач приоритезации рисков, локализации источников и причин возникновения рисков, определения методов и усилий, предпринимаемых для устранения рисков в источниках их возникновения.
Существует много способов спецификации риска - от простого утверждения о риске до сложного высказывания с применением условных выражений вида “ЕСЛИ <условие> ТО <последствия>”, связок “И” и др. Выбор того или иного способа определяется эффективностью его практического применения для проекта и особенностями инструментальной поддержки обработки рисков.
Функция оценивания риска заключается в определении величины каждого риска ПО, что служит основанием для присваивания приоритета риску и выявления наиболее важных на текущий момент рисков проекта.
Существуют различные механизмы оценивания величины риска - от простых субъективных оценок по 3-бальной шкале до строгих статистических измерений.