- •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.
21. Понятие и принципы тестирования.
Тестирование это выполнение программы с целью обнаружения ошибок. В процессе тестирования разрабатываются тесты или тестовые варианты, которые как правило содержат набор исходных данных и набор ожидаемого результата. После выполнения теста полученный результат сравнивается с ожидаемым и если есть несовпадения значит обнаружена ошибка. По результатам тестирования можно сделать след вывод:
1)Если ошибок много и они серьезные, то необходимо усилить тестирование.
2) если ошибки не большие и встречаются редко, то должно быть 2 варианта- либо программа качественная плохо тестируем.
Существует 2 осн принципа тестирования которые обязательно нужно проводить при проверки программы.
1.структурное тестирование.
2.функциональное тестирование.
5. Проектирование на базе стандарта idef3.
Стандарт IDEF3 используется для описания документа оборота. Этот стандарт имеет много общего со стандартом IDEF но есть и отличие.
Работа глагол Unit of Work (now) так же в этом стандарте используются связи которые могут иметь любое направление и могут начинаться и заканчиваться в любом направлении.
Связи бывают 3-ех видов:
1.временные предшествования.
Что след действие начинается после окончания первого блока.
2. объектный поток
Означает что первое действие передает во второе какой-то объект.
3. нечеткие отношения
Указывают связи между параллельными действиями.
Для слияния и разделения стрелок используются соединения, они бывают разворачивающие когда окончание первого действия приведет к началу нескольких других и 2-ая сворачивающая – завершение неск действий приводит к началу 1 –ого действия.
1.если и разворачивающие , то все действия должны начаться.
2.сварачивающая – все действия должны закончится.
3.если оно разворачивающие неск действий должны начаться, если сварачивающие нескл могут закончится.
Все соединения на диаграмме должно быть парами.
40. Конструктивная модель оценки стоимости cocomo81.
1981г. Барри Боэн предложил модель Cons functive Cost Medel – COCOMO81. В состав модели входят 3 подмодели.
1.базисная- позволяет определить затраты на разработку и стоимость в зависимости от ее размера.
2.промежуточная – она уточняет базисную учитывая сложность требований, возможности персонала.
3. усовершенствованная – уточняет стоимость программы на каждом этапе жизненного цикла.
E = aв * KLOC
Д = 2,5 * Е
Е- затраты чел/месс
KLOC – кол-во сточек в программном продукте.
Д – время разработки
а,в,d – коэф принимают различные значения размера программы опыта разработчика и сложности требования.
В 1995г – Барри предложил модель СОСОМО2 которая учитывает особенности объекта ориентируемой разработки программ входит 3- и подмодели:
1.Модель композиции приложения.
2.модель раннего этапа проектирования.
3.модель этапа пост-архитектуры.
в этой модели используются объектные указатели, которые позволяют измерить программный продукт по кол—во экранов отчетов и компонентов интерфейса, каждый из этих 3-ех элементов оцениваются по сложности (простой, средний, сложный) и получают определенный ряд.
отчет |
Кол-во |
простой |
средний |
сложный |
итого |
Экран |
Х1 |
Х1*1 |
Х1*2 |
Х1*3 |
= |
Отчет |
Х2 |
Х2*2 |
Х2*5 |
Х2*8 |
= |
контеб |
Х3 |
- |
- |
Х3*10 |
= |
Объединенные показатели |
сумма |
NOP- объектные указатели * (100-ReUse)/100
Затраты NOP/PROD ; PROD- скорость разработки
Модель раннего этапа проектирования применяется на этапе.
Затраты = А * размер в * Ме + затраты алко
А- коэф масштаба 2,5
А – длинна программного продукта в строках
В – может принимать значения от 101 до 1,26 зависит от 5-ти масштабных факторов – подсказуем степень риска, сложности группы разработчиков зрелости процесса.
Ме – множитель поправки, который зависит от возможности персонала сложности продукта, от требовании графики.
Затраты алко- затраты на автоматический гинирируемый ход.
Модель этапа пост-архитектуры применяется на завершающих стадиях проекта
Затраты = А * Ктед * размер * Мр + затраты алко
Ктед – это коэф который учитывает изменения в требованиях.
Ктед = 1+ВRAK/100
ВRAK - % входа который был отображен кода, из-за смены требований.
Мр – множитель поправки, зависит от 17 факторов хар-ка – продукции: надежность, сложность, набор БД, учитывает платформу, учитывать возможность персонала.
Стоимость = затраты*раб.коэф.
Раб коэф = 15000$ чел/меч
Можно определить длительность разработки
Т = 3,0 * затраты 0,33 +0,2 (в-1,01) * Sced /100
Sced - % отклонения от графика (допуск 75% 150%) – увелич риск.