Эволюционная модель разработки

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

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

Согласно Орлову:

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

Спиральная модель – классический пример эволюционной стратегии конструирования.

3) Расположите в хронологическом порядке этапы процесса проектирования:

А) Проектирование интерфейсов

Б) Архитектурное проектирования

В) Обобщённая спецификация

Г) Проектирование алгоритмов

Д) Компонентное проектирование

Е) Проектирование структур данных

Б – В – А – Д – Е – Г, согласно, http://se.math.spbu.ru/seminars/se1/SE_4.htm#_4._Проектирование_и :

Ниже перечислены отдельные этапы процесса проектирования.

1. Архитектурное проектирование. Определяются и документируются подсистемы и
взаимосвязи между ними.

2. Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная
спецификация на ее сервисы и ограничения.

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

4. Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам.

5. Проектирование структур данных. Детально разрабатываются структуры данных, необходимые для реализации программной системы.

6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов.

4) Расположите в хронологическом порядке этапы процесса тестирования:

А) Тестирование компонентов

Б) Тестирование подсистем

В) Тестирование модулей

Г) Тестирование системы

Д) Приёмочные испытания

А – В – Б – Г – Д, согласно http://se.math.spbu.ru/seminars/se1/SE_4.htm#_5._Аттестация_программных :

Процесс тестирования состоит из нескольких этапов.

1. Тестирование компонентов. Тестируются отдельные компоненты для проверки правильности их функционирования. Каждый компонент тестируется независимо от других.

2. Тестирование модулей. Программный модуль — это совокупность зависимых компонентов, таких как описание класса объектов, декларирование абстрактных типов данных и набор процедур и функций. Каждый модуль тестируется независимо от других системных модулей.

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

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

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

5) Какие работы не должен выполнять менеджер проекта по разработке программного обеспечения?

А) Написание предложений по созданию ПО – менеджер тоже выполняет подобные работы

Б) Планирование и составление графика работ по созданию ПО

В) Тестирование модулей – для этого существует тестер

Г) Оценка стоимости проекта – должен выполнять менеджер

Д) Подбор персонала – отчасти выполняет менеджер

Е) Разработка требований к ПО – это дело разработчиков, заказчиков и пользователей, а менеджер только направляет

Вот то, что должен делать менеджер (взято с http://se.math.spbu.ru/seminars/se1/SE_3.htm#1 ):