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

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

Различают два подхода к реализации эволюционного метода разработки.

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

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

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

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

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

3. Часто требуются специальные средства и технологии разработки ПО.

6. Опишите функциональные и нефункциональные требования к системе

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

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

Функциональные требования для программных систем могут быть описаны разными способами.

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

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

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

Три группы нефункциональных требований:

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

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

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

7. Перечислите и опишите требования, предъявляемые к разрабатываемой программе

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

Этапу разработки требований предшествует анализ, спецификация (документирование требований) и проверка правильности.

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

Основные требования, предъявляемые к разрабатываемым программам

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

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

3) структура программы должна быть построена по модульному принципу и должна допускать модификацию программы.

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

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

2. При проведении самотестирования программа должна обеспечивать оценку результатов полученных в ходе тестирования.

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

4. Вопросы, входящие в состав блока тестов должны соответствовать объёму информации входящей в состав информационно - справочной обучающей системы.

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

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

7. Иметь удобный интерфейс - это специальным образом созданная оболочка (внешний вид программы), который позволит пользователю не запутаться, правильно вводить исходные данные и изменять их. Удобный интерфейс должен не только обладать свойством последовательного и правильного введения данных, но и гармонично подобранным набором цветов, зрительных образов и компонентов.