Системный анализ в IT

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

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

Бесков Денис — Состав документов требований

Грубо можно выделить 3 категории документации, окружающих обычную IT-систему/продукт:

1. Предпроектная — создаётся на этапах, предшествующих детальному определению внешних свойств и внутреннего устройства системы.
2. Проектная — содержит основной пакет проектных решений
3. Эксплуатационная — используется для развёртывания, использования и модернизации системы

Какие документы можно отнести к этим категориям?

Предпроектная документация

1. Постановка проблемы
2. Отчёт об обследовании деятельности
3. Концепция системы
4. Бизнес-план
5. BRD / MRD / PRD / FSD
6. Пользовательские требования
7. Техническое задание
8. Технико-экономическое обоснование

Проектная документация

1. Функциональная спецификация
2. Эскизный проект
3. Документ архитектуры системы
4. Технический проект
5. Техническая спецификация

Эксплуатационная документация

1. Руководство администратора
2. Руководство пользователя
3. Руководство разработчика

Кто должен выступать основным автором этих документов при инженерном (а не халтурном) подходе к организации ведения проектов?

• Предпроект — маркетологи, бизнес-аналитики, процессные технологи, менеджеры продукта, системные аналитики.
• Проект — системные аналитики, системные архитекторы, проектировщики подсистем, инженеры-конструкторы.
• Эксплуатация — инженеры-разработчики, технические писатели, инженеры-администраторы, процессные технологи.

Почему это важно?
Это понимание важно потому, что в настоящее время у многих участников малых и средних IT-проектов, зачастую попавших в индустрию «случайно», что особенно характерно для веб-проектов, наблюдается устойчивый стереотип, что документацию перечисленных категорий и видов документов должны создавать технические писатели, прежде всего, и только.

На самом деле это не так, технические писатели могут быть отличными ОФОРМИТЕЛЯМИ документации и могут достаточно неплохо почти самостоятельно справляться с 3-й — эксплуатационной категорией документации, но для того, чтобы создавать документы 1-й и 2-й категорий (а документы сами по себе не являются самоцелью, а являются лишь форматом коммуникации результатов работ), нужно обладать соответствующей квалификацией, согласно перечисленным выше ролям.

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

Если страдает оформление — наймите техписа.

Если страдает содержание — организуйте обучение или наймите профессионалов.

Интересно, является ли «Дзен и искусство ухода за мотоциклом» культовой книгой для тестировщиков и технических писателей?

Подозреваю, что нет. А жаль. Но – пойду спрошу.

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

Тут возникла пара вопросов:
1) Какие организации в России профессионально занимаются аудитом документации? Заключения какого рода они могут дать?
2) Какие международные стандарты описания систем стоит рассмотреть, чтобы они котировались при аудите?

Пока вырисовалось, что нам нужно покрыть следующие темы:

1. Описания системы:

* Описание программной платформы (движка)
- технические требования
- архитектурно-значимые use case’ы
- модель пакетов
- модель компонентов
- модель размещения
- модель хранилища данных

* Описание аппаратно-сетевой платформы (инфраструктуры)

* Описание контент-модели (объекты, атрибуты, связи)

* Описание информационной архитектуры сайта
(страницы, блоки, навигации, сервисы)

2. Руководства:

* Руководство разработчика
- описание назначения компонентов
- принципы повторного использования
- стандарты кодирования
- процедура внесения изменений

* Руководство администратора
- регламенты штатной эксплуатации
- регламенты разрешения внештатных ситуаций
- регламенты внесения изменений в конфигурацию

* Руководство пользователя
- принципиальное устройство системы
- сценарии использования
- частые вопросы
- вопросы поддержки

Microsoft говорит, что они таких стандартов не знают, у них есть только лучшие практики.