Как сделать информационную систему самому
С чего начать разработку Информационной системы?
Добрый день, друзья!
В итоге решил разработать информационную систему для сбора анализа данных сетевой оргтехники для выполнения задач:
Инвентаризация оборудования (хранение сведений о поступлении/перемещении/ремонтах)
Централизованное получение сведений о состоянии оборудования для оператвного заказа и замены расходных материалов.
Вопрос:
С чего начать разработку информационной системы?
Как спланировать работу по разработке?
В голове слишком много вопросов, не знаю с какой стороны подойти:
Сбор данных (есть xls-файл с данными по оргтехнике), Архитектура системы, Проектирование БД, web-интерфейс, функционал, пользователи системы (коллеги в отделе), UI, MOCKUPы, где и как вести планирование и выполнение работы?! Блог/GitHub или что-то иное?
1. Сделайте блок-схемы (скетчи, вайрфреймы) каждой страницы приложения на бумаге
2. Сверстайте их
3. Реализуйте постепенно функционал для каждой из них
Начинайте с ключевого функционала, что б не застрять на регистрации, авторизации, смене пароля, правах доступа, оптимизации и т.д.
Ну и там всякие сложности, может ли оборудование иметь топологические отношения. Нужен ли учёт портов (сетевых электрических и тд), влан, клиентов на оборудовании, взаимодействие с самим оборудованием из интерфейса системы, продолжать можно очень долго, и большинство из этого вам не нужно ^^
Как сделать информационную систему самому
Вопросительный знак стоит не даром. Это действительно проблема, которую приходится решать в большинстве современных предприятий, независимо от того, какого рода бизнесом они занимаются. Термин «информационная система» относится к классу программных продуктов, облегчающих, или «автоматизирующих» ведение бизнеса. Система называется «информационной», если она поддерживает информационную поддержку бизнеса (любой деловой человек знает, сколько сил и средств уходит на поддержание необходимой информации). Соответствующая программа называется «системой», если она (в некоторых случаях последовательно, а иногда параллельно) выполняет более одной функции (одним из распространенных примеров являются информационные системы, поддерживающие ведение складского хозяйства: они отслеживают поступление товаров на склад, отпуск товаров покупателю, а также контролируют наличие на складе необходимого количества каждого продукта).
Второй важной особенностью СУБД является обеспечение выполнения так называемых «незапланированных (ad hoc)» запросов к базе данных. Представим себе, что при проектировании информационной системы, предназначенной для автоматизации управления складом, было запланировано выполнение запросов о наличии на складе товаров, операций модификации данных при отпуске товаров со склада и их получении, а впоследствии понадобилась информация об общем объеме поставок от данного поставщика. При отсутствии СУБД понадобилась бы переделка информационной системы. Однако СУБД, обладая достаточными знаниями о предметной области (например, о структуре и смысле данных складской информационной системы), может обеспечить (и реально обеспечивает) универсальный язык запросов (обычно, язык SQL), позволяющий сформулировать произвольный запрос на выборку информации из соответствующей базы данных. Такой запрос может быть в любой момент подан с терминала (без участия информационной системы) или встроен в одну из прикладных программ, входящих в информационную систему.
Итак, современные СУБД предназначены именно для разработчиков и последующих пользователей информационных систем. Однако достаточно ли этих базовых программных средств? Достаточно часто проблемой является проектирование и разработка информационной системы даже в том случае, если система опирается на какую-либо современную СУБД. Приходится решать задачи трех видов: проектирование и разработка логической структуры самой информационной системы как набора программ; проектирование лежащей в основе общего проекта информационной системы базы данных; проектирование и разработка интерфейсных подсистем, как тех, которые относятся к взаимодействиям информационной системы с конечным пользователем, так и тех, которые связывают прикладные программы с СУБД. Если проектируемая информационная система достаточно сложна (а это обычное явление), то решение этих задач «вручную», без привлечения программных инструментальных средств, как правило, превышает человеческие возможности.
К нашему с вами счастью о нас (по крайней мере, частично) позаботились софтверные компании, которые производят средства, служащие инструментом при проектировании и разработке информационных систем. Конечно, прежде всего это системы класса CASE (Computer Added Software Enginering), ориентированные на поддержку разработки информационных систем. Наиболее развитые CASE-системы позволяют автоматизировать процесс проектирования и разработки прикладной системы, поддерживая полную документацию (возможно, с разными версиями) обо всем этом процессе. Может быть, наиболее важно то, что такие системы существенно помогают создавать схему базы данных, лежащей в основе проекта информационной системы. CASE-системы позволяют естественно (и достаточно просто) пройти путь от интуитивного представления структуры и поведения нужной предметной области до формализованного представления в терминах языка SQL. Такие возможности CASE-систем может оценить каждый, кому приходилось вручную проектировать схему достаточно сложной базы данных.
Другой класс программных средств (часто интегрированных с CASE-системами) составляют программные системы языков четвертого поколения (4GL). Это, может быть, чересчур громкое название означает лишь то, что такие, как правило, интерпретируемые языки предоставляют пользователю более или менее удобные средства для формирования интерфейса с конечным пользователем (например, в виде меню или форм), обеспечивают сравнительно простые возможности для взаимодействия с системой управления базами данных, а также предоставляют (обычно, достаточно примитивные) средства программирования. Основным достоинством языков четвертого поколения является то, что они обеспечивают возможность так называемого «быстрого прототипирования приложений (rapid prototyping)».
Это означает то, что при использовании 4GL можно действительно быстро соорудить работающий прототип будущей системы, обеспечивающий требуемый интерфейс с конечным пользователем и взаимодействующий с макетом базы данных (а возможно, и с реальной базой данных, если она к этому времени подготовлена). Приходится говорить про «прототип», поскольку большинство современных систем 4GL не обеспечивают той эффективности прикладных систем, какую дают обычные языки программирования (как теперь принято выражаться, 2GL или 3GL). Вместе с тем, стоит заметить, что уже существует масса реально используемых информационных систем, разработанных исключительно на том или ином 4GL. Кто знает, что будет завтра, но тенденция к увеличению использования 4GL очевидна.
Заметим, что в последнее время подавляющее большинство CASE-систем и 4GL если не ориентируется, то обращает внимание на объектно-ориентированный подход. Более того, стали появляться методики по объектно-ориентированному использованию средств автоматизированного проектирования и разработки информационных систем, которые (средства) исходно для этого не предназначались. Коротко отвечая на вопрос, заданный в заглавии, скажем, что сегодня создателю информационной системы, как минимум, нужно иметь базовые знания о современных СУБД, ориентироваться в мире инструментальных средств разработки программных систем и иметь представления об объектно-ориентированном подходе к проектированию и разработке программ. Конечно, при этом неплохо еще уметь программировать :-).
Как создать базу знаний, чтобы она стала «интеллектуальным активом» компании
Создавая базу знаний, каждый преследует свои цели и решает свои проектные задачи, использует свои инструменты и программные средства. Однако для чего бы и с помощью чего бы не создавалась база знаний, она обязательно должна приносить компании максимальную пользу. Как этого добиться?
В сентябре 2020 года я выступила спикером IV-й конференции «Управление корпоративными знаниями», проходившей в рамках недели корпоративного обучения. Мой мастер-класс «Как создать корпоративную базу знаний, чтобы она стала «интеллектуальным активом» компании» заинтересовал собравшихся, и я решила сделать из материалов выступления статью. Буду рада если текст поможет вам в работе. Буду рада, если кто-то из вас захочет в комментариях обсудить этот пост.
Источник
Универсального сценария «Как создать базу знаний», который бы подходил всем и всегда, нет и быть не может. Обусловлено это как разными подходами к организации баз, так и разными IT-инструментами. А вот общие требования, своеобразный cookbook, – как раз предмет моей статьи.
Опыт большого многоуровневого проекта поддержки информационной системы позволяет выделить три основных принципа, лежащих в основе любой успешной базы знаний. Она должна быть:
Написать понятно для всех
Текст статьи из базы знаний должен быть понятен всем, кто будет её читать. Притом понятен с первого прочтения, ибо скорее всего второй раз её читать просто не будут. Статья не должна быть слишком длинной или чрезмерно короткой. Материал должен быть изложен так, чтобы трактовки его содержания были однозначными, и не нужно было переводить с «бухгалтерского» или «IT-шного» на «человеческий».
Например, статья, описывающая решение типовой проблемы, написанная в стиле «… перед входом в личный кабинет очистите кэш», скорее всего вызовет вопросы, а вот если дополнить его алгоритмом очистки кэша, написанным «для вашей бабушки», то ответ будет понятен всем.
Ситуация становится острее, когда база знаний используется как FAQ для внешних пользователей, уровень подготовки которых разнится от бабушек и дедушек, которые не смогли освоить смартфон, до суперпрофессионалов этой области.
На первый взгляд, кажется, что достичь этого невозможно: если статья написана для «чайника», то погруженному в тему она будет избыточной, а если ориентироваться на профи, то «чайнику» потребуется «перевод». Как быть?
Есть много инструментов, помогающих решить проблемы. В Департаменте корпоративных систем ЛАНИТ мы используем три подхода.
1. Ревью от ведущего эксперта предметной области. Процесс направлен на повышение качества материалов базы знаний (далее БЗ). Суть в том, что эксперт проверяет корректность изложения материала, в том числе логичность и последовательность изложения.
2. Обратная связь от пользователей в виде оценки и предложений по расширению/сокращению/изменению формулировок, порядка изложения/структурирования и т. п. по результатам использования материала. Обратную связь могут оставить все заинтересованные. Предложения и пожелания прорабатываются. Технически это может быть реализовано в виде оценок ответов от пользователей, лайков, благодарностей и т. п.
3. Структурирование. Этот инструмент условно можно разделить на два типа воздействий:
Всегда актуально
Однажды разместив информацию в базе знаний, нужно всегда поддерживать её в актуальном состоянии. У всех пользователей базы знаний всегда должно быть доверие к материалам, размещенным в ней.
По сути, knowledge manager должен иметь свою систему мониторинга, в которой будут свои триггеры и четко описанные алгоритмы реагирования.
Например, для базы знаний службы поддержки информационной системы триггером будет служить выход новой версии, изменение законодательства и т. п. Разработка набора триггеров и действий при их наступлении, а также определение ответственных за их выполнение – задача, решение которой обеспечивает значительную долю успеха базы знаний.
Сработавший триггер означает, что нужно оперативно скорректировать материалы. Для того, чтобы обновление не стало кошмаром, на этапе размещения материалов необходимо продумать, как оптимизировать количество статей и при необходимости автоматически отбирать нужные по заданным параметрам.
В качестве инструмента, позволяющего осуществить автоматический отбор статей, мы используем классификаторы и статусы (статусная модель с определенным алгоритмом переходов). При этом сложная задача – создание классификаторов так, чтобы их состав был достаточным, но не избыточным.
Пример статусной модели:
Как не создать информационную «мусорку» вместо базы знаний
Статьи, отвечающие на неактуальные вопросы или имеющие узко сформулированные заголовки, – путь к созданию информационной «мусорки» вместо базы знаний. Заголовок, сформулированный недостаточно широко, означает, что в нужный момент найти такую статью смогут только те, кто знает, что она есть в базе знаний. Остальные начнут решать задачу с нуля и создадут на основании этого решения статью-дубль.
Например, заголовок «Шаблоны заявлений» вполне корректен, но сформулирован узко. Искать будет легче, если добавить в него ключевые слова и написать так: «Шаблоны заявлений: отпуск, отгул, удаленная работа, увольнение, перевод».
Решить проблему помогает статистика использования материалов базы знаний. Опираясь на статистику использования, мы можем найти редко используемые и либо отправить их в архив (если материал утратил актуальность), либо расширить, обеспечив популярность в дальнейшем.
Статьи, собранные по принципу Lego из констант и переменных, снижают затраты на базу знаний
Есть правило, к которому мы пришли не сразу, но которое значительно экономит время на поддержание актуальности базы знаний. Это правило – никакого дублирования! Информация фиксируется один раз, далее используются ссылки на нее. Технически есть масса возможностей «вживлять» константы в нужные места по тексту статьи так, чтобы читатель даже не знал о том, что статья как конструктор состоит из частей.
Почему «не летит»
Даже самая актуальная база знаний, содержащая ответы на все востребованные вопросы, может «не взлететь», если найти нужную информацию сложно.
Решить проблему поиска можно структурированием и многоуровневой классификацией. Причём классификация должна быть не только на уровне разделов каталога БЗ, но и с метками по разным тематикам (например, если у нас база знаний службы поддержки пользователей, то по темам, личным кабинетам и т.д.). Каждый пользователь может отобрать перечень статей по заданным критериям, используя форму расширенного поиска.
Для того, чтобы поиск был максимально качественным для конкретного пользователя в базе знаний реализована ролевая модель доступа. Это, во-первых, решает вопрос потенциальной утечки информации: пользователю доступны только те материалы, которые подходят ему по роли в проекте или в организации в целом, а, во-вторых, сужают перечень материалов, среди которых производится поиск, повышая качество результатов.
Мобильность — наше всё
Для мобильности и в силу популярности Telegram дополнительно развиваем чат-бота.
Бот реализован в Telegram и доступен с любого устройства пользователя. Уровень доступа к информации через бот соответствует уровню доступа к сервисам компании. По запросу ответ можно получить в том числе из wiki.
Каждый ответ можно оценить. Система оценок позволяет своевременно корректировать как ответы, так и классификаторы. Вопросы, ответы на которые найдены не были, собираются отдельно и выступают идеями для развития базы знаний.
Рассмотренные принципы – не исчерпывающий список требований к базе знаний, сформулированный за четыре года активной работы над несколькими проектами, в том числе над базой знаний службы поддержки большой государственной информационной системы. Кроме того, следует отметить, что все принципы и правила работают тогда, когда в базе знаний заинтересованы все её пользователи и авторы. Главные метрики для оценки заинтересованности — количество использованных в работе материалов и количество правок от каждого автора. Мой личный список требований постоянно расширяется и в последний год появляется всё больше нюансов к требованию структурирования статей. Охотно поделюсь им в следующей статье.
Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы
Почему именно больница?
А почему бы и нет? Это хороший пример. Проект везде проект: плюс-минус те же стадии, та же схема управления, документооборот, работа с рисками, контроль качества и так далее. Везде есть требования и к оборудованию, и к помещениям, и к ПО. Вы спросите, какие могут быть требования к помещениям в Информационной Системе? Очень просто: расположение рабочих мест операторов, сервера — и тем и другим потребуется кондиционер. Вот уже и требования к помещениям. И вряд ли нынче кто-то сомневается, нужно ли больнице ПО. Если вы хотите идти в ногу со временем, перед вами встанет задача создать автоматизированное лечебное учреждение с электронными медицинскими картами, где врачи делают осмотр с планшетами, а, например, санитарки отмечают вымытый туалет не на листике, а в телефоне. Требований к ПО в данном случае будет предостаточно. А как только потребуется ПО, появится необходимость установить сервера, куда-то посадить админа и операторов. Все взаимосвязано.
Мы выбрали строительный проект, потому что на нем проще всего продемонстрировать, как спроектировать ИС. Информационная система скрыта где-то внутри, мы ее не видим, а стены — вот они перед нами: кривые и косые, с тупиковыми коридорами, потому что проект был сделан на коленке, да еще и заказчик свои требования менял сто раз по ходу пьесы.
Программный код внутри (но этого никто не видит)
При чем тут больница, если мы разрабатываем ПО?
А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.
Не программное обеспечение вы разрабатываете… Возьмем Android, — это ПО. А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.
Отличие очевидно. Если вы купили телефон — все просто: включаете его, запускается зеленый человечек (Android), пользуетесь. А если вы приобрели коробку с бухгалтерским ПО, то ясно, что теперь необходимы сервера, надо настроить сеть, сконфигурировать рабочие станции, обучить сотрудников, интегрировать систему с остальными ИС предприятия, погонять систему в тестовом режиме. Да и бухгалтеров надо еще как-то уговорить перейти на новый софт, далеко не все из них готовы к новациям. В общем, в любом IT-проекте 10-20% это IT, а все остальное — организационные и административные меры, ну и очень плотная, ювелирная, работа с персоналом.
Информационная система (разве это только ПО?)
И, наконец, вспомним определение системы еще из далеких 90-х годов, которое никто не отменял:
Автоматизированная система: система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения.
То есть, ИС в первую очередь — это люди, плюс технология, помогающая автоматизировать их деятельность, и никак не наоборот.
Как спроектировать больницу
Представим, что вы строительная организация, к вам приходит заказчик и просит в таком-то месте построить больницу. Вы сразу побежите кирпичи класть или…? Если смотреть на то, как зачастую создаются Информационные Системы, то так и есть: исполнители тут же начинают «мешать бетон и закупать стеклопакеты». Мол, выйдет не так — перестроим! Будем перестраивать, пока не добьемся нужного результата.
Однако, если вы серьезная организация, то сперва предложите заказчику ПРОЕКТ строительства. Согласны? А почему с Информационной Системой не так? Может, дело не в различиях между строительством и разработкой ПО, а в том, что в случае той же больницы сначала много думают, планируют, а потом строят, а ПО сначала разрабатывают и затем думают? Не потому ли много слышно о криворуких программистах, но ничего о таких же гастарбайтерах на стройке? Строители работают по проекту, в отличие от разработчиков.
Без проекта всегда так, даже если этого не видно
Рассмотрим теперь процесс проектирования подробнее. В нем несколько стадий. Зачем же нужно проходить несколько этапов, почему за один раз не сделать? Для ясности приведу школьный пример… Сколько лет в школе изучают операцию умножения? Вы скажете — один-два месяца, и будете в корне неправы. Да, как умножать 5 на 6, проходят за неделю. Еще определенное время учат таблицу умножения. А умножение дробей, чисел со степенью, логарифмов, выражений в скобках, комплексных чисел, возведение в степень сколько изучают? Почти все школьные годы! Получается, мы одно и то же умножение изучаем каждый год под разными углами.
И почему такое не изучают в первом классе?
Так вот, любой процесс и обучения, и проектирования, цикличен. Сначала мы получили общие понятия о числах, потом научились выполнять с ними простейшие действия, затем узнали про дроби и научились с ними работать, и так далее.
Сначала мы осознали, какую проблему должны решить с помощью Информационной Системы. Затем определили круг решаемых задач, поняли, ЧТО должна делать система, какие действия должен выполнять персонал. Потом продумали, КАК система должна выполнять определенные ранее задачи. Эти этапы можно перескочить, только придется возвращаться обратно и все переделывать: семь раз отмерить и один раз отрезать получается гораздо быстрее, чем наоборот, да и материала уйдет меньше.
Приведем еще пример. Вы на вершине горы смотрите вниз в сильный бинокль и пытаетесь составить детальный маршрут спуска. В окуляры можно рассмотреть каждый камешек на тропинке, каждую лужу. Но вот та ли эта тропинка и ведет ли она на вершину, в бинокль не видно: отсутствует общий план. Разумный альпинист сначала невооруженным глазом наметит пути спуска, а затем их будет рассматривать под сильным увеличением. Как только вы окунаетесь в детализацию, теряете общий взгляд на проект. Взяв сразу подзорную трубу, вы идеально опишите 10 функций, при этом забудете про 40 остальных, вообще про них не упомянете.
Видно хорошо, но только малую часть
Сложность поэтапного проектирования в том, что в начале процесса приходится оперировать абстрактными понятиями. Так хочется «пощупать» что-то готовое, а не говорить о неких требованиях, функциях, задачах, процессах. Нарисовать сразу интерфейс пользователя проще, но и легче упустить как минимум половину требований. Если же вначале составить детализированный список операций, которые должен выполнить пользователь при работе с той или иной экранной формой, то дизайнеру останется только нарисовать, а не фантазировать, как это часто бывает.
Теперь наконец-то перейдем к рассмотрению стадий проектирования.
1. Составление общих требований
Итак, допустим вы — проектант. К вам приходит заказчик, «посланный» ответственными строителями. Заказчик, естественно, просит вас разработать проект больницы. Вы бежите к кульману и… Ну ладно, это уже древность — запускаете ArchiCAD и чертите.
Но конечно речь не о вас. Вы — профессионал и начинаете задавать кучу «глупых» вопросов. И самый главный из них — зачем нужно строить больницу? Какова цель строительства? Если цель не понятна, то вы не сможете ответить на вопрос, большая это должна быть больница или маленькая, какого профиля, чем оснащенная. К сожалению, заказчики зачастую говорят очень много всего интересного, кроме главного, — какова их цель. Вот это надо «вытащить» из них в первую очередь. И задать вопрос должны вы. Сам заказчик — не специалист, у него есть идея, и на этом он видит свою роль выполненной. Он не понимает, какой путь необходимо пройти для реализации его идеи. Как правило, заказчик ждет старого доброго чуда — прийти на берег моря, закинуть невод (заплатить деньги), выловить рыбку, и она исполнит его желание… А случается как в анекдоте про богатого мужика, который поймав золотую рыбку, попросил выполнить одно желание: «Хочу, чтобы у меня все было!» — «Нет проблем, — ответила рыбка, — у тебя все было. »
Чтобы вникнуть в цель проекта, недостаточно составить пару предложений со стандартным набором фраз. Цель проекта обычно определяется на основе противопоставления: описывают существующую информационную модель (например, сидят люди в архиве и бумажки перебирают), затем — ее недостатки (из-за отсутствия автоматизации в архиве задействовано 10 человек, что явно избыточно, другие отделы не могут неделями получить из архива нужную им информацию и т.д.) и предлагают решение (внедрить ПО, которое позволит осуществлять в автоматизированном режиме ряд операций, операции надо перечислить). В случае, если на рынок выводится совершенно новый вид сервиса, то требуется изучить существующий рынок и «покритиковать» имеющиеся там инструменты, затем предложить решение.
Кроме того, на данной стадии необходимо определить, какие требования законодательства необходимо учесть, как юридически оформить те или иные операции, как будет монетизироваться новый сервис, как планируется выходить на рынок, как заинтересовать внешних участников новой системы.
Иными словами, следует составить бизнес-модель. С одной стороны, это как бы и не задача разработчиков, а, с другой, без четкого определения цели и способов ее реализации непонятно, какие задачи должна решать система. А если заказчик сам толком еще не сформулировал, что ему нужно, вряд ли он будет доволен хоть каким-нибудь результатом.
2. Выбор концепции системы
На данном этапе необходимо выбрать общие технические решения, с помощью которых могут быть выполнены требования, составленные на предыдущем этапе. Будет ли это веб-приложение или нативное, толстый клиент или тонкий, централизованная база или распределенная, реляционная СУБД или noSQL, монолит или микросервисы, Java или Python. Часто данные вопросы забывают обсудить вовремя, а потом оказывается, что кто-то из программистов самостоятельно выбрал определенный инструмент, а в конце концов данное решение не позволяет достичь поставленной цели.
3. Разработка Технического Задания
Составили общие требования к больнице, выбрали концепцию. «Ну, — скажет заказчик, — теперь все понятно, можно чертить». А можно ли? Требования-то общие, их надо детализировать. Например, на первом этапе вы определили, что должна иметься лаборатория по анализу крови. Но какое там будет оборудование, сколько оно потребляет электроэнергии, сжатого воздуха (а вдруг?), нужны ли кварцевые лампы для дезинфекции, лабораторные столы, вентиляция? Без этого проектировать тяжеловато будет. Это, во-первых. А во-вторых, необходимо прописать план строительства больницы, подготовки и ввода ее в эксплуатацию.
Для Информационной Системы разработка ТЗ (Технического задания) — центральная часть проекта. Техническое задание описывает:
При описании функций системы (а это центральная часть ТЗ) следует понимать — мы приводим требования к тому, ЧТО должна делать система, а не КАК. Для вас должна быть важнее широта охвата, а не глубина. Например, на первой стадии (составление общих требований) мы выявили необходимость наличия функции блокировки входа пользователя. В ТЗ указали, что учетная запись блокируется при неиспользовании в течение 90 дней или после 6-и неудачных попыток входа, доступ может быть ограничен администратором на определенный срок, при попытке входа заблокированного пользователя необходимо выводить сообщение и т.д. А в техническом проекте (забежим вперед), мы с вами нарисуем макет карточки пользователя с флажком блокировки и датой разблокировки, составим сценарий входа в систему, в котором производится проверка на блокировку, автоматическая разблокировка по истечении установленного срока, блокировка в случае неудачных попыток входа; определим, что выполняется на стороне клиента, а что — сервера.
Хочется развенчать несколько мифов, связанных с разработкой технического задания.
Миф первый: В ТЗ содержатся требования только к исполнителю.
Нет, ТЗ — это то, как создать систему, и в техзадании есть разделы, в которых можно описать распределение ответственности.
Миф второй: В Техническом задании часто очень много «воды».
Действительно, нередко ТЗ содержит общие сведения о системе, но они нужны. Например, мы обсуждали-обсуждали требования к системе, в результате одна команда поняла, что нужно разработать приложение под Windows, а другая — для браузера. Одна думала, что система называется так, а другая — по-другому. Вроде бы очевидные вещи, но они должны пониматься одинаково всеми членами команды и всеми привлеченными специалистами.
Миф третий: Требования к персоналу, серверам, каналам связи, режимам работы администраторов являются лишними, так как находятся в сфере ответственности заказчика.
Во-первых, как мы уже рассматривали, ТЗ пишется для всех сразу, а во-вторых, ТЗ описывает, как сделать так, чтобы система заработала, а не только было написано ПО. Иначе будет еще одна лежащая на полке коробка с диском и толстой инструкцией. Таким образом, организационная часть ТЗ, нефункциональные требования, не менее важны, чем требования функциональные.
Подробнее составление ТЗ мы рассматриваем в отдельной статье Разработка Технического задания по ГОСТ 34 легко и просто.
4. Разработка технического проекта
Итак, двигаемся дальше. Вот перед вами (мы же допустили, что вы — проектант) Техническое Задание на строительство больницы с огромным перечнем требований. Сидите вы, смотрите грустно на 100 страниц ТЗ, и не знаете, с чего начать. Потом картина постепенно начинает проясняться. Думаете: ага, нам нужно столько-то метров под палаты, столько-то под кухню, столько-то на зону отдыха, лабораторию, сестринские и так далее и тому подобное. Затем на свет появляется множество набросков, эскизов, вариантов, вы переделываете, меняете помещения местами, короче, ищете оптимальные соотношения. Потом переходите к деталям — чертежи, чертежи, чертежи: стены, двери, окна, кабель-каналы, проводка, трубы, вентиляция, межэтажные перекрытия, материалы стен, отделка… и прочее, и прочее, и прочее. В общем, подробно-подробно, насколько это возможно, очерчиваете то, как должна выглядеть и функционировать больница после завершения строительства.
При разработке технического проекта Информационной Системы необходимы документы, содержащие следующее: подробные сценарии, описывающие работу и взаимодействие разрабатываемой системы, пользователей и смежных систем; детальные макеты пользовательского интерфейса, содержащие описание типа данных и поведения каждого элемента интерфейса (значение по умолчанию, условия, при которых можно изменить значение поля, видимость, действия, выполняемые системой при изменении элемента и т.п.); описание протоколов для интеграции со смежными системами и оборудованием, формы отчетов и описание алгоритма их формирования, структуру серверов и баз данных, если их несколько.
Обычно этого более чем достаточно, чтобы была возможность отдать документы разработчикам и получить вменяемый результат. Детальные макеты и сценарии дают достаточно информации о поведении системы и интерфейса, а также о структуре данных. Разработчики будут поставлены в жесткие рамки, в которых фантазировать можно, но потом будет не отвертеться.
Надеюсь, в следующих статьях мы более подробно рассмотрим то, как качественно выполнить техническое проектирование, как разработать макеты, сценарии, какие документы необходимо составить.
5. Разработка рабочей документации
Логичный вопрос — какая такая рабочая документация для больницы? Неужто инструкция по уборке коридора?! Шутки шутками, а противопожарную систему надо обслуживать? Надо. А лифты? А компьютерные сети? А водопровод? «Ну, это к проекту больницы не относится!» — скажете вы. Да, отчасти это так. Однако больница сдается заказчику как единое целое, и все системы должны иметь соответствующую эксплуатационную документацию. И чтобы сдача была быстрой, успешной, вы составите перечень требований, напротив которых можно ставить галочку, если все в порядке.
Наличие руководств пользователя и администратора для ИС — это стандарт, с этим все понятно. А вот о процессе сдачи-приемки системы заказчику часто задумываются в последний момент. И напрасно. Для этого существует прекрасный документ «Программа и методика испытаний», тоже обычно относящийся к рабочим документам. Он представляет собой своего рода чек-лист, содержащий описание проверочных процедур. Если данный документ составлен заранее (а сценарий, как основу, можно из техпроекта позаимствовать), то у разработчиков будет четкий критерий приемки их работ. Вам не понадобится собственным или аутсорсинговым программистам доказывать свою правоту — есть сценарий, он должен отрабатываться. И с заказчиком проблем не будет — фантазия уже ограничена документом.
А где же здесь место для Agile?
Одни люди двумя руками за Agile (или иные «гибкие» методы разработки), другие резко против. У автора же статьи свое мнение: Agile очень хорош, но к месту. А используют его обычно не по назначению.
Вот скажите мне, любители Agile, можно ли пользуясь данной технологией, определить результат, который вы получите в конце разработки, стоимость и сроки? Нет? Ну и много ли дураков заказчиков таких найдете, которые ввяжутся в работу с неясным результатом, бюджетом и длительностью? Вы бы заказали ремонт квартиры бригаде, пользующейся Agile? Таким образом, Agile имеет место быть, но для проектов внутренних. Сами себе ремонт можете делать сколько угодно и несколько раз все пересматривать. Для внешних же заказчиков — это названный умным термином развод (вы, конечно, не согласитесь с такой формулировкой, но попробуйте убедить в том же клиента).
Заказчик думает: и сколько меня еще будут по кругу за нос водить?
Во-вторых, Agile хорош в инновациях, там, где не понятно, какой результат требуется получить, или не ясен путь его достижения. Называется это ОКР, опытно-конструкторскими разработками. Или даже НИОКР — научно-исследовательские и опытно-конструкторские работы. На любом заводе имеется опытный цех, где с напильником, несколько раз переделывая, получают опытные образцы. Представим, что нужно разработать заново тачскрин, все жесты и поведение. Здесь действительно следует пробовать и пробовать, заранее поведение не опишешь. Но часто ли перед вами задачи подобного толка? Следует различать инженерные разработки и научно-исследовательские. В основном мы — инженеры по конструированию информационных систем.
В-третьих, в большом проекте могут присутствовать этапы, где требуется именно ОКР, и тогда Agile в помощь. Никто не мешает на уровне оперативного планирования пользоваться спринтами. Наоборот, очень удобная технология: планировать на неделю или две и постоянно контролировать результат. На стратегическом уровне — каскадное планирование, на тактическом — итеративное. И никаких противоречий!
К сожалению, очень часто, «проповедуя» Agile, разработчики пытаются замаскировать свое неумение разработать проект системы (либо даже не знают, что это возможно). Они действуют самым удобным для них образом: будем допиливать и допиливать за деньги заказчика. Пока расходы никто не контролирует, это вполне сходит с рук. Но потом у стороннего наблюдателя (начальства) может возникнуть ощущение, что процесс-то есть, а конца и края, да и результата не видно. Пытайтесь смотреть не только со своей колокольни.
Где узнать подробнее о проектировании информационных систем?
Книжек на эту тему много. Толстых и не очень. Но книжка — это всегда ЧУЖОЙ опыт. А у вас другой характер, отличная ситуация и проект. Есть такая система ТРИЗ — теория решения изобретательских задач. Ее автор, Альтшуллер, пытается объяснить шаги, которые нужно предпринять, чтобы изобрести что-либо. Получается? Как правило, нет. Принципы излагаются интересные, полезные, но единого шаблона по изобретению не выходит. Каждый человек думает и творит по-своему, да и невозможно этому научить, можно только научиться. Чужой опыт использовать надо, глупо не использовать, но он должен быть пережит (переработан) вами, переложен на ВАШЕ мышление. Скопировать чудо не удастся.
Если вы хотите научиться проектированию, предлагаю взять за основу ГОСТы 34-й серии. Это настоящий шедевр, результат работы целых НИИ. В ходе разработки данных стандартов были изучены десятки (если не сотни) сложнейших проектов по автоматизации самых различных систем. Аккумулирован колоссальный опыт.
Эти стандарты сложно освоить, и с наскока ими пользоваться не научишься. Поэтому мы попытаемся раскрыть их суть в последующих статьях.