- •1. Технология разработки программного обеспечения. Определение. Основные этапы на примере классического жизненного цикла.
- •2. Два взгляда на по: научная разработка, программное изделие. Свободное по.
- •3. Парадигмы проектирования программных систем. Макетирование.
- •4.Парадигмы проектирования пс. Инкрементная модель.
- •5. Парадигмы проектирования программных систем. Быстрая разработка приложений.
- •6. Парадигмы проектирования программных систем. Спиральная модель.
- •7. Парадигмы проектирования программных систем. Компонентно-ориентированная модель.
- •8. Парадигмы проектирования программных систем. Унифицированный процесс. Rup.
- •1. Начало
- •2. Уточнение
- •3. Построение (Конструирование)
- •4. Внедрение
- •9. Парадигмы проектирования программных систем. Экстремальное программирование.
- •10. Спецификация требований. Виды требований.
- •1) Пользовательские требования
- •2) Системные требования
- •3) Проектная системная спецификация.
- •11. Функциональные требования.
- •12. Нефункциональные требования.
- •13. Требования предметной области.
- •14. Пользовательские требования.
- •15. Системные требования.
- •16. Описание технического задания по гост.
- •17. Прецеденты. Определение. Актеры. Сценарии.
- •18. Задачи и рамки прецедентов.
- •19. Степень формализации прецедентов. Сжатый, свободный и развёрнутый формат описания.
- •20. Пояснения к прецедентам. Предусловия и постусловия. Альтернативные сценарии.
- •22. Объектно-ориентированные анализ и проектирование программных систем. Основные определения.
- •23. Основные принципы объектно-ориентированной разработки программ.
- •24. Обязанности объектов. Разложение системы на объекты. Crc-карты.
- •25. Инкапсуляция. Связность внутри классов и зацепление между классами.
- •26. Композиция и наследование. Абстрактные классы. Интерфейс класса. Рекомендации.
- •27. Методы, операции, сообщения. Разделение команд и запросов.
- •28. Проектирование по контракту. Предусловия и постусловия в методах. Инварианты.
- •29. Паттерны проектирования. Определение. Формат описания.
- •30. Виды паттернов по уровню абстракции и по цели. Примеры.
- •36. Минимальное грубое тестирование
- •37. Автоматизированные тесты. Основные определения. XUnit
- •38. Разработка через тестирование
- •39. Особенности командной разработки по
- •40. Оценка стоимости по. Модели и методики. Модель cocomo
6. Парадигмы проектирования программных систем. Спиральная модель.
Спиральная модель — классический пример применения эволюционной стратегии конструирования.
Как показано на рисунке, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.
Планирование — определение целей, вариантов и ограничений.
Анализ риска — анализ вариантов и распознавание/выбор риска.
Конструирование — разработка продукта следующего уровня.
Оценивание — оценка заказчиком текущих результатов конструирования.
С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.
В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Достоинства спиральной модели:
наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции разработки;
включает шаг системного подхода в итерационную структуру разработки;
использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
повышенные требования к заказчику;
трудности контроля и управления временем разработки.
7. Парадигмы проектирования программных систем. Компонентно-ориентированная модель.
Компонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание квадранта конструирования — оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов.
1) Идентификация кандидатов в компоненты
2) Поиск готовых компонентов
3) Если компонент найден, то извлечение
4) Если не найден, то конструирование
5) Включение новых компонентов в библиотеку
6) Сборка системы из компонентов очередной итерации системы.
Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку.
Достоинства компонентно-ориентированной модели:
уменьшает на 30% время разработки программного продукта;
уменьшает стоимость программной разработки до 70%;
увеличивает в полтора раза производительность разработки.
Недостатки компонентно-ориентированной модели:
Программы, состоящие из многих компонентов, медленно работают.