BoatmansHome: Заметки/ФорматРешениеДокумент ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

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


Начнем чуть сбоку, с информации и продолжим определениями.


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


Данные – сведения, представленные в определенной знаковой системе и на определенном материальном носителе для обеспечения возможностей хранения, передачи, приема и обработки.


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


К перечисленным выше сущностям примыкают еще такие:
* Шаблон – это формат для документа/артефакта в целом.
* Нотация – синоним для формат. Но в ИТ чаще применяется по отношению к графическим моделям и к сложным формальным машиночитаемым текстовым конструкциям.
* Артефактдокумент, часть документа, информация в базе данных. С развитием технологий кроме документов в управлении решениями проекта стали участвовать базы данных и понадобилось как-то все это обозначать.
* Элемент (в нашем обсуждении) – часть документа или базы данных. Например, «вариант использования» в смысле «строка перечня вариантов использования». Формат чаще применяется к элементу документа, или артефакта, в то время, как нотация или шаблон к документу или артефакту в целом. Но это не так строго.


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


Когда все со всеми договорились и у нас есть конкретная методология выполнения проекта: за каждым видом документа (а так же элементом или артефактом) закреплены конкретные отражаемые виды решений, представленные в конкретном формате.
Например в машиностроении «чертеж общего вида» – это вполне ясный вид документа, определенного в жизненном цикле машиностроительного изделия (ГОСТ 2.103–68), выполненный по определенным правилам машиностроительного черчения (ЕСКД), отвечающий на вполне конкретные вопросы (документ, определяющий конструкцию изделия, взаимодействие его составных частей и поясняющий принцип работы изделия, см. ГОСТ 2.118–73..2.120–73).
То же самое можно сказать о RUP vision document, закрепленном в жизненном цикле системы и имеющем шаблон в RUP конкретной версии.


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


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


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


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


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]