Разработка информационной системы долгий и сложный процесс, в ходе которого рождается большое количество технической документации, содержащей описание создаваемого продукта с различных точек зрения. Несмотря на мнения некоторых специалистов о ненужности этого количества артефактов
Разработка информационной системы долгий и сложный процесс, в ходе которого рождается большое количество технической документации, содержащей описание создаваемого продукта с различных точек зрения. Несмотря на мнения некоторых специалистов о ненужности этого количества артефактов, практика показывает, что данная бюрократия является залогом удачного завершения проекта, особенно если команда осуществляющая разработку данной ИС включает несколько десятков человек. Также данная медаль может иметь оборотную сторону, так как четкое соблюдение всех требований к пакету технической документации в ГОСТах могут привести к появлению действительно не нужных документов. Таким образом, обсуждением состава технической документации, предъявляемой заказчику и необходимой для разработчиков ИС, следует заняться как можно раньше.
На начальном этапе проекта может потребоваться провести обследование объекта автоматизации, в результате которого аналитики проекта должны представить аналитический отчет.
Аналитический отчет может быть выполнен согласно требованиям ГОСТ 7.32-2001. Данный вид технической документации может содержать описание бизнес-процессов предприятия, рекомендации по автоматизации отдельных процессов. На стадии обследования объекта автоматизации аналитиками обычно формируется словарь терминов, описывающий предметную область, а также процессы, протекающие на предприятии. Все эти данные должны быть зафиксированы в технической документации для дальнейшего согласования их заказчиком. Описание процессов может быть выполнено с помощью диаграммы IDEF0 или диаграммы вариантов использования UML. Диаграммы, размещенные в аналитическом отчете, следует сопровождать текстовым описанием, где необходимо указать:
-
краткое описание процесса;
-
действующие лица (актеры);
-
предусловие;
-
постусловие;
-
основной сценарий процесса;
-
альтернативные сценарии (альтернативные сценарии на данном этапе могут быть выявлены не все, данное описание может дополняться в процессе уточнения требований).
Сценарии варианта использования в технической документации могут быть дополнены диаграммой деятельности UML, это поможет выявить дополнительные процессы и возможно неучтённых действующих лиц.
Также в аналитическом отчете можно показать примерные границы проекта, выделив процессы или функции, которые должны быть автоматизированы. Аналитический отчет является частью пакета технической документации и предназначен для описания предварительных целей создания ИС.
В конце документа следует дать технико-экономическое обоснование разработки ИС. Данный раздел технической документации, при необходимости, может быть выделен в отдельный документ.
Этап обследования объекта автоматизации юридически может быть оформлен отдельным договором или включен в перечень работ по созданию ИС.
Следующим этапом создания ИС, является уточнение требований и на основании этого анализа создание документа «Техническое задание». На данном этапе производится детализация процессов, выявленных на этапе обследования, которая способствует формированию списка функциональных требований к Системе. Функциональные требования могут быть описаны в технической документации при помощи все тех же диаграмм UML: use case (варианты использования или диаграммы прецедентов), avtivity (сценарии вариантов использования), state machine (диаграмма конечных автоматов).
На данном этапе разработки технической документации можно дополнить описание вариантов использования исключениями, то есть описанием поведения Системы в исключительных случаях (например, сбой или отказ аппаратных средств). Диаграмму конечных автоматов в технической документации лучше использовать для основных объектов, изменение состояния которых в Системе необходимо показать заказчику (например, документ – создан, согласован, утвержден).
Также на этапе создания Технического задания системным аналитиком формируется функциональная структура ИС с выделением отдельных подсистем, реализующих определенные функции.
Помимо функциональных требований в Техническое задание на разработку ИС должны быть включены требования к надежности и безопасности. Если создаваемая Система включает клиентские приложения для мобильных устройств, целесообразно будет включить в техническую документацию требования к разработке интерфейса.
В конце технического задания обычно размещается описание организационных моментов процесса сдачи системы в эксплуатацию и дальнейшего ее обслуживания.
На этапе эскизного проекта формируются документы, предназначенные в основном для разработчиков Системы, поэтому формат и состав технической документации может отступать от требований ГОСТа. Например, в нашей компании для разработчиков аналитиками создаются отдельные технические спецификации, выполненные согласно стандарту IEEE 830-1998 «Recommended Practice for Software Requirements Specifications». Данный документ может содержать детальный сценарий поведения Системы при вызове определенной функции, а также прототипы экранных форм, на которых данная функция реализована. Данный документ не выходит за рамки проектной команды и необходим только для внутреннего использования. Для описания реакции Системы на определенные сигналы, сообщения или действия в спецификацию можно включить диаграмму взаимодействия. Для спецификации объектов баз данных разработчиками может быть создана диаграмма классов.
Завершающим этапом документирования проекта по созданию ИС может считаться разработка технического проекта и рабочей документации. Техническая документация на данном этапе создается для специалистов заказчика, которые будут осуществлять эксплуатацию и, возможно, последующую доработку Системы.
Технический проект включает документацию, описывающую решения используемы при создании Системы. Техническая документация технического проекта может включать следующие документы:
-
«Пояснительная записка» или «Общее описание системы» - данные документы во многом пересекаются, поэтому в состав ТРП (технорабочий проект) следует включать только один из них. В документе должно быть представлено описание структуры системы, способы взаимодействия со смежными системами, подробное описание процесса передачи данных и так далее. Данный вид технической документации предназначен для разработчиков, которым в будущем предстоит осуществлять доработку или модификацию отдельных компонентов Системы.
-
«Описание постановки задач» - данный документ целесообразен, если функциональные требования в Техническом задании были описаны не достаточно детально.
-
«Описание организации информационной базы» - данный документ обычно включает логическое описание базы данных (БД) Системы. Документ предназначен для разработчиков БД.
Эксплуатационная документация обычно включает «Руководство системного администратора» и «Руководство пользователя». Если в Системе присутствует несколько основных пользователей, руководство пользователя пишется отдельно для каждого из них.
Перечень технической документации создаваемой для заказчика оформляется в документе «Ведомость технического проекта».
При составлении плана проекта менеджеру проекта предстоит согласовать состав пакета технической документации с заказчиком. Далее следует согласовать с ведущими разработчиками проекта и аналитиками вид документации, необходимой им для понимания требований к системе.
| След. » |
|---|