- •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.
1.Технология создания по. Методы средства процедуры.
При разработке программных систем для того чтобы обеспечить качество программного продукта необходимо выполнить определенную последовательность шагов которые называются технологией разработкой ИАС. В состав технологий так же входят методы, средства и процедуры. Методы позволяют решать след задачи:
1.планирование и оценка проекта.
2.анализ требований.
3. проектирование алгоритмов, структур данных и программных структур.
4. кодирование.
5. тестирование.
6.сопровождение.
Средства (утилиты) – они обеспечивают автоматизированную поддержку методов.
Процедуры – они соединяют методы и средства, чтобы образовалась непрерывная технологическая цепочка разработки программного обеспечения.
Процедуры определяют порядок применения методов и утилит – разработка отчетов и обеспечивают контроль процесса разработки.
2. Распределение обязанностей в команде разработчиков
В составе команды разработчиков каждого мини-проекта должны быть выделены следующие роли:
лидер мини-проекта отвечает за проект в целом, осуществляет распределение работ среди участников проекта и контролирует их выполнение;
главный разработчик отвечает за создание технического задания по мини-проекту, выполнение высокоуровневого проектирования (состав/содержание/план/структура конспекта и презентации);
главный тестер отвечает за планирование качества и тестирование конспекта и презентации (проверка соответствия зафиксированной структуре, отслеживание выполнения принятых правил оформления);
технический писатель выполняет поиск и накопление материалов, отвечает за реализацию (написание) компонентов конспекта и презентации (разделов, частей);
тестер выполняет тестирование компонентов конспекта и презентации (разделов, частей).
Замечание: каждый участник мини-проекта может выполнять несколько ролей одновременно
3. Стратегии конструирования по. Инкрементная модель
Существуют 3 стратегии конструирования ПО:
· однократный проход (водопадная стратегия) - линейная последовательность этапов конструирования;
· инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
· эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Характеристики стратегий конструирования
Стратегия конструирования
В начале процесса определены все требования?
Множество циклов конструирования?
Промежуточное ПО распространяется?
Однократный проход Инкрементная (запланированное улучшение продукта) Эволюционная
Да Нет Нет
Да Да Может быть
Нет Да Да
Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.
Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте - более сложные возможности редактирования и документирования; в 3-м инкременте - проверку орфографии и грамматики; в 4-м инкременте - возможности компоновки страницы.
Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными).
План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.