Реферат: Внутрифирменная методология ведения проектов Дата

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

2 Обзор стандартов

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

2.1 Отечественные стандарты

2.1.1 ГОСТ 34.601-90 – Стадии создания АС

Вкратце, ЖЦП регламентируется следующим образом [6, 18]:

Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС.	2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе.
3. Техническое задание.	Разработка и утверждение технического задания на создание АС.
4. Эскизный проект.	4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части.
5. Технический проект.	5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. Рабочая документация.	6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ.
7. Ввод в действие.	7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний.
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание

Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

2.1.2 ГОСТ 34.602-89 – Техническое задание на создание АС

Приведем наиболее важные положения стандарта, а именно – раздел 2 «Состав и содержание» [полностью см. в 7].

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

1) общие сведения;

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

3) характеристика объектов автоматизации;

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

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

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

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

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

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

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

2.2. В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ. В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе «Общие сведения» указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

1) назначение системы;

2) цели создания системы.

2.4.1. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

2.5. В разделе «Характеристики объекта автоматизации» приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел «Требования к системе» состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида.

2.6.1. В подразделе «Требования к системе в целом» указывают:

требования к структуре и функционированию системы;

требования к численности и квалификации персонала системы и режиму его работы;

показатели назначения;

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

требования безопасности;

требования к эргономике и технической эстетике;

требования к транспортабельности для подвижных АС;

требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

требования к защите информации от несанкционированного доступа;

требования по сохранности информации при авариях;

требования к защите от влияния внешних воздействий;

требования к патентной чистоте;

требования по стандартизации и унификации;

дополнительные требования.

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;

2) требования к способам и средствам связи для информационного обмена между компонентами системы;

3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

6) перспективы развития, модернизации системы.

2.6.1.2. В требованиях к численности и квалификации персонала на АС приводят:

требования к численности персонала (пользователей) АС;

требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;

требуемый режим работы персонала АС.

2.6.1.3. В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы ее назначению.

Для АСУ указывают:

степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;

допустимые пределы модернизации и развития системы;

вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

2.6.1.4. В требования к надежности включают:

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

3) требования к надежности технических средств и программного обеспечения;

4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

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

2.6.1.7. Для подвижных АС в требования к транспортабельности включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:

1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;

2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;

3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;

4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;

5) требования к регламенту обслуживания.

2.6.1.9. В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

2.6.1.10. В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе.

2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят:

1) требования к радиоэлектронной защите средств АС;

2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

2.6.1.13. В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.

2.6.1.14. В дополнительные требования включают:

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

2) требования к сервисной аппаратуре, стендам для проверки элементов системы;

3) требования к системе, связанные с особыми условиями эксплуатации;

4) специальные требования по усмотрению разработчика или заказчика системы.

2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:

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

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

2) временной регламент реализации каждой функции, задачи (или комплекса задач);

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

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

2.6.3.1. Для математического обеспечения системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке.

2.6.3.2. Для информационного обеспечения системы приводят требования:

1) к составу, структуре и способам организации данных в системе;

2) к информационному обмену между компонентами системы;

3) к информационной совместимости со смежными системами;

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

5) по применению систем управления базами данных;

6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

7) к защите данных от разрушений при авариях и сбоях в электропитании системы;

8) к контролю, хранению, обновлению и восстановлению данных;

9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

2.6.3.3. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога.

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

1) к независимости программных средств от используемых СВТ и операционной среды;

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

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

2.6.3.5. Для технического обеспечения системы приводят требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

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

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

1) предварительный перечень измерительных каналов;

2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;

3) требования к метрологической совместимости технических средств системы;

4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;

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

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

2.6.3.7. Для организационного обеспечения приводят требования:

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

2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

3) к защите от ошибочных действий персонала системы.

2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.).

2.7. Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

В данном разделе также приводят:

1) перечень документов, по ГОСТ 34.201-89, предъявляемых по окончании соответствующих стадий и этапов работ;

2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);

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

2.8. В разделе «Порядок контроля и приемки системы» указывают:

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

З) статус приемочной комиссии (государственная, межведомственная, ведомственная).

2.9. В разделе «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие.

В перечень основных мероприятий включают:

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

2) изменения, которые необходимо осуществить в объекте автоматизации;

3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

4) создание необходимых для функционирования системы подразделений и служб;

5) сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят:

изменения применяемых методов управления;

создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

2.10. В разделе «Требования к документированию» приводят:

1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика;

перечень документов, выпускаемых на машинных носителях;

требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

2.11. В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

1) расчет ожидаемой эффективности системы;

2) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

2.1.3 ГОСТ 34.602-89 – Виды испытаний АС

Приведем наиболее важные положения стандарта [полностью см. в 8].

1.3. Для АС устанавливают следующие основные виды испытаний:

1) предварительные (автономные и комплексные);

2) опытная эксплуатация;

3) приемочные.

Примечания:

1. Допускается дополнительно проведение других видов испытаний АС и их частей.

3. Виды испытаний и статус приемочной комиссии устанавливают в договоре и (или) ТЗ.

1.4. В зависимости от взаимосвязей испытываемых в АС объектов испытания могут быть автономные или комплексные.

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

Комплексные испытания проводят для групп, взаимосвязанных частей АС или для АС в целом.

1.5. Для планирования проведения всех видов испытаний разрабатывают документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ.

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

1.7. Программа и методика испытаний может разрабатываться на AC в целом, на части АС. В качестве приложения могут включаться тесты (контрольные примеры).

1.8. Предварительные испытания АС проводят для определения ее работоспособности и решения вопроса о возможности приемки AC в опытную эксплуатацию.

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

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

1.11. Приемочные испытания АС проводят для определения. соответствия АС техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки АС в постоянную эксплуатацию.

1.12. Приемочным испытаниям АС должна предшествовать ее опытная эксплуатация на объекте.

2.1.4 ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании АС

2.1.5 ГОСТ 19.101-77. Виды программ и программных документов

Приведем наиболее важные положения стандарта (полностью см. в [10]).

К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. Виды программных документов и их содержание:

· Спецификация - состав программы и документации на нее.

· Ведомость держателей подлинников - перечень предприятий, на которых хранят подлинники программных документов.

· Текст программы - запись программы с необходимыми комментариями.

· Описание программы - сведения о логической структуре и функционировании программы.

· Программа и методика испытаний - требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля.

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

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

· Эксплуатационные документы - сведения для обеспечения функционирования и эксплуатации программы. Содержат:

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

2.2 Международные стандарты

2.2.1 IEEE Std 830-1993 – спецификации требований

IEEE Std 830-1993 - IEEE Recommended Practice for Software Requirements Specifications (ANSI). «Рекомендации по разработке спецификаций требований программного обеспечения ».

Стандарт IEEE 830 является признанным разработчиками как не только формально обязательный, но и практически полезный при разработке спецификаций (близко к ТЗ).

Кратко основные полезные моменты стандарта.

1. Определены ключевые требования «хорошей спецификации»:

· Unambiguous (недвусмысленность) - отсутствие лексических, синтаксических и семантических ошибок.

· Complete (полнота) - должны быть описаны все значимые области требований.

· Verifiable (проверяемость) - должны содержаться только те требования, которые могут быть численно измерены.

· Consistent (целостность) -не должно быть конфликтов требований.

· Modifiable (модифицируемость)- спек должен быть легким в использовании и организации ссылок между требованиями.

· Traceable (трассируемость)- спек должен позволять пошагово отслеживать (трассировать) от требований до предудущих принятых решений, от документов расширяющих спек (проектировка и т.д.) к требованиям спека.

· Usable (возможность применения)- спек должен без излишних деталей описывать весь жизненный цикл системы.

2. Определено прототипирование как метод разработки требований к системе.

3. Даны образцы структуры спеков.

Заметим, отсутствует описание спека от понятия use case, широко применяемого в UML. Близкое по смыслу описание дается от понятия stimulus (отписание от проблем и задач пользователя).

2.2.2 IEEE Std 1074-1991 – процессы ЖЦ ПО

IEEE Std 1074-1991 - IEEE Standard for Developing Software Life Cycle Processes (ANSI). «Процессы жизненного цикла для развития программного обеспечения ». Описывает этапы жизненного цикла программного обеспечения и соответствующие входы [и выходы, т.е. отчетные документы] для каждого этапа.

На данный момент самой новой версией стандарта является IEEE Std 1074.1-1995.

Стандарт охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов. Эти процессы детализируются 16 частными процессами. В последних имеется еще более мелкая детализация в совокупности на 65 процессов-работ.

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

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

Хотя основные процессы близки к описанным в стандарте ISO 12207, общая архитектура и детализация частных процессов и работ в данном стандарте значительно отличается. Процессы непосредственного создания ПС и его поддержки в стандарте представлены наибольшим числом частных процессов (около 70%), начинающимся с разработки требований к ПС и завершающимся приемо-сдаточными испытаниями, проводимыми заказчиком или пользователем.

2.2.3 ISO 12207:1995 - процессы ЖЦ ПО

ISO 12207:1995 – ISO Standard for Software life cycle processes [см. 13, 18].

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важное замечание стандарта: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)

В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

В стандарте рассматриваются следующие этапы:

Анализ.
Проектирование.
Реализация.
Внедрение.
Сопровождение.

Стандарт регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

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

В стандарте расшифровано свыше 220 работ и комментариев к ним. Стандарт состоит из 7 разделов и 4 приложений.

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

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

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

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

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

б) внешние связи (интерфейсы) с единицей программного обеспечения;

в) требования квалификации;

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

д) спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;

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

ж) определение данных и требований базы данных;

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

и) документация пользователя;

к) работа пользователя и требования выполнения;

л) требования сервиса пользователя.

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

2.2.3.1 Вводные разделы (1-4)

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

2.2.3.2 Раздел 5

Основные этапы подготовки, эксплуатации и сопровождения ПС изложены в пятом разделе:

Приобретение или подготовка к созданию ПС (подраздел 5.1) включает 23 вида работ и начинается с инициализации проекта, анализа концепции и рынка аналогичных продуктов, выработки требований и состава поддерживающих документов, создания предварительного плана действий. Далее анализируются предложения возможных исполнителей и подготавливается проект контракта. Организуется отслеживание проекта, его приемка и завершение.
В подразделе 5.2. детализируются 23 процесса организации последующей подготовки к поставке ПС . Оцениваются отзывы фирм о проекте, заключается контракт, планируется ЖЦ, организуются поддержка разработки отчетами и обеспечение развития, а также процессы сдачи и завершения проекта.
Основные 55 работ по созданию сложного комплекса программ представлены в подразделе 5.3. Подготовка проекта начинается с определения состава сопровождающих документов, выбора средств конфигурационного управления и обеспечения качества, а также выбора методов и средств технологического обеспечения всей ИС. Анализируются и формализуются функциональные, коммерческие, пользовательские, системные требования и критерии качества ПС: защищенность, интерфейсы с внешней средой, сопровождаемость и т. д. На этой базе проектируется архитектура всей ИС, выделяются и анализируются требования к программным средствам. При формировании характеристик качества ПС рекомендуется руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Все эти работы отражаются в документах, на каждый компонент проекта отслеживается их взаимодействие и связи с внешней средой в ИС:

Кодирование и тестирование каждого компонента ПС должно быть оформлено комплексом документов, удостоверяющих соответствие первичной спецификации, содержащих тесты и результаты тестирования.
Для интеграции компонентов рекомендуется подготавливать план работ, включающий их комплексирование, тестирование по всем требованиям и показателям качества, а также документирование плана, результатов интеграции, использованных тестов, критериев оценки и полученных результатов.
Затем ПС необходимо подвергнуть квалификационному (аттестационному) тестированию по всем разделам требований, при широком варьировании тестов и значений критериев, а также протестировать адекватность программам и полноту технической и пользовательской документации.
Проверенный таким образом комплекс программ интегрируется с вычислительными средствами ИС, средствами визуализации и телекоммуникации.
После объединения всех средств ИС система подвергается квалификационному тестированию и испытаниям на всю совокупность требований к системе, а также производится оформление и проверка полного комплекта документации. При этом рекомендуется использовать методы и средства поддержки ЖЦ ПС, изложенные в шестом разделе.
Далее следует создать план установки программного продукта в соответствии с контрактом и производить инсталляции, результаты которых документируются. Должна быть обеспечена поддержка разработчиком поставки ПС.

Подраздел 5.4 состоит из 9 работ и посвящен поддержке эксплуатации . Подготовленный оператор должен освоить все процедуры применения ИС, в том числе тестирования ПС на соответствие критериям оперативного использования, указанным в документации. Поддержка пользователей подразумевает оказание помощи и консультационных услуг при обнаружении дефектов или ошибок при применении ПС в составе информационной системы. Эти работы взаимодействуют с описанными в подразделе 5.5, обеспечивающими сопровождение ПС (24 работы). Предполагается, что сопровождение может выполняться другими специалистами, не теми, кто создавал ПС на предыдущих этапах. Они анализируют сообщения об ошибках и предложения о модификации ПС, селектируют их на соответствие требованиям контракта и оценивают целесообразность проведения изменений. Подготовленные изменения тестируют и проверяют по критериям, определенным в документации. При подтверждении необходимости изменений в программах производится корректировка документации. Далее планируется распространение внесенных изменений или новой версии пользователям, которым была поставлена предшествующая версия. Рекомендуется учитывать возможность одновременного использования клиентами версий ПС с разным составом проведенных модификаций. Некоторые версии с определенной совокупностью изменений планируются для ликвидации.

2.2.3.3 Раздел 6

В разделе 6 представлено около 70 технологических работ, поддерживающих ЖЦ ПС:

Процессы документирования ПС (6.1) охватывают планирование и регламентирование документирования, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комплекта документации на ПС.
Конфигурационное управление (6.2) включает план реализации версий как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации.
Обеспечение гарантий качества (6.3) включает использование планирования, методологии, процедур и стандартов качества в соответствии с контрактом и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в процессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001 (для сравнения см. п. 2.4.4).
Верификация ПС (6.4) включает организацию, планирование и техническое обеспечение. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов.
Валидация (6.5) - удостоверение правильности (аттестация ) - должна гарантировать полное соответствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее выполнение независимыми специалистами путем тестирования во всех возможных ситуациях исходных данных. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается.
Управление проектом (6.6) подразумевает в основном подготовку и обеспечение планирования и управления ресурсами, персоналом, аппаратурой, программными средствами и инструментарием. Общий контроль проекта должен учитывать состояние доступных ресурсов и возможность изменения плана проектирования, а также систематические технические отчеты.
Процессы ревизии - аудит (6.7) - служат для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Ревизоры должны быть независимыми от проектировщиков ПС, они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования.
В процессе устранения дефектов и ошибок (6.8) решаются проблемы обеспечения последующего применения ПС и их функционирования. Каждый дефект или ошибка должны быть определены, идентифицированы, описаны, проанализированы и исправлены в процессе сопровождения в соответствии с контрактом.

2.2.3.4 Раздел 7

Раздел 7 посвящен процессам организации ЖЦ ПС (25 работ):

Процессы управления (7.1) включают основные работы по управлению проектом, производством и средствами для обеспечения прикладных процессов по созданию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение.
Процессы образования инфраструктуры (7.2) включают выбор и установление аппаратных и программных средств, технологии, стандартов и способов обслуживания, используемых для разработки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к проекту и подлежит конфигурационному управлению.
Совершенствование ЖЦ ПС (7.3) подразумевает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии.
Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходимые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответствующему плану.

2.2.3.5 Приложения

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

Приложение В (информационное) содержит руководство по процессам адаптации и преобразования ЖЦ ПС для конкретного проекта, а также рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта.

2.3 Методологии зарубежных фирм

2.3.1 Методология DATARUN

Одной из наиболее распространенных в мире электронных методологий является методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию [13].

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

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

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

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

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

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

Методология DATARUN опирается на две модели или на два представления:

модель организации;
модель ИС.

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

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

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

Подход DATARUN преследует две цели:

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

Объекты, формируемые на основании модели данных, являются объектами базы данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты интерфейса, определенные в архитектуре компьютерной системы, обычно размещаются на клиентской части. Модель данных, являющаяся основой для спецификации совместно используемых объектов базы данных и различных объектов интерфейса, обеспечивает сопровождаемость ИС.

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

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

Модели, создаваемые с помощью подхода DATARUN:

BPM (B usiness P rocess M odel) - модель бизнес-процессов.
PDS (P rimary D ata S tructure) - структура первичных данных [потоков между БП].
CDM (C onceptual D ata M odel) - концептуальная модель данных [логическая ERD].
ISA (I nformation S ystem A rchitecture) - архитектура информационной системы [подсистемы, их функции и данные].
ADM (A pplication D ata M odel) - модель данных приложения [физическая ERD].
SPM (S ystem P rocess M odel) - модель процессов системы [~ спецификация на программирование приложений, модулей, функций].
IPM (I nterface P resentation M odel) - модель представления интерфейса.
ISM (I nterface S pecification M odel) - модель спецификации интерфейса.

BPM

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

PDS

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

CDM

На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных (ER-модель). От структур первичных данных концептуальная модель отличается удалением избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной системы. Цель концептуальной модели данных - описать используемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализованном виде.

ISA

На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура ИС. Определяются входящие в систему приложения, для каждого приложения специфицируются используемые данные и реализуемые функции. Архитектура ИС создается в модуле Silverrun BPM с использованием специальной нотации ISA. Основное содержание этой модели - структурные компоненты системы и навигация между ними. Концептуальная модель данных разбивается на части, соответствующие входящим в состав системы приложениям.

ADM

Перед разработкой приложений должна быть спроектирована структура корпоративной базы данных. DATARUN предполагает использование базы данных, основанной на реляционной модели. Концептуальная модель данных после нормализации переносится в модуль реляционного моделирования Silverrun RDM с помощью специального моста ERX-RDM. Преобразование модели из формата ERX в формат RDM происходит автоматически без вмешательства пользователя. После преобразования форматов получается модель реляционной базы данных . Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений ссылочной целостности). Правила обработки данных можно задавать как непосредственно на языке программирования СУБД, так и в декларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным СУБД переводят эти декларативные правила на язык требуемой системы, что снижает трудоемкость программирования процедур сервера базы данных, а также позволяет из одной спецификации генерировать приложения для разных СУБД.

SPM

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

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

IPM

Модель представления интерфейса - это описание внешнего вида интерфейса, как его видит конечный пользователь системы. Это может быть как документ, показывающий внешний вид экрана или структуру отчета, так и сам экран (отчет), созданный с помощью одного из средств визуальной разработки приложений - так называемых языков четвертого поколения (4GL - Fourth Generation Languages). Так как большинство языков 4GL позволяют быстро создавать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования.

ISM

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

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

2.3.2 Методология Oracle CDM/PJM

Oracle CDM/PJM – метод сквозного создания и внедрения информационных систем с использованием Oracle Designer. Полная методология CDM изложена в отдельном документе и находится в архиве фирмы. В этом разделе приводятся наиболее важные ее моменты [см. также 18].

Oracle Custom Development Method (CDM ) — составная часть глобальной методологии разработки ИС — Oracle Method. Кроме CDM в Oracle Method входят метод разработки хранилищ данных (DWM ), метод внедрения готовых приложений (Aim ), метод управления проектом (PJM ) и ряд других.

Поскольку решаемые в CDM задачи тесно связаны и переплетены с задачами руководителя проекта, то CDM наиболее сильно связан с методикой Oracle PJM по организации управления разработкой проекта. Цель PJM (Project Metod) – определить структуру, в рамках которой проекты в области информационных технологий можно было бы согласованно планировать, оценивать, контролировать и завершать.

Этапы классического подхода в CDM:

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

Процессы в CDM (в скобках – условные коды):

Постановка задачи или Определение производственных требований (RD).
Исследование существующих систем (ES).
Определение технической архитектуры (TA).
Проектирование и построение БД (DB).
Проектирование и реализация модулей (MD).
Преобразование (конвертирование) данных (CV).
Документирование (DO).
Тестирование (TE).
Обучение (TR).
Внедрение или Переход к новой системе (TS).
Поддержка и сопровождение (PS).

2.3.3 Методология RUP

По методологии Rational unified process ( RUP) фирмы Rational Rose жизненный цикл системы состоит из следующих этапов:

Основные потоки работ процесса:

Деловое моделирование или Моделирование процессов предметной области.
Выработка требований .
Анализ и проектирование .
Выполнение или Кодирование (реализация программного кода).
Испытание или Тестирование.
Развертывание или Установка ПО.

Основные потоки работ поддержки:

Управление конфигурацией и изменениями.
Управление проектом.
Управление средой.

2.3.4 Методология фирмы SoftServe

Фирма SoftServe Inc. (Virginia, U.S.) осуществляет консалтинговые услуги на всех этапах жизненного цикла разработки ПО, который, по ее представлению, состоит в следующем:

Планирование (Planning):

Планирование информационных ресурсов (Information Resource Planning).
Планирование обмена данными (Electronic Data Interchange Planning).
Планирование внедрения (Implementation Planning).

Проектирование и разработка (Design and Development):

Системный анализ, проектирование и разработка (System analysis, design and development)
Определение технических требований к аппаратному и программному обеспечению (Hardware/Software selection).
Проектирование базы данных (Database Design).
Проектирование программной архитектуры (System Integration Design).
Проектирование пользовательского интерфейса (User-Interface Design).

Внедрение (Implementation):

Тестирование системы (System Testing).
Обучение и тренинг пользователей (Training and Education courses).
Выпуск документации (System and User Documentation).

Поддержка (Support):

Наблюдение за работой системы (System audits).
Техническое сопровождение (On-going technical support).
Пересмотр методов управления и обеспечения безопасности (Control and Security review).
Управление потоком данных (Data processing management).

2.4 Другие международные стандарты

2.4.1 Список международных стандартов

В целом, при проектировании систем используются следующие международные стандарты IEEE и ISO [1,2]:

ASTM 1340-90 - Standard Guide for Rapid Prototyping of Computerized Systems.
IEEE Std 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology (ANSI).
IEEE Std 730-1989 - IEEE Standard for Software Quality Assurance Plans (ANSI).
IEEE Std 828-1990 - IEEE Standard for Software Configuration Management Plans (ANSI).
IEEE Std 830-1993 - IEEE Recommended Practice for Software Requirements Specifications (ANSI). Рекомендации по разработке спецификаций требований программного обеспечения (см. п. 2.1.2).
IEEE Std 982.1-1988 - IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
IEEE Std 982.2-1988 - IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
(ANSI/)IEEE Std 983-1986 - IEEE Guide to Software Quality Assurance Planning.
IEEE Std 1002-1987 - IEEE Standard Taxonomy for Software Engineering Standards (ANSI).
(ANSI/)IEEE Std 1012-1986 - IEEE Standard for Software Verification and Validation Plans (ANSI).
IEEE Std 1016-1987 - IEEE Recommended Practice for Software Design Descriptions (ANSI).
IEEE Std 1028-1988 - IEEE Standard for Software Reviews and Audits (ANSI).
(ANSI/)IEEE Std 1042-1987 - IEEE Guide to Software Configuration Management (ANSI).
IEEE Std 1058.1-1987 - IEEE Standard for Project Management Plans (ANSI).
IEEE Std 1074-1991[1995?] - IEEE Standard for Developing Software Life Cycle Processes (ANSI) (см. п. 2.2.2).
IEEE P1233, October 1993 - Draft Guide to Developing System Requirements Specifications.
ANSI/IEEE 829-1983 Standard for Software Test Documentation.
ANSI/IEEE 1008-1986 Standard for Software Unit Testing.
IEEE 1063-1987 (confirmed 1993) - Standard for Software User Documentation.
ISO 9000-3:1991 - Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software (см. п. 2.4.4).
ISO 9126:1991 - Quality characteristics and guidelines for their use.
ISO 12119:1994 - Quality requirements and testing.
ISO 6592:2000 - Guidelines for the documentation of computer-based application systems.
ISO 9294-1990-TO - Guidelines for the management of software documentation.
ISO 9127:1988 - User documentation and cover information for consumer software packages.

2.4.2 Стандарт IEEE Std 830-1993 (Спецификация требований к ПО)

Стандарт IEEE Std 830-1993 описывается как «IEEE Recommended Practice for Software Requirements Specifications (ANSI)», т.е. Рекомендации по разработке спецификаций требований программного обеспечения (далее - СТПО).

Фактически, этот стандарт аналогичен Техническому заданию, потому что определяет форму описания и состав требований главных разделов ТЗ (1-3) в соответствии с отечественным стандартом ГОСТ 34.602-89 [2.1.2].

Приведем необходимые части СТПО в соответствии с этим стандартом:

Оглавление .
Раздел 1. Введение :

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

Раздел 2. Общее описание :

Описание изделия (взаимосвязь с другими системами):

Интерфейсы системы.
Интерфейсы пользователя.
Интерфейсы аппаратных средств ЭВМ.
Интерфейсы программного обеспечения.
Интерфейсы коммуникаций (средств связи типа протоколов локальной сети и т.д.).
Ограничения памяти.
Функционирование (иногда является частью раздела Интерфейса пользователя) - определение нормальных и специальных действий типа:

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

Требования настройки рабочих мест.

Функции изделия (сгруппированные и с диаграммами).
Характеристики пользователя.
Ограничения - факторы, ограничивающие выбор разработчика, например:

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

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

Раздел 3. Детальные требования :

Внешние интерфейсы - детальное описание всех входов и выходов системы программного обеспечения (дополнением к описанию интерфейса в Разделе 2), включает:

Наименование пункта.
Описание цели.
Источник входных или назначение выходных данных.
Диапазон допустимых значений, точность и/или допустимые отклонения.
Единицы измерения.
Временные характеристики.
Отношения к другим входам / выходам.
Форматы / организация экрана.
Форматы / организация окна.
Форматы данных.
Форматы команд.
Конечные сообщения.

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

Соглашение о стандартах.

Характеристики программного обеспечения системы.

Надежность.
Эксплуатационная готовность.
Безопасность.
Ремонтопригодность.
Переносимость.

Структурирование детальных требований.

Режим системы.
Классы пользователей.
Объекты.
Особенности.
Воздействие.
Реакция.
Функциональные иерархии.

Дополнительные комментарии.

Это - часто самая большая и наиболее важная часть СТПО, поэтому необходимо применять следующие принципы:

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

Приложения .
Индексы .

2.4.3 Стандарт на Глоссарий

Глоссарий используется лишь как приложение к Спецификации требований к ПО (СТПО). Определения терминов – четкие и краткие, без «энциклопедических» обзоров. Назначение Глоссария – однозначность трактовок терминов, используемых в СТПО.

2.4.4 Стандарт ISO 9000-3:1991 (Обеспечение качества )

Технология обеспечения качества в ЖЦ ПС представлена в стандарте ISO 9000-3:1991. Руководящие указания предназначены для унификации описания методов разработки и поставки ПС, а также способов контроля их качества, отвечающих требованиям заказчика. Этой унификации предлагается добиваться, предотвращая отклонения от стандарта на всех этапах ЖЦ - от начала разработки до технического обслуживания и ремонта. Предполагается, что в контракте будут особо оговорены важнейшие компоненты технологии проектирования и требования к техническим характеристикам ПС, иначе это делается в процессе разработки. Поставщик должен документально оформить цели, технологию и свои обязательства по обеспечению качества ПС. Необходимо определить ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество, надежность и безопасность применения создаваемого комплекса программ. Обеспечение и проверка качества проводится персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ и создание изделий. Покупатель-заказчик назначает своего представителя, ответственного за сотрудничество с поставщиком в процессе создания ПС по данному контракту.

В стандарте определена структура системы обеспечения качества и ее функции в жизненном цикле ПС. Эта деятельность предусматривает:

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

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

формализации состава, содержания и процессам утверждения документации;
управлению конфигурацией версий ПС и проведению изменений в программах и данных.

3 Внутрифирменные методологии

3.1 Опыт аналитиков фирмы

В целом, рекомендуется следующая последовательность этапов:

Обследование.
Разработка Спецификаций технических требований (и, если есть время, - Концепции проектируемой системы).
Утверждение Технического задания.
Системное проектирование (разработка ERD, Спецификации на программирование и пр.).
Программирование (кодирование и генерация БД).
Наполнение и тестирование.
Документирование.
Внедрение.
Сопровождение.

3.2 Используемые стандарты и документы

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

ГОСТ 34.602-89 (Техническое задание) [см. 2.1.2].
IEEE Std 830-1993 (Спецификация требований к ПО) [см. 2.4.2].
ISO 12207:1995 (ЖЦПО) [см. п. 2.2.3].
DATARUN (ЖЦПО) [см. п. 2.3.1].
ORACLE CDM (ЖЦПО) [см. п. 2.3.2].
RUP (ЖЦПО) [см. п. 2.3.3].

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

Денис Королев. Инновационный цикл в разработке проектов [3].
С.С.Гайсарян. Объектно-ориентированные технологии проектирования прикладных программных систем [4].
Владимир Липаев. Стандарты, регламентирующие жизненный цикл сложных программных комплексов [5].
Проект создания ПО (фирма «Архивные Системы») [14].
Предпроектное исследование задачи (фирма «Интегро», г. Уфа) [13].
Жизненный цикл разработки ПО [14].
Руководство по управлению внедренческими проектами на базе MS Project 2000 и рекомендаций PMI [15].

3.3 Методология разработки новой системы

Под разработкой новой системы понимается весь процесс создания информационной системы от системного обследования до внедрения. Этот процесс включает следующие этапы (по международному стандарту ISO 12207:1995):

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

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

3.3.1 Стратегия

3.3.1.1 Назначение и особенности

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

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

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

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

3.3.1.2 Выходные документы

Во время и по окончании этапа Стратегии разрабатываются следующие документы:

«Описание общих требований » [3.5.5]. Основной целью документа является формирование границ проекта, т.е. выявление и описание общих требований.
Предварительная версия «Календарного плана работ ». В этом документе четко оценивается трудоемкость, продолжительность и сроки этапа Анализа и ориентировочно – по остальным этапам.
Предварительная версия «Сметы ». В этом документе четко оцениваются затраты и общая стоимость работ на этапе Анализа и ориентировочно – по остальным этапам (на основании оценки трудоемкости, приведенном в «Календарном плане работ »).
«Договор о проведении обследования » - договор на выполнение бизнес-обследования предметной области [3.5.2].
«Соглашение о конфиденциальности » - соглашение о неразглашении конфиденциальной информации, полученной при обследовании предприятия (составляется по инициативе Заказчика) [3.5.3].

3.3.1.3 Трудоемкость и состав исполнителей

Этап носит непродолжительный характер (около 2 недель) и минимальное количество участвующих лиц (кроме руководителей и главных бухгалтеров – по 1-3 экспертов с обеих сторон).

3.3.2 Анализ

3.3.2.1 Назначение и особенности

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

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

3.3.2.2 Состав этапа (подэтапы)

При этом, в первую очередь, проводится анализ следующих аспектов (в скобках – условные коды подэтапов):

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

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

Далее (или одновременно) исследуется целесообразность использования какой-либо существующей информационной системы или разработки новой. При этом осуществляются и документируются (в виде разделов «Концепции » или отдельных документов) следующие подэтапы:

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

Затем уточняются системные требования, и на их основе определяются стратегические направления будущих работ. При этом проводятся и документируются (в виде разделов «Концепции » или отдельных документов) следующие подэтапы:

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

3.3.2.3 Выходные документы

Таким образом, на этапе Анализа разрабатываются следующие выходные документы:

«Модель предметной области » [3.6.2] с прилагаемыми протоколами интервью [3.6.1].
«Концепция системы » [3.6.3].
«Техническое задание » - как приложение к Договору или отдельный документ [3.5.1]. Составляется на основе предшествующего (разработанного на этапе Стратегии) документа «Описание общих требований » и раздела «Уточненные требования к системе» документа «Концепция ».
«Календарный план работ » - как приложение к Договору или к ТЗ.
«Смета » - как приложение к Договору или к ТЗ.
«Договор » - договор на выполняемые работы: на проектирование, разработку, развитие, внедрение системы и т.п. В договоре определяется состав и содержание результирующих документов.

3.3.2.4 Трудоемкость и состав исполнителей

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

Работы на этом этапе рекомендуется выполнять группе аналитиков – специалистов по исследуемой предметной области, по информационным технологиям, которые предполагается использовать в проекте, по методологиям обследования и проектирования (3-6 человек, при ограниченных сроках - больше).

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

3.3.3.1 Назначение и особенности

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

3.3.3.2 Состав этапа (подэтапы)

3.3.3.3 Выходные документы

На этом этапе разрабатываются следующие модели и методики:

«Модель данных » или «Информационная модель ». Документ содержит:

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

«Методики информационного наполнения » - методики сбора и обработки исходных данных (для тестирования и внедрения). Документ разрабатывается вслед за Моделью данных.
«(Программная) архитектура » или «Функциональная модель » - описание компонентов системы, их группировки и взаимосвязей.
«Модель представления интерфейса » - описание структуры экранных форм и отчетов, бизнес-логики процедур преобразования входных и выходных данных.
«Модель процессов » - описание работы системы и с системой на этапах внедрения и эксплуатации, сопровождаемое диаграммами DFD или UML.
«Спецификация на программирование » - описание входных и выходных параметров, обработки исключительных ситуаций модулями и функциями системы.
«Методики функционального наполнения » или «Встраивание в бизнес-процессы » - варианты планов дальнейшего расширения функциональных возможностей системы, описание перспектив ее развития.
«Технические требования » - требования к аппаратной части и программному окружению серверов и рабочих мест. Предназначено для тестировщиков и клиентов (в первую очередь – администраторам системы).

3.3.3.4 Трудоемкость и состав исполнителей

3.3.4 Реализация

3.3.4.1 Назначение и особенности

Назначением этапа является создание БД, кодирование, тестирование и документирование разработанной системы.

3.3.4.2 Состав этапа (подэтапы)

1. Разработка модулей системы в соответствии с требованиями ТЗ и проекта.

2. Разработка тестов.

3. Подготовка тестовой БД (заполнение системы минимально необходимым для стендовых испытаний набором данных).

4. Стендовое тестирование и доработка.

5. Опытная эксплуатация («пилотное» внедрение системы на реальном предприятии).

3.3.4.3 Выходные документы

Выходные документы:

Новая техническая документация на модифицированные серверную и клиентскую части системы, новые подсистемы:

Описание системы.
Руководство пользователя.
Руководство администратора.

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

3.3.4.4 Трудоемкость и состав исполнителей

3.3.5 Внедрение

3.3.5.1 Назначение и особенности

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

3.3.5.2 Состав этапа (подэтапы)

1. Сбор данных.

2. Создание справочников, классификаторов, кодификаторов.

3. Наполнение БД системы производственными и др. (например, географическими) данными.

4. Конфигурирование системы для решения задач предметной области (встраивание в бизнес-процессы).

3.3.5.3 Выходные документы

Выходные документы:

Отчет о наполнении системы данными.
Отчет о соответствии работы системы требованиям ТЗ.

3.3.5.4 Трудоемкость и состав исполнителей

3.3.6 Сопровождение и развитие

3.3.6.1 Назначение и особенности

Назначение этапа состоит в сопровождении промышленной эксплуатации системы (абонентском обслуживании), главным образом в устранении проблем при эксплуатации системы и ее развитие включает в себя следующие основные работы:

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

3.3.6.2 Исполнительные документы

Выходные документы:

Договор на абонентское обслуживание.
Журнал регистрации консультаций.
Журнал регистрации и устранения ошибок.
Журнал регистрации доработок и тиражирования обновленных релизов (с указанием инициаторов доработок).
Технические задания на доработку системы (в рамках абонентского обслуживания).

3.3.6.3 Трудоемкость и состав исполнителей

3.3.7 Развитие

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

Фактически, этот этап является итерацией ЖЦ системы с какого-либо этапа (в основном – с этапа ее проектирования, а иногда даже обследования), в то время как доработка системы в рамках абонентского обслуживания – в основном, итерация с этапа ее реализации.

3.3.8 Оценка сроков работ

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

По поводу распределения времени в проекте Брукс в своей книге «Мифический человеко-месяц» приводит следующие эмпирические данные для этапов разработки информационных систем:

1/3 – планирование (этапы Стратегии, Анализа и Проектирования).
1/6 - написание программ (начало этапа Реализации).
1/4 - тестирование компонентов и предварительное системное тестирование (завершение этапа Реализации).
1/4 - системное тестирование при наличии всех компонентов (завершение этапа Реализации).

Таким образом, этап Реализации занимает 2/3 времени ЖЦ ПО, причем работы по тестированию – 50% времени ЖЦ ПО.

Далее, условно будем считать, что:

Малые проекты: несложные АРМ (типа «Кадры»).
Средние проекты, например:

сложные АРМ (например, «Бухгалтерия», «Операционный день банка»);
АСУ (например, системы диспетчеризации);
ГИС;
САПР;
системы паспортизации;
контроля исполнения договоров и т.д.

Крупные проекты: проект масштаба всего предприятия (ERP-система) и т.д.

Для среднего проекта оценка трудоемкости выглядит следующим образом:

Стратегия: 1-2 недели.
Анализ (бизнес-обследование): от 4 месяцев.
Проектирование: от 4 месяцев.
Реализация (кодирование и тестирование) – не менее 7 месяцев.
Внедрение и обучение– от 1 недели до 1 месяца (с полным вводом данных) в 1 филиале.

Итого, на анализ предметной области, проектирование и реализацию среднего проекта необходимо не менее 15 месяцев.

Приведем более детальную схему работ по указанным этапам.

Стратегия – 1-2 недели:

Разработка предварительной версии «Технического задания » - 4-7 дней.
Разработка предварительной версии «Календарного плана » (в документе точно оцениваются только работы на этапе Анализа) – 1 день.
Разработка предварительной версии «Сметы » (в документе точно оцениваются только работы на этапе Анализа) – 1-3 дня.
Согласование и утверждение «Договора о проведении обследования » (для этапа Анализа) – 1-3 дня.
Согласование и утверждение «Соглашения о конфиденциальности » – 1-2 дня.

Анализ – 4-6 месяцев:

Интервьюирование экспертов, протоколирование интервью и утверждение протоколов – от 3 недель (на каждого эксперта 2-3 дня, всего интервьюируется не менее 10 экспертов).
Разработка Модели предметной области – 9-10 недель:

Обзор предметной области – 2 недели.
Организационная структура предприятия – 1-2 дня.
Эксплуатируемые информационные системы – 1 неделя.
Словарь терминов – 1-2 недели.
Составление диаграмм бизнес-процессов и их уточнение у экспертов – от 1 месяца.
Описание первичных данных (потоков между бизнес-процессами) – 2-3 дня.

Разработка Концепции системы - около 1 месяца:

Обзор существующих систем – 2-3 дня.
Экономическое обоснование целесообразности проекта – 1-2 дня.
Уточненные технические требования – 1 неделя.
Стратегия проектирования системы (фактически, наметки ко всем 8 будущим проектным документам, по 2-3 дня для каждого) – 16-24 дня.

Составление окончательной документации на последующие этапы – 1-2 недели:

Разработка Технического задания – от 2-3 дней.
Составление Календарного плана работ – 1-2 дня.
Калькуляция работ - 2-5 дней.
Составление и согласование Договора на проектирование, разработку и внедрение системы - 2-5 дней.

Проектирование – от 4 месяцев:

Разработка Модели данных (архитектура базы данных и ER-диаграммы с описанием) – от 3 недель.
Разработка Методик информационного наполнения (для тестирования и внедрения) – 1 неделя.
Разработка Программной архитектуры (описание компонентов и их взаимосвязей) – от 2 недель.
Разработка Модели представления интерфейса (структура экранных форм и отчетов, бизнес-логика процедур преобразования данных) – от 3 недель.
Разработка Модели процессов системы (DFD-диаграммы и описание работы системы на этапах внедрения и эксплуатации) – от 2 недель.
Разработка Спецификации на программирование (модулей и функций) – от 3 недель.
Разработка Методологии встраивания системы в бизнес-процессы (план расширения функциональных возможностей системы и описание перспектив ее развития) – 1 неделя.
Разработка Технических требований к аппаратной части и программному окружению серверов и рабочих мест (для тестировщиков и клиентов) – 1 неделя.

Реализация – от 7 месяцев (наиболее сложный этап для ориентировочной оценки):

Кодирование компонент (модулей, драйверов, инструментов и пр.) – от 3 месяцев (зависит от количества компонент).
Тестирование и доработка компонент – от 1 месяца (в среднем, 30% от этапа кодирования).
Создание скриптов и генерация базы данных – от 1-3 месяцев, в т.ч.:

Создание скриптов генерации табличных пространств и настройка конфигурационных параметров БД – 1 неделя.
Создание скриптов генерации таблиц, последовательностей, индексов, несложных триггеров и функций – 1 неделя.
Создание скриптов настройки репликации – 1 неделя.
Разработка запросов к БД (на выборку данных для отчетов и пр.) – от 1 месяца.
Разработка хранимых процедур – от 1 месяца.

Информационное наполнение системы для стендового испытания – 1 неделя.
Стендовое тестирование и доработка системы – от 1 месяца, в т.ч.:

Тестирование и оптимизация запросов на выборку данных
Тестирование транзакций при добавлении, изменении, удалении данных на правильную работу последовательностей, ограничений, триггеров, функций и пр.; исправление ошибок, оптимизация запросов и настройка БД, подготовка отчета – от 2 недель.
Тестирование и настройка обмена данными для распределенной БД (репликации); исправление ошибок, оптимизация запросов и настройка БД, подготовка отчета – от 2 недель.

Подготовка документации (описание системы, руководство пользователя, и руководство администратора с приложениями) – от 1 месяца.

Внедрение в одном филиале – от 1 месяца:

Инсталляция системы на рабочих местах пользователей и администратора – 1 неделя.
Сопровождение пользователей при наполнении системы – 1-2 недели.
Устранение проблем (если таковые будут) – до 1 недели.
Обучение пользователей и администратора – до 1 недели.
Подготовка и утверждение приемо-сдаточных актов – 1-3 дня.

3.3.9 Общий план работ

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

№	Этапы и подэтапы	Документы (в скобках – трудоемкость разработки, ЧМ)	Трудо-ёмкость (ЧМ)	Продол-житель-ность (мес)	Персонал
1.	Стратегия	· Описание общих требований (0,5) · Календарный план НИР · Смета затрат по НИР · Соглашение о конфиденциальности · Договор о проведении обследования	1	0,5	3 (рук-тель, гл.бухгалтер, аналитик)
2.	Анализ	· Протоколы интервью (2-3) · Модель предметной области (3) · Концепция (3) · Техническое задание (1,5-2) · Календарный план (0,5) · Калькуляция работ (0,5) · Договор (0,5)	12	От 4	3 аналитика (и более)
3	Проекти-рование	· Информационная модель (3) · Методика наполнения (1-2) · Функциональная модель (2) · Модель интерфейса (2) · Модель процессов (2) · Спецификация (2-3) · Методика встраивания в БП (1)	15	От 4	4 аналитика (и более)
4.	Реализация	· Описание системы (0,5) · Руководство пользователя (1) · Руководство администратора (1) · Отчеты о стендовых испытаниях и результатах пилотного внедрения (1)	20	От 7	4 (аналитик, прогр-сты)
	Итого по этапам 1-4		48	От 15	От 4
5.	Внедрение	· Отчет о наполнении системы данными. · Отчет о соответствии работы системы требованиям ТЗ.		Около 1 мес. на 1 объект	2 (прогр-сты клиента и сервера или прогр-ст и оператор)

3.4 Методология развития существующей системы

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

3.4.1 Перечень работ

Для этого необходимо выполнить следующие работы:

Обследование предметной области:

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

Определение необходимой архитектуры системы:

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

Проектирование системы:

Создание серверной части системы (системные функции, структуры данных, базовые процедуры).
Создание клиентской части системы (интерфейс пользователя, инструментарий, драйверы и пр.).
Конфигурирование механизмов доступа (Web, Net8 и пр.) и синхронизации данных (различные виды репликации).

Информационное и функциональное наполнение системы (для стендовых испытаний):

создание иерархии прототипов (понятийной модели) объектов предметной области;
конфигурирование взаимосвязей между этими объектами;
сбор и наполнение БД системы актуальными производственными данными;
сбор и наполнение БД системы географическими данными;
конфигурирование системы для решения задач предметной области (встраивание в бизнес-процессы);

Стендовое тестирование и пилотные внедрения:

Стендовое тестирование системы (с минимально необходимым информационно-функциональным наполнением) на различных программно-аппаратных платформах (Sun, Intel, IBM; Solaris, Linux, HP/UX, Windows NT, Novell Netware; Windows 95, 98, 2000) серверов и клиентов.
Пилотные внедрения системы в производственных подразделениях исследуемых предприятий.

3.4.2 Этапы и итоговые результаты

В итоге получим следующий перечень этапов и назовем необходимые выходные документы по каждому из них:

1. Обследование предметной области. Итоговые результаты: диаграммы бизнес-процессов; обзор предметной области; словарь терминов предметной области. Последний составляется как мини-энциклопедия, а не только с краткой интерпретацией термина, как в Глоссарии к Спецификации на программирование.

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

3. Модификация «Комплекса/2000» и разработка новых подсистем в соответствии с требованиями ТЗ и проекта. Итоговые результаты: модифицированные серверная и клиентская части системы, новые подсистемы, новая техническая документация на них.

4. Создание иерархии прототипов (понятийной модели) объектов и отношений между ними. Итоговые результаты: ввод в проектируемую систему понятийной модели для предметной области заказчика.

5. Сбор и наполнение БД системы актуальными производственными данными. Результат: БД системы, заполненная минимально необходимым для стендовых испытаний набором реальных производственных данных по какому-либо подразделению заказчика.

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

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

8. Тестирование, опытная эксплуатация и доработка. Итоговые результаты: отчет о тестировании и выявленных несоответствиях ТЗ, отчет по ликвидации ошибок и несоответствий ТЗ; предварительная версия системы.

9. Промышленная эксплуатация. Итоговые результаты: отчеты о результатах пилотных внедрений, отчет о направлениях дальнейшего развития системы; окончательная версия системы, прошедшая успешные испытания и отладку на одном или ряде пилотных внедрений.

3.5 Договорная и приемо-сдаточная документация

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

3.5.1 Договор на создание (развитие) системы

Данный договор состоит из следующих разделов:

Предмет договора и сроки выполнения работ.
Стоимость работ и порядок расчетов.
Порядок сдачи и приема работ.
Ответственность сторон.
Прочие условия.
Ответственность сторон и порядок рассмотрения споров.
Обстоятельства непреодолимой силы.
Приложения.
Адреса и банковские реквизиты сторон.

3.5.2 Договор о проведении обследования

«Договор о проведении обследования ». Документ является договором на выполнение работ по этапу Анализа предметной области (его можно также назвать «Соглашением»).

В договоре можно определить состав и содержание результирующих документов. Можно также оговорить способ описания бизнес-диаграмм (стандарт IDEF0, средства Oracle или Rational Rose, ARIS и пр.).

3.5.3 Соглашение о конфиденциальности

«Соглашение о конфиденциальности ». Данный документ, призван защитить Заказчика от возможной утечки конфиденциальной информации, полученной при обследовании предприятия.

Составляется по инициативе Заказчика. Может оформляться как приложение к «Договору о проведении обследования ».

3.5.4 Техническое задание

Документ «Техническое задание » содержит определение цели и границ проекта, функционального наполнения системы и требуемых ресурсов, этапов работ и выходных документов. За основу формы и содержания ТЗ взят отечественный стандарт ГОСТ 34.602-89 [см. 2.1.2]. Учтены также рекомендации международного стандарта IEEE Std 830-1993 (Спецификация требований к ПО), которые касаются второй, третьей и, частично, первой части ТЗ [см. 2.4.2].

ТЗ состоит из разделов:

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Требования к системе.

3.1. Требования к системе в целом.

3.2. Требования к функциям системы.

3.3. Требования к информационному обеспечению.

3.4. Требования к программному обеспечению.

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

3.6. Требования к организационному обеспечению.

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

4. Состав и содержание работ по созданию (развитию) системы.

5. Порядок контроля и приемки системы.

6. Описание состава работ и исполнителей по подготовке системы к внедрению.

7. Требования к документированию.

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

9. Приложения.

Далее опишем эти разделы.

3.5.4.1 Общие сведения

Здесь указывается, главным образом, следующее:

Полное наименование системы и ее условное обозначение.
Основание работ – в первую очередь, номер договора, на основании которого создается система.
Наименование предприятий разработчика (исполнителя) и заказчика системы, их реквизиты.
Плановые сроки начала и окончания работ по созданию (развитию) системы.
Сведения об источниках и порядке финансирования работ.
Порядок оформления и предъявления заказчику результатов работ по созданию системы.

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

В разделе 2 определяются:

Назначение создания (развития) системы - здесь указывают вид автоматизируемой деятельности и перечень объектов автоматизации.
Цели создания (развития) системы - здесь указывают конкретные цели, например, требуемые значения каких-либо показателей объекта автоматизации, которые должны быть достигнуты в результате создания ИС.

3.5.4.3 Требования к системе

Раздел 3 может содержать следующие пункты (состав пунктов определяется Исполнителем и Заказчиком):

Требования к системе в целом:

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

Требования к функциям системы:

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

Требования к информационному обеспечению:

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

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

3.5.4.4 Состав и содержание работ по созданию (развитию) системы

Раздел 4 содержит:

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

Этот раздел может быть объединен с разделом 6 «Описание состава работ и исполнителей по подготовке системы к внедрению» в общий раздел «Состав и содержание работ».

3.5.4.5 Порядок контроля и приемки системы

Раздел 5 содержит:

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

3.5.4.6 Описание состава работ и исполнителей по подготовке системы к внедрению

Раздел 6 содержит:

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

Этот раздел может быть объединен с разделом 4 «Состав и содержание работ по созданию системы» в общий раздел «Состав и содержание работ».

3.5.4.7 Требования к документированию

Раздел 7 содержит:

Согласованный Исполнителем и Заказчиком системы перечень подлежащих разработке видов документов.
Описание и структура указанных документов (при необходимости).

3.5.4.8 Источники разработки

Раздел 8 - необязательная часть ТЗ. Здесь перечисляются документы и информационные материалы, на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы, например:

Технико-экономическое обоснование.
Отчеты о законченных НИР.
Материалы на отечественные и зарубежные системы-аналоги.

3.5.4.9 Приложения

Приложения - необязательная часть ТЗ. В приложениях могут, например, содержаться:

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

3.5.5 Описание общих требований

Документ «Описание общих требований », по существу, является предварительной версией «Технического задания ». Основной целью документа является формирование границ проекта, т.е. выявление и описание общих требований. Форма документа может совпадать с формой «Технического задания » [3.5.1], но со свободным составом разделов и подразделов.

Далее опишем состав разделов документа (как один из вариантов).

3.5.5.1 Общие сведения

Раздел состоит, прежде всего, из следующих пунктов:

«Полное наименование системы и ее условное обозначение».
«Основание работ». Здесь приводятся, в первую очередь, номер договора, на основании которого создается система.
«Заказчик, Головной исполнитель и соисполнитель проведения работ ». Здесь приводятся наименования соответствующих предприятий и их реквизиты.
«Сроки начала и окончания работ по созданию системы». Здесь можно просто сослаться на договор.
«Источники и порядок финансирования работ». Здесь нужно указать из средств какого предприятия идет финансирование, и сослаться на смету.
«Порядок оформления результатов работ по созданию системы». Здесь можно жестко оговорить состав документов, предоставляемых Исполнителем после обследования, и примерный состав – по остальным этапам. Можно это оговорить и в договоре (тогда на него нужно сослаться). Подробное описание документов не требуется, поскольку оно, в дальнейшем, будет приведено в Техническом задании в разделе 7 «Требования к документированию» [0].
«Защита авторских прав ». Здесь определяется, кому будут принадлежать авторские права на разработанную систему.

3.5.5.2 Назначение, цели и задачи создания (развития) системы

В разделе определяется:

Назначение создания или развития системы в плане обслуживаемых бизнес-процессов с указанием вид автоматизируемой деятельности и перечня объектов автоматизации.
Конкретные цели создания или развития системы.
Задачи, которые необходимо решить для достижения перечисленных целей.
Краткое технико-экономическое обоснование целесообразности проведения обследования и дальнейшего создания или развития системы (при необходимости).

3.5.5.3 Требования к системе в целом

Раздел может содержать следующие пункты (состав и содержание пунктов определяется Исполнителем и Заказчиком):

Требования к программной архитектуре системы.
Требования к архитектуре БД и средствам репликаций данных.
Требования к надежности.
Требования к защите информации от несанкционированного доступа.

3.5.5.4 Требования к видам обеспечения

Раздел может содержать следующие пункты (содержание пунктов определяется Исполнителем и Заказчиком):

Требования к программному окружению (ОС, СУБД, драйверы, интерфейс и пр.).
Требования к техническому обеспечению.

3.5.5.5 Требования к функциям системы

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

3.5.5.6 Состав и содержание работ

В этом разделе приводится перечень и содержание этапов (решаемые задачи) по разработке или развитию системы. На основании этих сведений в дальнейшем составляется «Календарный план работ ».

Раздел содержит:

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

3.5.6 Календарный план работ

«Календарный план работ » (или просто «Календарный план » или «График работ ») предназначен для управления проектом на всех этапах и представляет собой перечень этапов и подэтапов с указанием по каждому из них следующих данных:

Сроков и продолжительности (в скобках) работ.
Состава исполнителей.
Состава документов, предъявляемых по окончании соответствующих стадий и этапов работ.

«Календарный план » составляется на основании сведений раздела 6 «Состав и содержание работ» [3.5.5.6] документа «Описание общих требований» или разделов 4 «Состав и содержание работ по созданию (развитию) системы» [3.5.4.4] и 6 «Описание состава работ и исполнителей по подготовке системы к внедрению» [3.5.4.6] «Технического задания».

3.5.7 Смета расходов

«Смета расходов » (или просто «Смета ») предназначена для обоснования стоимости проекта и представляет собой перечень всех затрат по проекту. Также можно использовать название «Калькуляция работ ».

Перечень затрат в смете удобно группировать по указанным в «Календарном плане » этапам и подэтапам, а также по группам затрат.

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

3.5.8 Акт приема-сдачи работ

Данный документ констатирует факт выполнения (частичного выполнения или невыполнения) Исполнителем своих обязательств по конкретному этапу и является основанием для выплаты Заказчиком установленной суммы денег за проведенные Исполнителем работы. Акт обязательно визируется обеими сторонами.

В случае частичного выполнения или невыполнения Исполнителем своих обязательств, к Акту прилагается «Протокол испытаний » [3.5.9] с выводами о неполном соответствии выполненных работ требованиям Заказчика.

3.5.9 Протокол испытаний

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

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

3.6 Рабочая документация

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

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

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

3.6.1 Протоколы интервью

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

Протоколы могут также оформляться как приложение к документу «Модель предметной области ».

Рекомендуется следующая форма протокола:

ИНТЕРВЬЮ

Имя:	Смирнов Валентин Петрович
Организация:	АК «Трансгаз»
Подразделение:	Управление информационных технологий
Должность:	Начальник управления
Дополнительно:	Эксперт имеет 15-летний опыт работы в данной сфере
Интервьюер:	Георгиев И.К.
Дата/Время:	24.07.2001
Тема:	Организационная структура компании
Тип интервью:	Обзорное
Место проведения:	Офис АК «Трансгаз»
Предоставленные документы:	Телефонный справочник сотрудников

1. Вопрос: Какова структура компании по регионам?

Ответ: Компания имеет 4-уровневую региональную структуру. Первый уровень – Центральный офис компании (ЦО). Второй – дочерние компании (ДО). Третий – районные газопроводные управления и производственные объединения (РГУ, ПО). Четвертый – линейные службы (ЛПДС и пр.) …

2. Вопрос: …

Ответ: …

…

Резюме : (обобщающие выводы, планирование следующих тем и вопросов и пр.)

3.6.2 Модель предметной области

Документ состоит из следующих разделов (некоторые из них, при необходимости, могут оформляться как отдельные документы):

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

Региональная иерархия - описание организационных уровней (центральный офис, дочерние предприятия, производственные управления, локальные службы и бригады).
Внутренние подразделения (отделы) для каждого уровня.
Группировка внутренних подразделений (отделов) по бизнес-процессам.

«Объекты учета ». Содержит описание производственных, технологических и других объектов, учет которых необходимо вести в системе – их состава, взаимосвязей, место в общей структуре, статистику и т.п.
«Эксплуатируемые информационные системы ». Описывает сферы деятельности предприятия, подлежащие автоматизации и реализованные в этих сферах информационные системы.
«Бизнес-процессы ». Содержит описание бизнес-процессов предметной области, потоков данных и управлений между ними, регистрируемых событий и пр. с прилагаемыми бизнес-диаграммами. Диаграммы рекомендуется выполнять в формате IDEF0, но можно использовать также средства Oracle Process Modeler, ARIS или UML. Формат описания БП можно заранее оговорить в «Договоре о проведении обследования ».
«Терминологический словарь ». Рекомендуется разбивать по бизнес-процессам (или по подразделениям). Содержит не только интерпретацию термина, но и краткий обзор, т.е. является краткой «энциклопедией» по предметной области. В этом его отличие от «Глоссария » к «Спецификации на программирование », где приводятся только используемые в этой Спецификации термины и их точная интерпретация.

3.6.3 Обзорный документ по рынку систем

Документ «Обзор существующих на рынке систем » содержит обзор достоинств и недостатков других систем (используемых в данной предметной области или которые можно использовать), и обоснование принципиального достоинства предлагаемой системы или подходов к ее проектированию. Само название документа может быть более конкретно (и по отношению к типу системы и к предметной области), например: «Использование ГИС в нефтегазовой промышленности».

Названный документ содержит, например, следующие разделы:

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

3.6.4 Концепция

Документ «Концепция » предназначен для определения стратегии проектирования, реализации, внедрения и дальнейшего развития системы. Также можно использовать названия: «Устав проекта », «Описание проекта », «Спецификация границ проекта », «Документ по стратегии » [20].

Документ содержит следующие разделы:

Анализ существующих на рынке систем:

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

Уточнение системных требований (на основе анализа предметной области):

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

Направления проектирования - собственно концепция, т.е. стратегия проектирования системы (фактически, наметки ко всем будущим проектным документам).

Концепция архитектуры (состав компонентов).
Концепция ядра (структуры данных для реализации механизмов, названных в «Концепции архитектуры»).

Общий план внедрения системы.
Направления развития системы.
Используемые стандарты.

3.6.5 Модель данных

Документ «Модель данных » содержит следующее:

Архитектура базы данных (методы построения БД и методы доступа к данным и механизмы репликации данных). Этот раздел раньше был в Программной архитектуре. Впрочем, его можно сделать отдельным документом.
Входные и выходные данные:

Входные данные (сигналы, сообщения, документы).
Выходные данные (сигналы, сообщения, документы).

Описание сущностей и связей (концептуальная ER-модель):

Определения сущностей и атрибутов концептуальной модели данных (с фрагментами ER-диаграмм).
Описание доменов типов данных.
ER-диаграммы концептуальной модели данных (в формате IDEF1x).
Диаграммы таблиц физической модели данных.

Сценарии (скрипты) для генерации базы данных.

3.6.6 Модель процессов системы

Документ «Модель процессов системы » или «Технологические процессы системы » содержит:

Описание основных технологических процессов системы (с примерами):

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

Диаграммы работы с системой при ее внедрении и эксплуатации (в формате DFD или UML).

3.6.7 Методики сбора и обработки исходных данных

Документ «Методики сбора и обработки исходных данных » является, по существу, описанием технологии внедрения системы (а также дальнейшего ввода данных при ее эксплуатации) и содержит:

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

3.6.8 Программная архитектура

Документ «Программная архитектура » (синонимы – «Архитектура системы », «Функциональная модель ») содержит следующее:

Состав модулей (с диаграммой).
Распределение функций между участниками создания и использования системы.
Методы обеспечения надежности, производительности, безопасности и качества системы.
Технические требования к программному окружению (как клиентов, так и серверов).

3.6.9 Требования к аппаратному обеспечению

Документ «Требования к аппаратному обеспечению » содержит разделы:

Аппаратная архитектура:

защита информации;
обеспечение надежности;
обеспечение производительности.

Аппаратная реализация и программное окружение:

общие требования по производительности;
общие требования по качеству;
план нагрузки (общие показатели БД, работоспособность распределенной архитектуры, количество компьютеров, количество сеансов, максимальный объем транзакции);
технические требования к серверам (аппаратная часть, программная часть);
технические требования к рабочим местам (аппаратная часть, программная часть);
технические требования к каналам связи;
технические требования по безопасности.

3.6.10 Спецификация на программирование

Документ «Спецификация на программирование » содержит описание компонент системы, составляющих основу ее функциональности, с указанием входов, выходов, экранного интерфейса и исключительных ситуаций (с их обработкой), а именно:

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

3.7 Сопроводительная документация

Под сопроводительной документацией понимается документация, которая разрабатывается Исполнителем и передается Заказчику после реализации системы с описанием различных аспектов ее эксплуатации.

Наиболее компактный (минимально необходимый) набор сопроводительной документации включает:

Описание системы.
Руководство пользователя (Инструкция по эксплуатации).
Руководство администратора.

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

Опишем структуру и содержание указанных выше документов.

3.7.1 Описание системы

Документ содержит следующие разделы:

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

3.7.2 Руководство пользователя

Документ содержит следующие разделы:

Задачи, решаемые пользователем.
Интерфейс пользователя.
Функции подсистем.

3.7.3 Руководство администратора

Документ содержит следующие разделы:

Задачи, решаемые администратором.
Инсталляция системы и подсистем.
Функции подсистем.

4 Рекомендации по подготовке и участию в тендерах и презентациях

4.1 Подготовка документов и буклетов

4.1.1 Оформление рекламного буклета

4.1.2 Подготовка научно-технического обоснования проекта

4.2 Подготовка презентаций и демо-версий

4.2.1 Подготовка презентации системы

4.2.2 Подготовка демонстрационной версии системы

5 Внутрифирменные соглашения

5.1 Соглашения по проектированию

5.1.1 Описание бизнес-процессов

5.1.1.1 Bpwin (IDEF0)

5.1.1.2 Oracle Process Modeler

5.1.2 Описание диаграмм «сущность-связь» (ERD)

5.1.2.1 Erwin

5.1.2.2 Oracle Diagrammer

5.1.2.3 PowerDesigner

5.1.3 Описание системных процессов

5.1.3.1 DFD

5.1.3.2 UML

5.1.4 Описание потоков работ ( Workflow)

5.2 Соглашения по программированию серверной части

5.2.1 Генерация экземпляра БД, табличных пространств и сегментов отката

5.2.2 Генерация таблиц и других объектов БД (DDL-скрипты)

5.2.3 Программирование на SQL (DML-скрипты)

5.2.4 Программирование на PL/SQL

5.3 Соглашения по программированию клиентской части

5.3.1 Программирование на Borland C++

5.3.2 Программирование на MS VC++

5.3.3 Программирование в Oracle Developer2000

5.4 Методики тестирования программных продуктов

5.4.1 Стратегии тестирования

5.4.2 Инструменты тестирования

5.4.3 Тестирование серверной части

5.4.4 Тестирование клиентской части

5.5 Рекомендации по оптимизации работы системы

5.5.1 Настройка сервера БД и объектов БД

5.5.2 Оптимизация выполнения запросов

5.5.3 Настройка репликации

5.5.4 Настройка клиентов

6 Термины

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

6.1 Общие термины

АС – автоматизированная система.
АСУ – Автоматизированная система управления.
АСУТП – Автоматизированная система управления технологическими процессами.
БД – база данных.
БП – бизнес-процесс(ы).
ГИС – географическая информационная система.
ЕКС - Единый комплекс стандартов.
ЕСКД – Единая система конструкторской документации.
ЕСПД – Единая система проектной документации.
ЖЦ – Жизненный цикл.
ЖЦП – Жизненный цикл программы.
ЖЦРПО - Жизненный цикл разработки программного обеспечения.
ЖЦ ПС – Жизненный цикл программной системы.
ИР – информационные ресурсы.
ИС – информационная система.
Испытания АС - процесс проверки выполнения заданных функций системы, определения и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик системы, выявления и устранения недостатков в действиях системы, в разработанной документации [стандарт ГОСТ 34.603-92 – см. 8].
ИТ – информационные технологии.
Комплекс - программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса [стандарт ГОСТ 19.101-77 – см. 10].
Компонента - программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса [стандарт ГОСТ 19.101-77 – см. 10].
КСП – календарно-сетевое планирование.
КТС – комплекс технических средств.
Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования [стандарт ISO12207 – см. 2.2.3].
НИР – научно-исследовательские работы.
НИОКР – научно-исследовательские и опытно-конструкторские работы.
НТД – научно-техническая документация.
ОКР – опытно-конструкторские работы.

Операбельность – эксплуатационная пригодность.

ОС – операционная система (MS Windows, UNIX и пр.).
ПМК - программно-методический комплекс.
ПТК - программно-технический комплекс.
ПО - программное обеспечение.
ПП – программный продукт.
Проект - в основе проекта лежит план создания продукта или услуги. Проект имеет дату старта и дату финиша и может содержать следующие элементы: работы, ресурсы, структуру декомпозиции работ (WBS), организационную структуру (OBS), календари, зависимости, целевые проекты, расходы, риски, уведомления, показатели, проектные коды и документы [19].
ПС – программная система.
РД - руководящий документ.
САПР – Система автоматизированного проектирования.
СВТ – средства вычислительной техники.
Система - объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей [стандарт ISO12207 – см. 2.2.3].
СРПП – система разработки и постановки продукции на производство.
СТПО - Спецификация требований к программному обеспечению.
СУБД – система управления базами данных (Oracle, Informix, Sybase, MS SQL и пр.)
ТЗ – Техническое задание.
Требование квалификации - набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде [стандарт ISO12207 – см. 2.2.3].
ТС – 1) техническая система; 2) технические средства.
ТТ – технические требования.
ТУ – технические условия.
ЧТЗ – частные технические задания.
Oracle Aim - метод внедрения готовых приложений, входящий в Oracle Method .
Oracle CDM ( Custom Development Method) - метод сквозного создания и внедрения информационных систем с использованием Oracle Designer, входящий в Oracle Method .
Oracle DWM - метод разработки хранилищ данных, входящий в Oracle Method .
Oracle Method - глобальная методология разработки ИС фирмы ORACLE.
Oracle PJM - метод управления проектом, входящий в Oracle Method .
SLC – ЖЦ.
SLCM – модель ЖЦПО.
Software Life Cycle (SLC) – Жизненный Цикл ПО.

6.2 Термины по защите информации

Данные термины взяты из [12].

Биометрическая идентификация - идентификация, основанная на использовании индивидуальных физических признаков человека.
Вещественный код - код, записанный на физическом носителе (идентификаторе).
Взлом -действия, направленные на несанкционированное разрушение конструкции.
Временной интервал доступа (окно времени) - интервал времени, в течение которого разрешается перемещение в данной точке доступа.
Вскрытие - действия, направленные на несанкционированное проникновение через УПУ без его разрушения.
Доступ - перемещение людей, транспорта и других объектов в (из) помещения, здания, зоны и территории.
Запоминаемый код - код, вводимый вручную с помощью клавиатуры, кодовых переключателей или других подобных устройств.
Зона доступа - совокупность точек доступа, связанных общим местоположением или другими характеристиками (например, точки доступа, расположенные на одном этаже).
Идентификатор доступа, идентификатор (носитель идентификационного признака) - уникальный признак субъекта или объекта доступа. В качестве идентификатора может использоваться запоминаемый код, биометрический признак или вещественный код Идентификатор, использующий вещественный код - предмет, в который (на который) с помощью специальной технологии занесен идентификационный признак в виде кодовой информации (карты, электронные ключи, брелоки и т. д.).
Идентификация - процесс опознавания субъекта или объекта по присущему ему или присвоенному ему идентификационному признаку. Под идентификацией понимается также присвоение субъектам и объектам доступа идентификатора и (или) сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов.
Контроль и управление доступом (КУД) - комплекс мероприятий, направленных на ограничение и санкционирование доступа людей, транспорта и других объектов в (из) помещения, здания, зоны и территории.
Копирование - действия, производимые с идентификаторами, целью которых является получение копии идентификатора с действующим кодом.
КУД - контроль и управление доступом.
Манипулирование - действия, производимые с устройствами контроля доступа без их разрушения, целью которых является получение действующего кода или приведение в открытое состояние заграждающего устройства. Устройства контроля доступа могут при этом продолжать правильно функционировать во время манипулирования и после него; следы такого действия не будут заметны. Манипулирование включает в себя также действия над программным обеспечением.
Наблюдение - действия, производимые с устройствами контроля и управления доступом без прямого доступа к ним, целью которых является получение действующего кода.
Несанкционированные действия (НСД) - действия, целью которых является несанкционированное проникновение через УПУ.
Несанкционированный доступ - доступ людей или объектов, не имеющих права доступа .
НСД - несанкционированные действия.
Правило двух (и более) лиц - правило доступа, при котором доступ разрешен только при одновременном присутствии двух или более людей.

ПРД – правила разграничения доступа.

Принуждение - насильственные действия над лицом, имеющим право доступа, с целью несанкционированного проникновения через УПУ. Устройства контроля и управления доступом при этом могут функционировать нормально.
Пропускная способность - способность средства или системы КУД пропускать определенное количество людей, транспортных средств и т.п. в единицу времени.
Пулестойкость - способность преграды противостоять сквозному пробиванию пулями и отсутствие при этом опасных для человека вторичных поражающих элементов.
Саботаж (состояние саботажа - по ГОСТ Р 50776) - преднамеренно созданное состояние системы, при котором происходит повреждение части системы.
Санкционированный доступ - доступ людей или объектов, имеющих права доступа.
СЗИ – средства защиты информации.
СЗЗ – специальные защитные знаки.
Система контроля и управления доступом (СКУД) - совокупность средств контроля и управления. обладающих технической, информационной, программной и эксплуатационной совместимостью.
СКУД - Система контроля и управления доступом.
Средства контроля и управления доступом (средства КУД) - механические, электромеханические, электрические, электронные устройства, конструкции и программные средства, обеспечивающие реализацию контроля и управления доступом.
Специальные защитные знаки (СЗЗ) - продукты, созданные на основе физико-химических технологий и предназначенные для контроля доступа к объектам защиты, а также для защиты документов, идентифицирующих личность, от подделки.
Считыватель - устройство в составе УВИП, предназначенное для считывания (ввода) идентификационных признаков.
Точка доступа - место, где непосредственно осуществляется контроль доступа (например дверь, турникет, кабина прохода, оборудованные считывателем, исполнительным механизмом, электромеханическим замком и другими необходимыми средствами).
УВИП - устройства ввода идентификационных признаков.
УПУ - устройства преграждающие управляемые.
Уровень доступа - совокупность временных интервалов доступа (окон времени) и точек доступа, которые назначаются определенному лицу или группе лиц, имеющим доступ в заданные точки доступа в заданные временные интервалы.
Устойчивость к взрыву - способность конструкции противостоять разрушающему действию взрывчатых веществ.
Устойчивость к взлому - способность конструкции противостоять разрушающему воздействию без использования инструментов, а также с помощью ручных и других типов инструментов.
Устройства ввода идентификационных признаков (УВИП) - электронные устройства, предназначенные для ввода запоминаемого кода, ввода биометрической информации, считывания кодовой информации с идентификаторов. В состав УВИП входят считыватели и идентификаторы.
Устройства исполнительные - устройства или механизмы, обеспечивающие приведение в открытое или закрытое состояние УПУ (электромеханические и электромагнитные замки, защелки, механизмы привода шлюзов, ворот, турникетов и т. д.).
Устройства преграждающие управляемые (УПУ) - устройства, обеспечивающие физическое препятствие доступу людей, транспорта и других объектов и оборудованные исполнительными устройствами для управления их состоянием (двери, ворота, турникеты, шлюзы, проходные кабины и т. п. конструкции).
Устройства управления (УУ) - устройства и программные средства, устанавливающие режим доступа и обеспечивающие прием и обработку информации с УВИП, управление УПУ, отображение и регистрацию информации.
УУ - устройства управления.

7 Ссылки

http://nnz.newmail.ru/IEEE830.htm - IEEE Recommended Practice for Software Requirements Specifications.
http://www.as.ntl.ru/engl/Solutions/standarts.htm - Software development. International standards.
http:// www.bizcom.ru/analisys/2000-03/07.html - Денис Королев. Инновационный цикл в разработке проектов.
http://www.nur.yamal.ru/koi8-r/citforum/programming/oop_rsis/index.shtml - С.С. Гайсарян. Объектно-ориентированные технологии проектирования прикладных программных систем.
http://kis.pcweek.ru/N24/ISO8859/Reviews/chapt1.htm - Владимир Липаев. Стандарты, регламентирующие жизненный цикл сложных программных комплексов.
ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. См. на ссылках: http://joker.botik.ru/~tip/Gost/34-601-90.htm , http://softdev.omskreg.ru/gost/34-601-90.asp .
ГОСТ 34.602-89. Техническое задание на создание автоматизированных систем. См. на ссылках: http://joker.botik.ru/~tip/Gost/34-602-89.htm .
ГОСТ 34.603-92. Виды испытаний автоматизированных систем. См. на ссылках: http://joker.botik.ru/~tip/Gost/34-603-92.htm .
ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированных систем. См. на ссылках: http://joker.botik.ru/~tip/Gost/34-201-89.htm , http://www.nist.fss.ru/hr/doc/gost/34-201-89.htm .
ГОСТ 19.101-77. Виды программ и программных документов. См. на ссылках: http://joker.botik.ru/~tip/Gost/19101-77.htm .
ГОСТ 24.104-85. Автоматизированные системы управления. Общие требования. См. на ссылках: http://www.nist.fss.ru/hr/doc/gost/24-104-85.htm .
ГОСТ Р 51241-98. Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний. См. http://joker.botik.ru/~tip/Gost/51241-98.htm .
А.М. Вендров. CASE-технологии. Современные методы и средства проектирования информационных систем. См. http://icc.migsv.ru/database/case/index.shtml .
http:// www.as.ntl.ru/Solutions/PO.htm#Меж - Общее управление проектом в фирме Архивные Системы.
http://www.integro.ru/builderpro/V2_analyse.htm - Предпроектное исследование задачи (фирма «Интегро», г.Уфа).
http://www.s-test.nm.ru/Docs/docs.htm - ЖЦРПО.
http://www.ivn.newmail.ru/index_rus.html - Руководство по управлению внедренческими проектами на базе MS Project 2000 и рекомендаций PMI.
http://javaworld.osp.ru/dbms/1997/03/41.htm - Е. З. Зиндер. Соотнесение и использование стандартов организации жизненных циклов систем. СУБД №3, 1997.
http://www.pmsoft.ru/pmsoft/doc/theory/glossary.asp - Глоссарий терминов управления проектами.
Питер Колетски, Д-р Поль Дорси. Oracle Designer. Настольная книга пользователя. Создание систем с использованием средств разработки Oracle. 2-е издание.
С.В. Маклаков. BPwin и ERwin, CASE-средства разработки информационных систем.
Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000. – 432 с.: ил. (Серия «Для программистов»).
Брукс. Ф. Мифический человеко-месяц или как создаются программные системы.
Брукс Ф. Как проектируются и создаются программные комплексы. М.: Наука, 1979.
Боэм Б. У. Инженерное проектирование программного обеспечения: Пер. с англ. - М.: Радио и связь.