
- •Сосновский Ю.В.
- •Технологические основы языков программирования высокого уровня
- •СЛОЖНОСТЬ ЗАДАЧ
- •КАК БОРОТЬСЯ СО
- •ТЕХНОЛОГИИ
- •ОПРЕДЕЛЕНИЯ
- •Модель жизненного цикла ПП – описание набора фаз (этапов, стадий) проекта по созданию
- •Отладка (Debugging) – деятельность, направленная на установление точной природы известной ошибки, а затем
- •ПРОЦЕСС РАЗРАБОТКИ ПО
- •ЖИЗНЕННЫЙ ЦИКЛ ПО
- •ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
- •УРОВНИ ЖИЗНЕННОГО ЦИКЛА
- •PDCA-ЦИКЛ
- •КАСКАДНАЯ МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА ПО
- •КАСКАДНАЯ МОДЕЛЬ
- •МАКЕТИРОВАНИЕ (ПРОТОТИПИРОВАНИЕ)
- •ИНКРЕМЕНТНАЯ МОДЕЛЬ ЖЦ РАЗРАБОТКИ ПО
- •Требования и планирование
- •1-й инкремент
- •снижается риск неудачи и изменения требований
- •ИТЕРАЦИОННАЯ МОДЕЛЬ
- •СПИРАЛЬНАЯ МОДЕЛЬ
- •СПИРАЛЬНАЯ (ЭВОЛЮЦИОННАЯ) МОДЕЛЬ РАЗРАБОТКИ П
- •ОСОБЕННОСТИ СПИРАЛЬНОЙ МОДЕЛИ
- •V-МОДЕЛЬ ЖИЗНЕННОГО
- •Планирование
- •ПРЕИМУЩЕСТВА V-МОДЕЛИ
- •AGILE МЕТОДОЛОГИИ
- •АКТУАЛЬНЫЕ МЕТОДОЛОГИИ РАЗРАБОТКИ ПО
- •ГИБКАЯ РАЗРАБОТКА (AGILE)
- •AGILE MANIFESTO
- •AGILE MANIFESTO
- •ТЕХНОЛОГИЯ RAD
- •ЭТАПЫ RAD
- •ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ
- •ОСНОВНЫЕ ПРИНЦИПЫ ХР
- •Extreme programming explained
- •РЕФАКТОРИНГ
- •НЕОБХОДИМОСТЬ РЕФАКТОРИНГА
- •SCRUM
- •С ЧЕГО ВСЕ НАЧИНАЛОСЬ
- •РОЛИ
- •Product Backlog — приоритезированный список
- •ПЛАНИРОВАНИЕ СПРИНТА
- •ПРОЦЕСС. ВСТРЕЧИ
- •SCRUM
- •СООТНОШЕНИЕ SCRUM VS RUP
- •ОБЩЕЕ СООТНОШЕНИЕ
- •ОСНОВНЫЕ КРИТЕРИИ КАЧЕСТВА ПО
- •ПРЕДСТАВЛЕНИЕ КАЧЕСТВА В СТАНДАРТЕ ISO 9126
- •КРИТЕРИИ КАЧЕСТВА ПО
- •ISO 9004:2000 Quality management systems — Guidelines for performance improvements
- •ХАРАКТЕРИСТИКИ И АТРИБУТЫ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПО ISO 9126
- •СТОИМОСТЬ КАЧЕСТВА
- •СТОИМОСТЬ КАЧЕСТВА
- •УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ
- •ТРЕБОВАНИЯ К ПО
- •ТЕСТИРОВАНИЕ ПО
- •СТАНДАРТЫ ТЕСТИРОВАНИЯ
- •ОРГАНИЗАЦИОННЫЕ ПРИНЦИПЫ УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ
- •ТЕСТОВЫЕ МЕТРИКИ
- •ТЕСТИРОВАНИЕ ПО
- •УРОВНИ ТЕСТИРОВАНИЯ
- •ТЕСТИРОВАНИЕ
- •ВИДЫ ТЕСТИРОВАНИЯ
- •ТИПЫ ДЕФЕКТОВ И СТАТИЧЕСКИЕ МЕТОДЫ ТЕСТИРОВАНИЯ (Майерс)
- •ВЫЯВЛЕНИЕ
- •ИЗВЕСТНЫЕ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ
- •Технологические основы языков программирования высокого уровня
- •ОБЪЕКТНЫЙ ПОДХОД...
- •ОБЪЕКТНЫЙ ПОДХОД
- •ПРИНЦИПЫ ОБЪЕКТНОГО
- •ТЕНДЕНЦИЯ ПОСЛЕДНЕГО ДЕСЯТИЛЕТИЯ
- •ИСТОРИЯ ПОДХОДОВ В ПРОГРАММИРОВАНИИ
- •СТРУКТУРА СТАНДАРТА UML
- •ЛЕГЕНДА О ВАВИЛОНСКОЙ
- •МОДЕЛИ UML
- •ДИАГРАММЫ UML
- •ПОНЯТИЯ UML
- •АКТЕРЫ И
- •СВЯЗЬ АКТЕРОВ И ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
- •ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
- •http://staruml.sourceforge.net/en/

1-й инкремент
Анализ
2-й инкремент
Анализ
3-й инкремент
Анализ
|
|
|
|
|
|
Поставка 1-го |
|
|
|
|
|
|
|
инкремента |
|
|
|
|
|
|
|
|
|
Проектир |
|
|
Кодиро- |
|
|
Тестиро- |
|
ование |
|
|
вание |
|
|
вание |
|
|
|
|
|
|
|
Поставка 2-го |
|
|
|
|
|
|
|
инкремента |
|
|
|
|
|
|
|
|
|
Проектир |
|
|
Кодиро- |
|
|
Тестиро- |
|
ование |
|
|
вание |
|
|
вание |
|
|
|
|
|
|
|||
|
|
|
|
|
|
Поставка 3-го |
|
|
|
|
|
|
|
инкремента |
|
|
|
|
|
|
|
|
|
Проектир |
|
|
Кодиро- |
|
|
Тестиро- |
|
ование |
|
|
вание |
|
|
вание |
|

«+»
не требуется заранее тратить средства, необходимые для разработки всего проекта
в результате выполнения каждого инкремента получается функциональный продукт
заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы
позволяет разбить возникшую проблему на управляемые части
существует возможность поддерживать постоянный прогресс в ходе выполнения проекта
снижаются затраты на первоначальную поставку программного продукта
ускоряется начальный график поставки |
25 |
|

снижается риск неудачи и изменения требований
заказчики могут распознавать важные возможности продукта на ранних этапах разработки
риск распределяется на несколько меньшие по размеру инкременты
требования стабилизируются на момент создания определенного инкремента
улучшается понимание требований для более поздних инкрементов
в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика
в процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработки команды не прекращали работу над проектом
возможность начать построение следующей версии проекта на переходном этапе предыдущей версии сглаживает изменения, вызванные сменой персонала

«--»
в модели не предусмотрены итерации в рамках каждого инкремента
определение полной функциональной системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов
формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом
общие затраты на выполнение проекта не будут снижены
поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах
для модели необходимы хорошее планирование и проектирование
может возникнуть тенденция к оттягиванию решений трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки

ИТЕРАЦИОННАЯ МОДЕЛЬ

СПИРАЛЬНАЯ МОДЕЛЬ
(Бари Боэм, 1988г.
Спиральная модель была предложена как альтернатива
каскадной модели, учитывающая повторяющийся характер разработки ПО
Основные принципы спиральной модели можно сформулировать следующим образом:
Разработка вариантов продукта, соответствующих
различным вариантам требований с возможностью вернуться к более ранним вариантам
Создание прототипов ПО для уточнения и выявления требований
Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту
Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится
неоправданно высок.

СПИРАЛЬНАЯ (ЭВОЛЮЦИОННАЯ) МОДЕЛЬ РАЗРАБОТКИ П
Программное обеспечение создается итерационно с использованием метода прототипирования.
Требования
установлены
Прототипом |
продукт, |
реализующий |
интерфейсы |
разра |
|
30

ОСОБЕННОСТИ СПИРАЛЬНОЙ МОДЕЛИ
Достоинством
Про моментов

V-МОДЕЛЬ ЖИЗНЕННОГО
ЦИКЛА
V-образная модель была разработана как разновидность каскадной модели
V-образная модель ЖЦ создана с целью помочь
работающей над проектом команде в планировании с
обеспечением дальнейшей возможности тестирования
системы. В этой модели особое значение придается действиям, направленным на верификацию и аттестацию
продукта

Планирование |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Производство, |
проекта и |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
эксплуатация |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
требований |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
и сопровождение |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Анализ требований |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Системное и |
продукта и |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
приемочное |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
спецификаций |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
тестирование |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Разработка |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Интеграция и |
архитектурного |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
продукта на высшем |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
тестирование |
уровне |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Детализованная |
|
|
|
|
|
|
|
|
|
|
|
|
|
Модульное |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
разработка |
|
|
|
|
|
|
|
|
|
|
|
|
|
тестирование |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Написание кода