Эта статья является продолжением моей статьи «ГОСТ 34-й серии для сисадминов, начинающих фрилансеров и всех заинтересованных». Продолжим наш разговор о советских ГОСТах 34й серии и чем они могут помочь в нелегкой работе над проектами.
Но прежде чем продолжать знакомить со своим видением ГОСТов я хочу сделать несколько уточнений, т.к. у некоторых читателей появилось, на мой взгляд, некоторое недопонимание смысла статьи. Повторюсь, что поводом для написания статьи стала статья (согласен, как-то много статей) про то, как поставить фриланс на коммерческие рельсы и начать получать прибыль. Так вот, данная статья не содержит в себе готовых рецептов уровня «как вести себя с заказчиком». На самом деле, работа над проектом включает в себя работу нескольких специалистов. Тут у нас и продавец (убедить заказчика потратить деньги), тут у нас и эксперт (экспертизы и ответы на технические вопросы), тут у нас и технический писатель (пачки документов вас ждут), тут у нас и инженер (кто-то должен крутить гайки), тут у нас и руководство (а кто будет раздавать затрещины?), тут у нас и юрист (сами понимаете). Наверняка, я упустил еще кого-нибудь. У каждого своя роль, свои задачи, свои методы. Особенность фриланса, отчасти системного администратора и несколько косвенно системного инженера заключается в том, что эти должности в силу тех или иных причин (обычно исторических) объединяют в себе многих из перечисленных специалистов. Иной раз даже всех разом.
Охватить все эти специализации явно невозможно в рамках толкования ГОСТов. Да я и не пытаюсь. Я лишь хочу попробовать помочь при помощи ГОСТа сформировать правильное отношение к проектированию как таковому. ГОСТ можно представить как карту местности. На ней отмечен маршрут и различные объекты, которые будут встречаться по пути. И как совершенно необязательно посещать все достопримечательности, точно так же совершенно необязательно (разумеется, если в рамках проекта нет условия написания документации согласно ГОСТов) соблюдать все. За одним исключением: чтобы из пункта А попасть в пункт Б надо пройти маршрут. Т.е. чтобы завершить проект, необходимо сдать проектируемую систему заказчику. И как раз тут ГОСТ поможет нам. Тут опять подходит сравнение с картой. Только уже скорее не бумажной, а картой в навигаторе с GPS. Вы посмотрели и определили, где находитесь и куда двинуться дальше.
Примерно так. Двинулись
Итак, мы продолжаем. Чтобы освежить в памяти стадии разработки снова приведу рисунок
.png "ГОСТ 34 й серии для сисадминов, начинающих фрилансеров и всех заинтересованных (часть 2)")
В предыдущей части мы с вами рассмотрели три первых пункта. Причем два первых — Формирование требований к АС и Разработка концепции АС — достаточно внимательно. Чтобы подвести некий итог первой части, приведу отвлеченный пример. Допустим, есть некое производство, которое выпускает какой-то замороженный продукт и складирует продукцию на обычный склад, где продукция хранится какое-то время, тает и портится. Очевидно, что это несколько неправильно. Необходимо избавить заказчика от того, чтобы его продукция портилась. Т.е. мы будем автоматизировать вид деятельности «хранение продукта», уж простите за столь нелепую аналогию. Итак, нам нужно сделать так, чтобы замороженный продукт не таял. Значит нам необходима система обеспечивающая холод и имеющая в себе полость для хранения. Ну и т.д. Опрашиваем свидетелей пользователей, находим заинтересованных лиц (кстати, очень важная задача в работе аналитика-проектироващика), убеждаемся в экономической выгоде от подобной автоматизации и т.д.
Все, убедились, что надо. Или что не надо. Внезапно выяснилось, что заказчик расположен на Северном Полюсе и мороза вокруг просто завались, а он просто складывает продукцию на отапливаемый склад. Зачем-то. В общем, на этом данный проект можно закрывать. И еще не начав тратить деньги и трудоресурсы, мы уже пришли к выводу бессмысленности проекта. До начала внедрения (админы, ау, узнаете? как оно бывает, когда наоборот?). Но тут у нас все хорошо. Хранить в холоде надо и естественного холода нет. Заказчик нарезает круги в нетерпении от предвкушения. И мы переходим к концепции. Какие пути могут быть предложены для решения? Например, вырыть яму, засыпать ее льдом, наковырять полостей и складывать продукт туда. Вариант? Почему нет? А еще можно поставить что-то вида дома жителей крайнего севера – из снежных брусков. Внутри будет необходимый уровень прохлады. Вариант? Еще какой. Ну или банальную морозильную камеру, питающуюся от розетки. В общем, смысл концепции сводится к тому, чтобы обеспечить поставленную задачу – хранение замороженного продукта. Помним, что цель и задача совсем не одно и то же. И хранение замороженного продукта никак не может быть целью. Целью будет получение прибыли от того, что продукт не испортился. Надеюсь, это понятно. В общем, вот нам варианты. Посидели, подумали, голову почесали и пришли к выводу, что ничего круче морозильной камеры быть не может.
Еще раз уточню, что на этих стадиях мы учитываем лишь очень очень общие параметры. Технологические. Именно что концептуальные. В конце концов, не тонка ли у нас кишка потянуть подобное. И придя к некоему согласию, начинаем формировать техническое задание на разработку автоматизации хранения замороженной продукции. Надеюсь, теперь понятно, почему две первых стадии крайне важны для успешного ТЗ. Так же очень надеюсь, что из такого вот отвлеченного примера видно, что детальная проработка двух стадий нужна при объемном проекте. Если надо хранить две пачки мороженого, то нужна морозилка размером с кирпич и больше говорить как бы и не о чем. И эти две стадии хоть незримо и наличествуют, но мы через них проскакиваем галопом. Так? На первый взгляд. Почему на первый? Ну хотя бы потому, что сколько времени хранить мороженое вы уточнили? Или предположили? Или даже не подумали? То-то.
Следующая, третья стадия — «Техническое задание»
К сожаление, т.к. тема создания Технического задания слишком объемная, я ее отложу и на этот раз. Напомню только, что ТЗ является основным документом, определяющим требования и порядок создания автоматизированной системы. Т.е., если мы посмотрим на вышеизложенное как на нечто графическое, то увидим модель, которую я упоминал в первой части, «от общего к частному». Замечаете это движение? Надеюсь, что да. Чем-то напоминает инкапсуляцию уровней в OSI модели, верно?
Итак, переходим к стадии четыре — «Эскизный проект». Что это такое? Эскизный проект это, согласно ГОСТ 34-601-90, разработка предварительных проектных решений. Нужен лишь в очень крупных проектах, поэтому даже такой строгий документ как ГОСТ допускает пропускать эту стадию. Эскиз нужен в том случае, если заказчик сомневается в том, что ему разрабатывают именно то, что надо. Например, если мы проектируем внедрение Exchange, то тут можем рассматривать варианты различных подсистем (например, использование кластерных технологий и т.п.). Или, если вернуться к примеру с холодильником, что холодильник будет прямоугольной формы с дверцей. В общем, цель этой стадии уберечь о провала (и, следовательно, потерь) последующие стадии. Но необходимость в этом крайне и крайне редкая. Результатом работы является разработка документации (не забыли, что мы все еще проектируем? Т.е. никто отверткой ничего не крутит) на части разрабатываемой АС и пояснительная записка к эскизному проекту
Теперь давайте посмотрим на следующую стадию.
Стадия пять — «Технический проект». Согласно ГОСТ 34-601-90, в этой стадии нам предлагается выполнить несколько этапов.
• Разработка проектных решений по системе и её частям.
• Разработка документации на АС и её части.
• Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.
• Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
Что же от нас хочет ГОСТ в этой стадии согласно этих этапов? А хочет он от нас буквально следующее: мы должны разработать проектное решение на систему и ее части. Т.е. если мы разрабатываем автоматизированную систему на базе Exchange, то тут мы проектируем решение касающиеся исключительно самого Exchange. Т.е. какая версия, как будет установлен (в рамках системы, а не инфраструктуры) и т.д. Части – это, например, отдельные решения для Front-End и Back-End. Или, если вернуться к полюбившемуся мне холодильнику, это проектирование из чего будет состоять холодильник, где компрессор, где трубочки, где морозильные камеры (в составе холодильника) и т.п. Где будет стоять холодильник, прошу заметить (в прихожей или на кухне) в этой стадии не рассматривается.
Разрабатываем комплект документов на АС и ее части. Т.к. ГОСТы структура иерархическая, то для документов, разрабатываемых на различных стадиях существует отдельный ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем». Его мы рассмотрим, так уж складывается, позже. В нем указывается какие документы и на каких стадиях создаются. Т.к. тема тоже несколько объемная, я ее затрону в другой части
Этап разработка и оформление документации на поставку изделий для комплектования АС и технических требований на их разработку подразумевает, что если необходимо уточнить какие либо моменты для комплектования АС, это надо сделать. Например, если мы ставим Exchange на кластер, нам вполне может потребоваться частное ТЗ (не путать с основным ТЗ) на разработку кластера. Т.е. в сложном проекте на стадии технического проектирования системы мы можем дробить (от общего к частному) проект на более мелкие части.
Этап разработки заданий на проектирование в смежных частях проекта объекта автоматизации подразумевает задания на привлечение подрядчиков или выполнение работ, напрямую с проектированием АС не связанных. Например, прокладка витой пары или, если опять же вернуться к холодильнику, вырубка в стене ниши для его установки. Замечу, что тут важно понимать, что в техническом проекте мы разрабатываем общую часть. Т.е. если нам надо вырубить нишу, мы это отражаем в задании технического проекта. Учитываем различные нюансы. Если лично мы некомпетентны в подобном, то в задании указываем необходимость проведения экспертизы силами субподряда. Это надо учитывать при разработке основного ТЗ в объемах работ. Т.е. заказчику совершенно необязательно знать (если он допускает привлечение субподряда на уровне договора, само собой, с нашей стороны), что нишу рубить будем не мы сами, но учитывать необходимое время на эти работы необходимо.
Если подытожить, то на стадии «Технический проект» мы проектируем именно систему. И учитываем задачи, которые потребуются нам дальше при внедрении. В итоге у нас получается пакет проектных документов на АС. Которую мы можем установить у заказчика в различных филиалах (если это входит в проект), где мы столкнемся с местной инфраструктурой и наведем с ней мосты дружбы. Ведь на каждой площадке она может быть своя. А вот как система будет дружить с инфраструктурой заказчика рассматривается на следующей стадии — «Рабочий проект». Там мы будем знакомиться с документами для подготовки к вводу в действие и т.д. Ввиду очевидной близости стадий «Технический проект» и «Рабочий проект» ГОСТ 34-601-90 великодушно разрешает объединять эти стадии в одну — «Техно-рабочий проект».
Но об этом мы поговорим уже в следующей части…
Очень надеюсь, что вторая часть сделала понимание первой части и вообще идеи, которую я пытаюсь донести, более понятной.
Продолжение следует…
PS. Пытливый читатель может задать вопрос: а на кой черт создавать столько документации? И какая разница, что в ней будет написано, по большому то счету? Все достаточно просто: документация создается для того, чтобы в случае если ее возьмет в руки человек, который не участвовал в проектировании, он сможет лишь прочитав документацию, разобраться и выполнить необходимые действия согласно ранее разработанных инструкций и регламентов. Другими словами, кнопки нажимать дело не особо хитрое. А вот разработка последовательность нажатий – куда более серьезная тема.
Автор: sudden_buben
