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

Внедрение разработанного проекта (блоки 7-10) начинается с опытного внедрения (блок 7), заключающегося в проверке работоспособности элементов и модулей проекта, устранении ошибок на уровне элементов и связей между ними.

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

Эксплуатация и сопровождение проекта (блоки 11-12). На этой стадии выполняются этапы: эксплуатация проекта системы и модернизация проекта ЭИС.

Другой характерной чертой жизненного цикла является наличие нескольких циклов внутри схемы:

§ первый цикл, включающий блоки 1-12 – это цикл первичного проектирования ЭИС;

§ второй цикл (блоки 7-8, 6-7) – цикл, который возникает после опытного внедрения, в результате которого выясняются частные ошибки в элементах проекта, исправляемые начиная с 6-го блока;

§ третий цикл (блоки 9-10, 4-9) возникает после сдачи в промышленную эксплуатацию, когда выявляются ошибки в функциональной архитектуре системы, связанные с несоответствием проекта требованиям заказчика, по составу функциональных подсистем, составу задач и связям между ними;

§ четвертый цикл (блоки 12, 5-12) возникает в том случае, когда требуется модификация системной архитектуры в связи с необходимостью адаптации проекта к новым условиям функционирования системы, т.е. новым требованиям;

§ пятый цикл (блоки 12, 1-12) возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы.

Чтобы исключить пятый цикл и максимально уменьшить необходимость выполнения третьего и четвертого циклов, необходимо выполнять проектирование ЭИС на всех этапах первого, основного цикла разработки ЭИС в соответствии с требованиями:

§ разработка ЭИС должна быть выполнена в строгом соответствии со сформулированными требованиями к создаваемой системе;

§ требования к ЭИС должны адекватно соответствовать целям и задачам эффективного функционирования экономического объекта;

§ созданная ЭИС должна соответствовать сформулированным требованиям на момент окончания внедрения, а не на момент начала разработки;

§ внедренная ЭИС должна развиваться и адаптироваться в соответствии с постоянно изменяющимися требованиями к ЭИС.

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

§ требования к функциональным характеристикам

§ требования к надежности

§ настраиваемость

§ условия эксплуатации

§ требования к информационной и программной совместимости

§ требования к документации

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

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

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

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

Требования к составу и параметрам технических средств. Указывается необходимый состав технических средств с указанием их основных технических характеристик. Могут указываться требования к помещениям, в которых будет находиться оборудование. В этом разделе указываются требования к переносимости системы.

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

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

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

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