В этой статье мы разберем как проектировать ИС
Почему бы и нет? Это хороший пример. Проект везде проект: примерно те же стадии, схема управления, документооборот, работа с рисками, контроль качества и так далее. Везде есть требования к оборудованию, помещениям и ПО. Например, расположение рабочих мест операторов, сервера — и тем и другим потребуется кондиционер. Вот и требования к помещениям. И вряд ли кто-то сомневается, нужно ли больнице ПО. Если хотите идти в ногу со временем, перед вами встанет задача создать автоматизированное лечебное учреждение с электронными медицинскими картами, где врачи делают осмотр с планшетами, а санитарки отмечают вымытый туалет не на листике, а в телефоне. Требований к ПО будет предостаточно. А как только потребуется ПО, появится необходимость установить сервера, куда-то посадить админа и операторов. Все взаимосвязано.
Мы выбрали строительный проект, потому что на нем проще всего продемонстрировать, как спроектировать ИС. Информационная система скрыта где-то внутри, мы ее не видим, а стены — вот они перед нами: кривые и косые, с тупиковыми коридорами, потому что проект был сделан на коленке, да еще и заказчик свои требования менял сто раз по ходу пьесы.
Не программное обеспечение вы разрабатываете. Возьмем Android — это ПО. А если перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.
Отличие очевидно. Если вы купили телефон — все просто: включаете его, запускается Android, пользуетесь. А если вы приобрели бухгалтерское ПО, то теперь необходимы сервера, надо настроить сеть, сконфигурировать рабочие станции, обучить сотрудников, интегрировать систему с остальными ИС предприятия, протестировать систему. В любом IT-проекте 10-20% — это IT, а все остальное — организационные и административные меры, и очень плотная работа с персоналом.
Вспомним определение системы из 90-х годов, которое никто не отменял:
Автоматизированная система: система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.
ИС — это люди, плюс технология, помогающая автоматизировать их деятельность, и никак не наоборот.
Представим, что вы строительная организация, к вам приходит заказчик и просит построить больницу. Вы сразу побежите класть кирпичи? Если смотреть на то, как зачастую создаются Информационные Системы, то так и есть: исполнители тут же начинают "мешать бетон и закупать стеклопакеты". Мол, выйдет не так — перестроим! Однако, если вы серьезная организация, то сперва предложите заказчику ПРОЕКТ строительства.
Почему с Информационной Системой не так? Может, дело не в различиях между строительством и разработкой ПО, а в том, что в случае больницы сначала много думают, планируют, а потом строят, а ПО сначала разрабатывают, а затем думают?
Рассмотрим процесс проектирования подробнее. В нем несколько стадий. Зачем нужно проходить несколько этапов? Приведем школьный пример… Сколько лет в школе изучают умножение? Месяц-два? Нет, почти все школьные годы! Получается, мы одно и то же умножение изучаем каждый год под разными углами.
Так и проектирование. Сначала осознали, какую проблему должны решить с помощью ИС. Затем определили круг задач, поняли, ЧТО должна делать система, какие действия должен выполнять персонал. Потом продумали, КАК система должна выполнять задачи. Эти этапы можно перескочить, но придется возвращаться и все переделывать.
Приведем пример. Вы на вершине горы смотрите вниз в бинокль и пытаетесь составить детальный маршрут спуска. В окуляры можно рассмотреть каждый камешек, но та ли это тропинка и ведет ли она на вершину, не видно. Разумный альпинист сначала наметит пути спуска, а затем будет рассматривать их под увеличением. Как только вы окунаетесь в детализацию, теряете общий взгляд на проект.
Сложность поэтапного проектирования в том, что в начале приходится оперировать абстрактными понятиями. Так хочется «пощупать» что-то готовое, а не говорить о требованиях, функциях, задачах. Нарисовать сразу интерфейс проще, но можно упустить половину требований. Если же сначала составить детализированный список операций, дизайнеру останется только нарисовать, а не фантазировать.
Допустим, вы — проектант. К вам приходит заказчик, просит разработать проект больницы. Вы сразу к чертежу? Нет, вы начинаете задавать кучу "глупых" вопросов. Главный из них — зачем нужно строить больницу? Какова цель? Если цель не ясна, вы не сможете ответить, большая это больница или маленькая, какого профиля, чем оснащенная.
Цель проекта обычно определяется на основе противопоставления: описывают существующую информационную модель (например, люди перебирают бумажки в архиве), затем — ее недостатки, и предлагают решение (внедрить ПО). На данной стадии необходимо определить, какие требования законодательства учесть, как юридически оформить операции, как монетизировать сервис, как заинтересовать участников системы.
Составление бизнес-модели. Это не задача разработчиков, но без четкого определения цели и способов ее реализации непонятно, какие задачи должна решать система. Если заказчик сам не сформулировал, что ему нужно, вряд ли он будет доволен результатом.
На данном этапе необходимо выбрать общие технические решения: будет ли это веб-приложение или нативное, толстый клиент или тонкий, централизованная база или распределенная, реляционная СУБД или noSQL, монолит или микросервисы, Java или Python. Если не обсудить это вовремя, то программист может самостоятельно выбрать инструмент, который в итоге не позволит достичь цели.
Составили общие требования к больнице, выбрали концепцию. Теперь можно чертить? Нет, требования нужно детализировать. Например, если нужна лаборатория по анализу крови, какое будет оборудование, сколько оно потребляет электроэнергии? Без этого проектировать будет сложно. Также необходимо прописать план строительства и подготовки больницы к эксплуатации.
Для ИС разработка ТЗ — центральная часть проекта. ТЗ описывает:
ТЗ содержит функциональные и нефункциональные требования, а также требования к этапам разработки, сдаче-приемке, документации. Важно понимать — мы приводим требования к тому, ЧТО должна делать система, а не КАК.
Миф первый: В ТЗ содержатся требования только к исполнителю.
Реальность: Нет, ТЗ — это то, как создать систему, и в техзадании есть разделы, где можно описать распределение ответственности.
Миф второй: В ТЗ много "воды".
Реальность: Общие сведения о системе нужны, чтобы все члены команды понимали требования одинаково.
Миф третий: Требования к персоналу, серверам, каналам связи лишние.
Реальность: ТЗ описывает, как сделать так, чтобы система заработала, а не только было написано ПО. Организационная часть ТЗ и нефункциональные требования не менее важны.
Перед вами ТЗ на строительство больницы с огромным перечнем требований. Вы смотрите на 100 страниц и не знаете, с чего начать. Но картина постепенно проясняется: нужно столько-то метров под палаты, столько-то под кухню, зону отдыха, лабораторию и т.д. Затем появляются наброски, эскизы, варианты, вы переделываете, меняете помещения местами, ищете оптимальные соотношения. Потом переходите к деталям — чертежи, двери, окна, кабель-каналы, проводка, трубы, вентиляция и т.д.