Главная » Хабрахабр » [Из песочницы] Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы

[Из песочницы] Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы

Почему именно больница?

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

Информационная система скрыта где-то внутри, мы ее не видим, а стены — вот они перед нами: кривые и косые, с тупиковыми коридорами, потому что проект был сделан на коленке, да еще и заказчик свои требования менял сто раз по ходу пьесы. Мы выбрали строительный проект, потому что на нем проще всего продемонстрировать, как спроектировать ИС.

Программный код внутри (но этого никто не видит)

При чем тут больница, если мы разрабатываем ПО?

А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.

А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.
Отличие очевидно. Не программное обеспечение вы разрабатываете… Возьмем Android, — это ПО. А если вы приобрели коробку с бухгалтерским ПО, то ясно, что теперь необходимы сервера, надо настроить сеть, сконфигурировать рабочие станции, обучить сотрудников, интегрировать систему с остальными ИС предприятия, погонять систему в тестовом режиме. Если вы купили телефон— все просто: включаете его, запускается зеленый человечек (Android), пользуетесь. В общем, в любом IT-проекте 10-20% это IT, а все остальное — организационные и административные меры, ну и очень плотная, ювелирная, работа с персоналом. Да и бухгалтеров надо еще как-то уговорить перейти на новый софт, далеко не все из них готовы к новациям.

Информационная система (разве это только ПО?)

И, наконец, вспомним определение системы еще из далеких 90-х годов, которое никто не отменял:

Автоматизированная система: система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

003-90. ГОСТ 34. Комплекс стандартов на автоматизированные системы. Информационная технология. Термины и определения.
Автоматизированные системы.

То есть, ИС в первую очередь — это люди, плюс технология, помогающая автоматизировать их деятельность, и никак не наоборот.
Представим, что вы строительная организация, к вам приходит заказчик и просит в таком-то месте построить больницу. Вы сразу побежите кирпичи класть или…? Если смотреть на то, как зачастую создаются Информационные Системы, то так и есть: исполнители тут же начинают «мешать бетон и закупать стеклопакеты». Мол, выйдет не так — перестроим! Будем перестраивать, пока не добьемся нужного результата.

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

Без проекта всегда так, даже если этого не видно

В нем несколько стадий. Рассмотрим теперь процесс проектирования подробнее. Для ясности приведу школьный пример… Сколько лет в школе изучают операцию умножения? Зачем же нужно проходить несколько этапов, почему за один раз не сделать? Да, как умножать 5 на 6, проходят за неделю. Вы скажете — один-два месяца, и будете в корне неправы. А умножение дробей, чисел со степенью, логарифмов, выражений в скобках, комплексных чисел, возведение в степень сколько изучают? Еще определенное время учат таблицу умножения. Получается, мы одно и то же умножение изучаем каждый год под разными угл
ами. Почти все школьные годы!

И почему такое не изучают в первом классе?

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

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

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

Видно хорошо, но только малую часть

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

Теперь наконец-то перейдем к рассмотрению стадий проектирования.

1. Составление общих требований

Итак, допустим вы — проектант. К вам приходит заказчик, «посланный» ответственными строителями. Заказчик, естественно, просит вас разработать проект больницы. Вы бежите к кульману и… Ну ладно, это уже древность — запускаете ArchiCAD и чертите.

Вы — профессионал и начинаете задавать кучу «глупых» вопросов. Но конечно речь не о вас. Какова цель строительства. И самый главный из них — зачем нужно строить больницу. К сожалению, заказчики зачастую говорят очень много всего интересного, кроме главного, — какова их цель. Если цель не понятна, то вы не сможете ответить на вопрос, большая это должна быть больница или маленькая, какого профиля, чем оснащенная. И задать вопрос должны вы. Вот это надо «вытащить» из него в первую очередь. Он не понимает, какой путь необходимо пройти для реализации его идеи. Сам заказчик — не специалист, у него есть идея, и на этом он видит свою роль выполненной. Как правило, заказчик ждет старого доброго чуда — прийти на берег моря, закинуть невод (заплатить деньги), выловить рыбку, и она исполнит его желание… А случается как в анекдоте про богатого мужика, который поймав золотую рыбку, попросил выполнить одно желание: «Хочу, чтобы у меня все было!» — «Нет проблем, — ответила рыбка, — у тебя все было...»

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

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

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

2. Выбор концепции системы

На данном этапе необходимо выбрать общие технические решения, с помощью которых могут быть выполнены требования, составленные на предыдущем этапе. Будет ли это веб-приложение или нативное, толстый клиент или тонкий, централизованная база или распределенная, реляционная СУБД или noSQL, монолит или микросервисы, Java или Python. Часто данные вопросы забывают обсудить вовремя, а потом оказывается, что кто-то из программистов самостоятельно выбрал определенный инструмент, а в конце концов данное решение не позволяет достичь поставленной цели.

3. Разработка Технического Задания

Составили общие требования к больнице, выбрали концепцию. «Ну, — скажет заказчик, — теперь все понятно, можно чертить». А можно ли? Требования-то общие, их надо детализировать. Например, на первом этапе вы определили, что должна иметься лаборатория по анализу крови. Но какое там будет оборудование, сколько оно потребляет электроэнергии, сжатого воздуха (а вдруг?), нужны ли кварцевые лампы для дезинфекции, лабораторные столы, вентиляция? Без этого проектировать тяжеловато будет. Это, во-первых. А во-вторых, необходимо прописать план строительства больницы, подготовки и ввода ее в эксплуатацию.

Техническое Задание описывает: Для Информационной Системы разработка ТЗ (Технического Задания) — центральная часть проекта.

  1. ЧТО должна делать система.
  2. Какова должна быть общая структура системы.
  3. Как создать систему.

То есть, ТЗ содержит функциональные и нефункциональные требования, а также требования к этапам разработки, сдаче-приемке, документации. Также в ТЗ должны быть кратко описаны процессы, которые мы собственно автоматизируем.

Для вас должна быть важнее широта охвата, а не глубина. При описании функций системы (а это центральная часть ТЗ) следует понимать — мы приводим требования к тому, ЧТО должна делать система, а не КАК. В ТЗ указали, что учетная запись блокируется при неиспользовании в течение 90 дней или после 6-и неудачных попыток входа, доступ может быть ограничен администратором на определенный срок, при попытке входа заблокированного пользователя необходимо выводить сообщение и т.д. Например, на первой стадии (составление общих требований) мы выявили необходимость наличия функции блокировки входа пользователя. А в техническом проекте (забежим вперед), мы с вами нарисуем макет карточки пользователя с флажком блокировки и датой разблокировки, составим сценарий входа в систему, в котором производится проверка на блокировку, автоматическая разблокировка по истечении установленного срока, блокировка в случае неудачных попыток входа; определим, что выполняется на стороне клиента, а что — сервера.

Хочется развенчать несколько мифов, связанных с разработкой технического задания.

Миф первый: В ТЗ содержатся требования только к исполнителю.

Нет, ТЗ — это то, как создать систему, и в техзадании есть разделы, в которых можно описать распределение ответственности.

Миф второй: В Техническом Задании часто очень много «воды».

Например, мы обсуждали-обсуждали требования к системе, в результате одна команда поняла, что нужно разработать приложение под Windows, а другая — для браузера. Действительно, нередко ТЗ содержит общие сведения о системе, но они нужны. Вроде бы очевидные вещи, но они должны пониматься одинаково всеми членами команды и всеми привлеченными специалистами. Одна думала, что система называется так, а другая — по-другому.

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

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

А пока предлагаю изучить ГОСТ 34. Думаю, подробнее мы рассмотрим составление Технического Задания в другой статье, это достаточно обширная тема. Не пугайтесь этих страшных букв — ГОСТ. 602-89. Изучишь стандарты, и в голове появляется стройная картина, которая впоследствии сослужит вам хорошую службу. Да, сперва может быть тяжеловато, но это как раз из-за постановки мозгов на место.

4. Разработка технического проекта

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

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

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

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

5. Разработка рабочей документации

Логичный вопрос — какая такая рабочая документация для больницы? Неужто инструкция по уборке коридора?! Шутки шутками, а противопожарную систему надо обслуживать? Надо. А лифты? А компьютерные сети? А водопровод? «Ну, это к проекту больницы не относится!» — скажете вы. Да, отчасти это так. Однако больница сдается заказчику как единое целое, и все системы должны иметь соответствующую эксплуатационную документацию. И чтобы сдача была быстрой, успешной, вы составите перечень требований, напротив которых можно ставить галочку, если все в порядке.

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

Одни люди двумя руками за Agile (или иные «гибкие» методы разработки), другие резко против. У автора же статьи свое мнение: Agile очень хорош, но к месту. А используют его обычно не по назначению.

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

Заказчик думает: и сколько меня еще будут по кругу за нос водить?

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

Никто не мешает на уровне оперативного планирования пользоваться спринтами. В-третьих, в большом проекте могут присутствовать этапы, где требуется именно ОКР, и тогда Agile в помощь. На стратегическом уровне — каскадное планирование, на тактическом — итеративное. Наоборот, очень удобная технология: планировать на неделю или две и постоянно контролировать результат. И никаких противоречий!

Они действуют самым удобным для них образом: будем допиливать и допиливать за деньги заказчика. К сожалению, очень часто, «проповедуя» Agile, разработчики пытаются замаскировать свое неумение разработать проект системы (либо даже не знают, что это возможно). Но потом у стороннего наблюдателя (начальства) может возникнуть ощущение, что процесс-то есть, а конца и края, да и результата не видно. Пока расходы никто не контролирует, это вполне сходит с рук. Пытайтесь смотреть не только со своей колокольни.

Книжек на эту тему много. Толстых и не очень. Но книжка — это всегда ЧУЖОЙ опыт. А у вас другой характер, отличная ситуация и проект. Есть такая система ТРИЗ — теория решения изобретательских задач. Ее автор, Альтшуллер, пытается объяснить шаги, которые нужно предпринять, чтобы изобрести что-либо. Получается? Как правило, нет. Принципы излагаются интересные, полезные, но единого шаблона по изобретению не выходит. Каждый человек думает и творит по-своему, да и невозможно этому научить, можно только научиться. Чужой опыт использовать надо, глупо не использовать, но он должен быть пережит (переработан) вами, переложен на ВАШЕ мышление. Скопировать чудо не удастся.

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Проект Keystone: доверенная среда для запуска приложений на базе RISC-V

Команда исследователей из MIT и Калифорнийского университета в Беркли при поддержке Facebook, Google, Microsoft и других ИТ-гигантов представила проект Keystone. Это open source компонент, позволяющий организовать доверенную среду для запуска программ (trusted execution environment, TEE) на базе архитектуры RISC-V. Далее ...

[Перевод] Руководство по Node.js, часть 4: npm, файлы package.json и package-lock.json

Сегодня мы публикуем четвёртую часть перевода руководства по Node.js. В этом материале мы начнём разговор об npm а также рассмотрим особенности файлов package.json и package-lock.json. [Советуем почитать] Другие части цикла Основы npm Npm (node package manager) — это менеджер пакетов ...