- Денис Королев. Инновационный цикл в разработке проектов [3].
- С.С.Гайсарян. Объектно-ориентированные технологии проектирования прикладных программных систем [4].
- Владимир Липаев. Стандарты, регламентирующие жизненный цикл сложных программных комплексов [5].
- Проект создания ПО (фирма «Архивные Системы») [14].
- Предпроектное исследование задачи (фирма «Интегро», г. Уфа) [13].
- Жизненный цикл разработки ПО [14].
- Руководство по управлению внедренческими проектами на базе MS Project 2000 и рекомендаций PMI [15].
Под разработкой новой системы понимается весь процесс создания информационной системы от системного обследования до внедрения. Этот процесс включает следующие этапы (по международному стандарту ISO 12207:1995):
- Стратегия (определение цели и ориентиров).
- Анализ (обследование и выработка требований).
- Проектирование (формальное описание системы для передачи программистам).
- Реализация (разработка и интеграция компонент серверных и клиентских частей системы).
- Внедрение (ввод в промышленную эксплуатацию).
- Сопровождение (абонентское обслуживание).
В результате сильного изменения бизнес-процессов предприятия, законодательства, появления новых информационных технологий и т.д. может потребоваться произвести развитие системы, т.е. сделать итерацию жизненного цикла системы с одного из ее этапов – реализации, проектирования или даже анализа. Поэтому фазу развития системы мы не будем выделять в отдельный этап ее жизненного цикла, однако описание особенностей этой фазы также включим в данный документ.
3.3.1.1 Назначение и особенности
Стратегия - этап определения назначения проекта, предварительного анализа предмета, планирования и оценки объема работ. На этом этапе Заказчик предоставляет Исполнителю краткие сведения о целях и объектах информатизации, на основе чего Исполнитель предоставляет Заказчику информацию об ориентировочных сроках и расходах по проекту.
Более реальная оценка объема работ возможна лишь после детального обследования предметной области в фазе Анализа (в границах, определенных на этапе Стратегии). Поэтому на этом этапе составляется документ с общими требованиями к системе и определением границ предметной области, в рамках которой будет эксплуатироваться эта система. Затем определяется объем работ на этапе Анализа и заключается соглашение (договор) на проведение этих работ. Объемы по другим этапам также могут включаться, но оговаривается, что они носят ориентировочный характер.
Только после проведения анализа определяется окончательный вариант Технического задания (ТЗ), календарный план (график) и калькуляция всех оставшихся работ, и составляется Договор по проекту.
Возможен (и часто практикуется) также другой вариант, когда сроки и объем средств у Заказчика ограничены. В этом случае календарный план и калькуляция работ в окончательном виде определяются на этапе Стратегии, но состав и объем работ определяются на этапе Анализа, по окончании которого в Техническом задании фиксируются необходимые требования к системе, которые можно реализовать за эти сроки и сумму.
3.3.1.2 Выходные документы
Во время и по окончании этапа Стратегии разрабатываются следующие документы:
- «Описание общих требований» [3.5.5]. Основной целью документа является формирование границ проекта, т.е. выявление и описание общих требований.
- Предварительная версия «Календарного плана работ». В этом документе четко оценивается трудоемкость, продолжительность и сроки этапа Анализа и ориентировочно – по остальным этапам.
- Предварительная версия «Сметы». В этом документе четко оцениваются затраты и общая стоимость работ на этапе Анализа и ориентировочно – по остальным этапам (на основании оценки трудоемкости, приведенном в «Календарном плане работ»).
- «Договор о проведении обследования» - договор на выполнение бизнес-обследования предметной области [3.5.2].
- «Соглашение о конфиденциальности» - соглашение о неразглашении конфиденциальной информации, полученной при обследовании предприятия (составляется по инициативе Заказчика) [3.5.3].
Этап носит непродолжительный характер (около 2 недель) и минимальное количество участвующих лиц (кроме руководителей и главных бухгалтеров – по 1-3 экспертов с обеих сторон).
Назначение этапа - обследование предметной области, обозначение границ и направлений проектирования системы, детальное планирование и уточнение объема будущих работ.
При обследовании предметной области используются самые различные источники информации: научно-техническая документация, отраслевые стандарты, публикации в прессе и Интернете, но, главное, - корпоративные руководящие документы и информация экспертов, результаты иньтервьюирования которых являются отражением фактических (или желаемых) деловых операций (бизнес-процессов) на предприятии.
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.1 подэтапов, а также в соответствии с количеством экспертов, которых предполагается интервьюировать.
Работы на этом этапе рекомендуется выполнять группе аналитиков – специалистов по исследуемой предметной области, по информационным технологиям, которые предполагается использовать в проекте, по методологиям обследования и проектирования (3-6 человек, при ограниченных сроках - больше).
3.3.3.1 Назначение и особенности
На этапе Проектирования создаются документы, на основании которых программисты будут разрабатывать компоненты системы, а затем внедрять готовую систему.
3.3.3.2 Состав этапа (подэтапы)
3.3.3.3 Выходные документы
На этом этапе разрабатываются следующие модели и методики:
- «Модель данных» или «Информационная модель». Документ содержит:
- описание архитектуры БД (серверы, клиенты, обмен данными, доступ к данным, сегменты данных);
- описание объектов системы и их взаимосвязей;
- концептуальные и физические ER-диаграммы.
- «Методики информационного наполнения» - методики сбора и обработки исходных данных (для тестирования и внедрения). Документ разрабатывается вслед за Моделью данных.
- «(Программная) архитектура» или «Функциональная модель» - описание компонентов системы, их группировки и взаимосвязей.
- «Модель представления интерфейса» - описание структуры экранных форм и отчетов, бизнес-логики процедур преобразования входных и выходных данных.
- «Модель процессов» - описание работы системы и с системой на этапах внедрения и эксплуатации, сопровождаемое диаграммами DFD или UML.
- «Спецификация на программирование» - описание входных и выходных параметров, обработки исключительных ситуаций модулями и функциями системы.
- «Методики функционального наполнения» или «Встраивание в бизнес-процессы» - варианты планов дальнейшего расширения функциональных возможностей системы, описание перспектив ее развития.
- «Технические требования» - требования к аппаратной части и программному окружению серверов и рабочих мест. Предназначено для тестировщиков и клиентов (в первую очередь – администраторам системы).
3.3.4.1 Назначение и особенности
Назначением этапа является создание БД, кодирование, тестирование и документирование разработанной системы.