вторник, 1 мая 2012 г.


Все мы много раз задумывались над тем, откуда берётся то самое электричество, благодаря которому возможна работа твоего компьютера, Интернета, огромного количества всевозможного оборудования, и, конечно, Хабрахабра.

Сейчас у нас есть ТЭЦ, АЭС, ГЭС и довольно большое количество других технологий получения энергии. У большей части из этих технологий есть очень существенные недостатки — это либо значительный вред окружающей среде, либо расход медленно возобновляемых природных ресурсов, либо низкая эффективность. Некоторые технологии кажутся почти идеальными, но только до того момента, пока не знаешь их стоимость.

Но что, если бы у нас появилась возможность найти такой способ получения энергии, который не имел бы всех этих недостатков? И что, если бы он также давал дополнительные преимущества, такие как, например, чистая питьевая вода? И если бы он стоил около ста долларов (около трёх тысяч рублей) на человека и всё необходимое оборудование при этом имело бы очень длительный срок эксплуатации (то есть заплатив единожды $100 можно было бы много лет не задумываться о счетах за электричество и воду), а установить такой комплекс можно было бы в любом месте на Земле?

У нас есть этот способ. И мы скоро будем готовы к производству. Поэтому, если вам интересно, читайте дальше.

(Девочка смотрит на тех, кто не хочет ничего слышать.)

Фотография


Постановка задачи


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

Сущность решения


Известно, что солнечная энергия, доходящая до нашей планеты, примерно в 20000 раз превосходит потребности человечества (см. Энергетика. Проблемы и перспективы. — М.А.Стырикович, Э.Э.Шпильрайн, М: Энергия, 1981, с. 38). Из неё примерно четверть уходит на испарение воды и фактически постоянно более-менее равномерно аккумулируется в атмосфере над любой точкой мира. Стандартная гидроэнергетика принципиально способна использовать только малую часть этой энергии, так как все осадки теряют основную часть своей потенциальной энергии по пути к земле на преодоление сопротивления воздуха и удар об землю. Для того, чтобы использовать эту потенциальную энергию более рачительно, надо собирать воду на той высоте, где она конденсируется, и срабатывать в ГЭС весь перепад высот. Именно это и составляет сущность данного решения.

Интересно, что когда решение уже было придумано, то при поиске похожих идей в Интернете по ключевым словам было неожиданно обнаружено, что ещё в 1919 году в одной из статей гениальный Никола Тесла практически был в полушаге до реализации этой идеи, правильно принципиально оценив необходимый ресурс, но так и не найдя схему для его реализации, для чего всё было готово ещё сто лет назад. Обидно. Если бы он тогда докрутил эту идею, то мы все жили бы совсем в другом мире — чистом, экологичном, изобильном, без войн за нефть, без власти нефтебаронов и так далее… увы, человечество потеряло сто лет!

Как реализовать решение — Аэро ГЭС.

Схема одного из вариантов решения показана на рисунке. Аэро ГЭС содержит нижний бьеф 1, верхний бьеф 2, водовод 3, турбогенератор 4, сетчатые, тканные или плёночные поверхности 5, дирижабль 6 и крепёжные тросы 7.

Схема решения

Дирижабль 6 поднимает поверхности 5 на высоту вблизи или выше точки росы для данных атмосферных условий (обычно это 2—3 км). Там переохлаждённая атмосферная влага начинает активно конденсироваться на поверхностях 5. Дренажная система на поверхностях 5 отводит эту воду в небольшой резервуар (верхний бьеф 2), откуда вода под напором всего перепада высот (2—3 км) поступает по напорному или безнапорному водоводу 3 в нижний бьеф 1 на земле, производя электроэнергию в турбогенераторе 4.

Всю установку можно легко смонтировать в любом удобном для потребителя электроэнергии и воды месте, просто подняв и переместив её целиком с помощью того же дирижабля 6.

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

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

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

Как это работает


С точки зрения генерации электроэнергии всё работает точно так же как и в обычной ГЭС, но у обычных ГЭС есть принципиальные общие недостатки: они требуют значительных капитальных затрат на сооружение плотины, занимают значительные территории под водохранилище, наносят ущерб экологии и обычно удалены от потребителя. Кроме того, всегда существует потенциальная опасность возможного разрушения плотины. В известной мере, все эти недостатки являются следствием сравнительно небольших перепадов высот при огромных объёмах воды, характерных для большинства равнинных рек.

Тем не менее и перепады высот в 2 км, как в Аэро ГЭС, не являются экстраординарными. В мире есть несколькоэлектростанций, работающих с такими перепадами. При этом используют очень простые ковшовые турбины, изобретённые ещё в 1889 г. американским инженером Алланом Пелтоном.

Принципиальным отличием Аэро ГЭС является конденсация влаги из воздуха, что на первый взгляд кажется забавным и практически неосуществимым курьёзом. Тем не менее и тут нет ничего необычного. На свете существует несколькопрекрасно работающих установок, называемых сборщиками тумана. Например, установка для сбора питьевой воды в Чили была испытана ещё в 1987 г. и прекрасно описана со всеми техническими характеристиками.

Что это даёт


  • практически вечную и ничем не ограниченную дармовую электроэнергию и чистую воду для питья и орошения, причём в любой точке планеты, где это надо потребителю
  • минимальный расход места на земле (как под ЭС, так и под ЛЭП), а также возможность использования любых поверхностей (включая огромные территории пустынь, морей, океанов и т.п.)
  • модульность (можно собирать системы любой мощности из стандартных модулей, например, по 1 МВт)
  • мобильность (в том числе и для использования на транспорте, например, для снабжения электроэнергией и водой океанских судов)
  • чистоту и экологичность из-за сравнительно небольших локальных гидропотоков по сравнению с обычными ГЭС и полным отсутствием тепловых, химических или ядерных выбросов в окружающую среду
  • увеличение удельной мощности ГЭС (т.е. мощности на единицу расхода воды) путём использования максимально возможного перепада высот между верхним и нижним бьефом (от высоты конденсации атмосферной влаги до уровня земли)
  • существенно более низкие капитальные затраты на единицу мощности и издержки по сравнению с любыми другими известными видами возобновляемой и невозобновляемой энергетики
  • возможность дополнительного использования для сетевой связи, видеонаблюдения, высотной рекламы, грозозащиты, климатической защиты (например, против ураганов и торнадо в США по берегу Мексиканского залива), регулирования климата (например, отсечением дождей в Питере по дамбе при преобладающей юго-западной розе ветров), ПВО (например, для Израиля), затенения в жарких странах и многое другое…


Технико-экономические расчёты


Работоспособная установка может быть даже портативной. Например, турист или дачник может соорудить это просто в виде параплана или воздушного змея, причём в промозглом Питере, откуда мы родом, это начнёт давать воду уже с высоты полкилометра. :)

На самом деле, есть сайты и расчётные модели, которые позволяют даже рассчитать высоту точки росы в любой реальный момент времени в любом месте планеты по аэрологическим диаграммам. Кроме того, есть и прекрасныетеоретические модели, разрабатываемые в Гатчине нашими физиками В.Г.Горшковым и А.М.Макарьевой. Для расчёта турбины можно использовать сайт М.Н.Розина.

По данным чилийской установки такие сетчатые поверхности давали от 3 до 13 литров с квадратного метра в сутки. Учитывая, что в Чили установки были полностью пассивными, а мы можем активно управлять Аэро ГЭС, меняя положение поверхностей 5 по высоте (для максимальной конденсации) и ориентации на ветер (для максимального потока атмосферной влаги), можно надеяться, что выход воды будет значительно увеличен. Но даже приняв его для простоты на том же уровне ~ 10 л/м2/сутки, мы получаем, что всего лишь кусок нейлоновой сетки 10 х 10 м (100 м2) полностью обеспечивает потребности одного человека в воде (~1000 л/сутки) и бытовой электроэнергии (~150—200 кВт-час/месяц).

Прикинем, например, технико-экономические данные небольшой Аэро ГЭС для посёлка в 100 человек. Такая установка будет давать воды до 100 м3/сутки (1.16 л/с) и иметь мощность 20—50 кВт (в зависимости от высоты подъёма).

Пусть минимум — высота 2000 м, 20 кВт — 10000 м2 сети (100 х 100 м)
Цена нейлоновых сетей от $0.5/м2, вес от 10 г/м2 — $5000, 100 кг
Аэростат 500 м3 (водород, примерно как в блокадном Ленинграде) поднимает 500 кг — оболочка пусть $2000, водород всего $10 (по $2/кг) — гелий бы стоил около $5000.
Шланг нужен внутренним диаметром всего 3 мм, скорость воды в нём 200 м/с (примерно то же самое, что и на вышеупомянутой швейцарской ГЭС), вес всей воды в шланге 10—20 кг (в зависимости от геометрии).
Общий вес воды в шланге, на сетях и в верхнем резервуаре — пусть 100—200 кг
Простейшая ковшовая турбина + генератор на 20 кВт + нейлоновые тросы и прочее — пусть ещё $3000

Итого даже при такой предельно малой мощности имеем:
Общая цена ~ $10000 (по $100 с каждого жителя посёлка), вес 200—300 кг при грузоподъёмности аэростата до 500 кг. Удельная капиталоёмкость $500/кВт. Издержки близки к нулю.

Для сравнения

  • самые дешёвые в сегодняшней энергетике ТЭЦ с газовыми турбинами ~ $500—700/кВт при самых больших издержках ~ 5 центов за кВт-час,
  • обычные ТЭЦ ~ $1500/кВт при издержках ~ 2.5 цента за кВт-час,
  • ГЭС ~ $1000—3000/кВт при издержках ~ 0.5 цента за кВт-час,
  • АЭС ~ $5000/кВт при издержках ~ 2.5 цента за кВт-час.


Ясно, что при увеличении мощности, показатели должны только улучшаться. Для типичных мощностей в сотни и тысячи МВт, можно ожидать снижение удельной капиталоёмкости до $200—300/кВт.

Итого


Аэро ГЭС может решить все энергетические проблемы человечества и заодно решить огромные социальные пробемы. Примерный рынок: как минимум 7 млрд. людей на планете по $100 = 700 млрд. Если кто-то хочет начать производство, осчастливить человечество и заодно стать самым богатым человеком на Земле — пожалуйста, пришлите мне сообщение. :)

Да, у нас скоро будет сайт по адресу airhes.com. Там пока что только небольшой текст, но скоро там будет статья на английском, переключение языков, различная информация и так далее. Поэтому, если интересно — то следите за событиями, скоро будет интересно. :)

Posted by Автор: mp3user на 01:34
Categories:

0 коммент.  

суббота, 28 апреля 2012 г.



Введение


Кому не приходилось изготавливать печатную плату? Дело это не очень сложное, а результат придаёт проекту завершённость. В этом посте я бы хотел рассказать о процессе создания печатной платы на дому. Я опишу фоторезистивный метод создания платы. Он довольно прост в применении и позволяет печатать весьма сложные платы. Более того, я обошёлся струйным принтером.

Пост содержит фотографии, видео и схемы.

Идея фоторезистивного метода очень проста. Медь на печатной плате сверху покрыта специальным веществом. Если на это вещество попадает свет, то оно потом растворяется в проявителе. Если свет не попал, то в проявителе вещество остаётся красителем. Процесс изготовления платы состоит из четырёх частей:
1. Создаём прозрачную маску на которой размечено что с чем соединять
1. Светим на плату с веществом через эту маску
2. Бросаем плату в проявитель: на плате окрашены только места, размеченные на маске
3. Бросаем плату в травитель: он съест всю медь, кроме окрашеной

Создание схемы


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

В рамках этого поста мы будем делать довольно простое устройство: плату, разводящую контакты для ATTiny. Так, чтобы можно было воткнуть в плату чип, питание и программатор. 
Сначала нарисуем простенькую схему, а потом, нажав «Switch to board» расположим компоненты на макете платы.




Схему и разводку платы можно увидеть тут.

Печать макета


Подготовим макет к печате. Надо убедиться, что включены только слои с Bottom, Pads, Vias, Dimension. В меню печати надо включить Mirror и Black. Таким образом макет будет отражен и напечатан лишь черным цветом. Не знаю, есть ли более удобный способ, но я распечатал макет в PDF, сконвертировал PDF в TIFF с довольно прилиным разрешением, а потом в текстовом редакторе размножил картинку, чтобы заполнить лист: 


Отмечу, что я печатал две схемы, одну – на сегодня, а другую – на потом.

Документ готов. Печатаем на прозрачной плёнке. Я использовал плёнку от MG Chemicals. Хоть она и предназначена для лазерных принтеров, я использовал свой струйный Lexmark. Минус: чернила легко смазать рукой. 

Подготовка платы


Очевидно, что для фоторезистивного процесса необходима плата, покрытая специальным веществом. Можно купить это вещество и покрывать плату самому, но я решил купить готовую. Вырежим из платы кусочек, соответствующий размерам схемы. Я использовал аппарат Dremel для вырезания:


Экспонирование


Всё готово для экспонирования платы. Опыт показывает, что струйный принтер может не дать нужной плотности (то есть чёрный с виду на самом деле будет пронизан мелкими дырочками). Бороться с этим не сложно: можно совместить два или три слоя распечатки. Вот так: 


Снимем с платы защитный слой (белая тонка плёночка) и положим её на основу (книжка по электронике даёт +3 к удаче). Плату укроем плёнкой с распечаткой и прижмём это дело стеклом:


Конструкция должна простоять под сильной лампой минут 10:


Проявка


Пока плата экспонируется, разведём проявитель. На коробочке проявителя написана пропорция и рекомендуемая температура. Я взял проявитель от MG Chemicals. Он разводится в любой пластиковой посудине в соотношении 1 к 10:


Проявитель готов, десять минут уже прошло. Берём плату и кидаем её в проявитель:


Получится что-то вроде этого:


Травление


Споласкиваем плату в воде и кидаем её в травитель. Я использовал хлорное железо от MG Chemicals. Рекомендуемая температура – 50° C, но я травил при комнатных 25° С. Травилось минут 20:
 
Получится что-то вроде этого:


Зачистка


Оставшийся краситель легко удаляется спиртованными тряпочками:


В результате остаётся чистенькая плата:


Отверстия


Дыры дырявить просто. Я использовал тот же аппарат Dremel:


Получается почти уже готовая плата:


Компоненты


Цепляем на плату необходимые компоненты и припаиваем их к медной основе:


Результат


Плата получилась что надо, хоть друзьям показывай:


Впрочем, не всем друзьям объяснишь, что это такое…

Безопасность


Процесс изготовления плат этим методом предполагает работу со всякой химической дрянью. 

Во-перых, не сливайте химическую дрянь в раковину или туалет. В интернете много советов о том, что с этой дрянью делать.

Во-вторых эта химическая дрянь портит одежду, оставляет пятна на руках и делает что-то совсем страшное с глазами. Пожалуйста, используйте средства безопасности! К примеру, я использовал резиновые перчатки, очки и передник из шторы для душа:

Posted by Автор: mp3user на 01:15
Categories:

0 коммент.  

пятница, 20 апреля 2012 г.


Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Что такое стандарты на документацию?


В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем 

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов


Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:
  • приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
  • структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
  • пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
  • Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
  • Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
  • администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

Соответственно, в стандарте есть артефакты, наподобие следующего:

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.

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

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо



Любой стандарт хорош уже тем, что он позволяет заказчику и исполнителю говорить на одном языке и дает гарантию, что, по крайней мере, претензий «по форме» к передаваемым результатам у заказчика не будет.

А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.

Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.

Можно смеяться над тем, что создатели стандартов ничего не знали о java или .NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества. 

Как читать и понимать стандарты документации по ГОСТ серии 34



Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:
  • Эскизный проект (ЭП)
  • Технический проект (ТП)
  • Разработка рабочей документации (РД)

Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

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

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

Части (разделы) проектной документации по созданию АСУ

Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.

Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.

Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю. 

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

Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.

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

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

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

На стадии ТП раздел содержит всего один документ «Описание организационной структуры», в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя. Комментарии излишни, я думаю.

Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.

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

Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы — все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.

Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том,какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мыне ставим. Мы эти бизнес-процессы автоматизируем.

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

Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.

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

А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

Варианты использования ГОСТ 34

  1. Полное и точное следование стандарту. Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
  2. Мы просто любим ГОСТы. В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
  3. Нам плевать на документацию, лишь бы все работало. Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями — директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).


Заключение



Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.

Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги!

Posted by Автор: mp3user на 01:30
Categories:

0 коммент.  

 
>