Техническое задание на разработку ис. Требования к видам обеспечения.

1.1. ТЗ является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) информационной системы (далее ИС), в соответствии с которым проводится разработка ИС и ее приемка при вводе в действие.

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

1.3. Требования к ИС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта информатизации. В этом случае ТЗ не разрабатывают.

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

1.5. В ТЗ включают только те требования, которые дополняют требования к системам данного вида и определяются спецификой конкретного объекта, для которого создается система.

1.6. Изменения к ТЗ оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на ИС. На титульном листе ТЗ должна быть запись “Действует с ... ”.

ТЗ содержит следующие разделы, которые могут быть разделены на подразделы:

• общие сведения;

• назначение и цели создания (развития) системы;

• характеристика объектов;

• требования к системе;

• состав и содержание работ по созданию системы;

• порядок контроля и приемки системы;

• требования к составу и содержанию работ по подготовке объекта разработки к вводу системы в действие;

• требования к документированию;

• источники разработки.

• В ТЗ могут включаться приложения.

Классическая модель жизненного цикла ис

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

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;

Проектирование;

Реализация;

Тестирование;

Внедрение;

Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем[3].