Модели разработки

Модели разработки

Waterfall Model. Оценка

Advantages ?

Enforced discipline through documents

каждая фаза завершается документами, проверяемыми группой контроля качества

наглядность прогресса в разработке

каждая дорогостоящая фаза более прозрачна?

Testing is inherent in every phase

continuously as well as at end of phases

Disadvantages ?

Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Therefore, this model is only appropriate when the requirements are well- understood and changes will be fairly limited during the design process.

Few business systems have stable requirements

The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites

Модели разработки

Evolutionary development

Пробные разработки (Exploratory development)

Большую роль играет постоянная работа с заказчиком (или пользователями) для того, чтобы определить полную систему требований к ПО, необходимую для разработки конечной версии продукта. Вначале разрабатываются те части системы, которые очевидны или хорошо специфицированы. Система эволюционирует (дорабатывается) путем добавления новых средств по мере их предложения заказчиком.

Прототипирование (Throw-away prototyping)

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

внутренними противоречиями.

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

Модели разработки

Evolutionary development. Основные идеи

Модели разработки

Evolutionary development. Оценка

Problems

Многие этапы процесса создания ПО не документированы.

Менеджерам проекта создания ПО необходимо регулярно документально отслеживать выполнение работ. Но если система разрабатывается быстро, то

экономически не выгодно документировать каждую версию системы.

Система часто получается плохо структурированной. Постоянные

изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и

затратным.

Часто требуются специальные средства и технологии

разработки ПО. Это вызвано необходимостью быстрой разработки версий

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

уровня.

Applicability

For small or medium-size interactive systems;

For parts of large systems (e.g. the user interface);

For short-lifetime systems.

Итерационные модели разработки

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

Модель пошаговой разработки (Incremental), где процессы специфицирования требований, проектирования и написания кода разбиваются на последовательность небольших шагов, которые ведут к созданию ПО.

Спиральная модель разработки (Spiral), в которой весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали.

Модели разработки

Incremental Model. Основные идеи

Модели разработки

Incremental Model. Оценка

Advantages ?

Заказчик может оценить на самой ранней стадии самые важные компоненты, (так

как имеют наибольший приоритет).

Заказчик может использовать компоненты, полученные на первых шагах разработки, как прототипы для уточнения требований к тем компонентам, которые будут разрабатываться позднее.

Данный подход уменьшает риск общесистемных ошибок. Хотя в разработке отдельных

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

Наиболее важные сервисы тестируются наиболее полно. Поскольку системные сервисы с

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

Disadvantages ?

Сложно разбить систему на полезные, но небольшие компоненты

need an open architecture

too few builds build-and-fix

too many builds непроизводительные издержки

Модели разработки

Spiral Model. Основные идеи

Always some risk involved in software development

people leave… other products not delivered on time…

Ключевая идея

minimize risk

e.g., building prototypes & simulations minimizes risks

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

Перед каждой фазой:

looking at alternatives

risk analysis

В конце каждой фазы:

evaluation

planning of next phase