Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Отчёты как источник функциональных требований и проектных решений
Сегодня я расскажу о том, как правильно работать с отчётами и о том, какой это замечательный источник функциональных требований (и даже проектных решений) при разработке информационных систем.
Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.
Для начала определимся, что такое отчёт и каково его основное предназначение.
Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.
Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.
Для начала определимся, что такое отчёт и каково его основное предназначение.
Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.
Основное предназначение отчёта (как и учётных ИС в целом) — предоставлять информацию, на основе которой люди могли бы принимать управленческие решения.
Как создается отчёт
При создании отчёта этапы проектирования и разработки последовательно сменяют друг друга.
На этапе проектирования отчёта системный аналитик:
- Определяет по техническому заданию (ТЗ) показатели, которые должны выводиться в отчёт
- Создаёт прототип для формы вывода отчёта и согласовывает его с заинтересованными лицами
- Описывает последовательность и формулы для расчёта показателей в отчёте
- Связывает показатели, выводимые в отчёт, с атрибутами модели данных
- Оформляет постановку на реализацию отчёта
На этапе реализации отчёта разработчик:
- Берёт постановку на реализацию отчёта в работу
- Верстает форму для вывода отчёта на экран (или печатную форму отчёта)
- Создаёт SQL-запросы для выборки нужных данных из базы данных (БД)
- Реализует расчётные процедуры с полученными данными
- Выводит полученные результаты в форму вывода
- И наступает всеобщее счастье! Даже скучно…
Да что угодно, в чём я имел возможность лично убедиться, потому что…
Из предисловия к первому изданию книги
Четыре типа проблемных ситуаций с отчётами
Как-то раз меня пригласили в качестве аналитика на этап технического проектирования очень большого проекта. Это был проект автоматизации учёта и отслеживания движения транспортных средств (ТС) одного из крупнейших регионов России.
Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.
Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:
1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным
Поговорим о том, почему это случается и как это предотвратить.
Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.
Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:
1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным
Поговорим о том, почему это случается и как это предотвратить.
Ситуация 1: в системе не предусмотрено хранение нужных нам данных
Причины, по которым возникла ситуация:
В ТЗ не были указаны требования к автоматизации процессов по внесению исходных данных, на основании которых формируется отчётность, то есть была нарушена методология разработки ТЗ.
Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.
Кто виноват:
Тот, кто разрабатывал ТЗ, если он недостаточно квалифицирован, и/или тот, кто дал команду нарушить методологию разработки ТЗ. Как правило, нарушение методологии встречается часто на таких проектах, где ТЗ служит основанием для участия в конкурсе. Из экономии времени отчётами пренебрегают как тем, что всегда можно получить из системы и согласовать с заказчиком позже.
Как это предотвратить:
Соблюдать методологию разработки ТЗ и использовать отчёты, которые нужны пользователям, как источник требований к проектированию ИС.
В ТЗ не были указаны требования к автоматизации процессов по внесению исходных данных, на основании которых формируется отчётность, то есть была нарушена методология разработки ТЗ.
Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.
Кто виноват:
Тот, кто разрабатывал ТЗ, если он недостаточно квалифицирован, и/или тот, кто дал команду нарушить методологию разработки ТЗ. Как правило, нарушение методологии встречается часто на таких проектах, где ТЗ служит основанием для участия в конкурсе. Из экономии времени отчётами пренебрегают как тем, что всегда можно получить из системы и согласовать с заказчиком позже.
Как это предотвратить:
Соблюдать методологию разработки ТЗ и использовать отчёты, которые нужны пользователям, как источник требований к проектированию ИС.
“
Когда вы разрабатываете ТЗ как аналитик, ни в коем случае не поддавайтесь на уговоры (за исключением письменного приказа!), когда руководитель проекта, начальство, заказчик предлагают или требуют отложить отчёты на потом, когда система уже будет разработана.
Помните, ответственность на проекте за формирование ТЗ и полноту требований несёт аналитик, и в конечном счёте виноваты будете именно вы!
Помните, ответственность на проекте за формирование ТЗ и полноту требований несёт аналитик, и в конечном счёте виноваты будете именно вы!
Системный анализ и Разработка требований в ИТ-проектах
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Отчёты как источник требований
Чтобы отчёты стали тем замечательным источником выявления функциональных требований (ФТ) к системе, о котором я говорил, работа с ними должна начинаться как можно раньше.
Этап обследования организации
На этапе сбора бизнес- и пользовательских требований у заинтересованных лиц необходимо выяснить:
- Какие формы отчётности существуют в компании сейчас
- Кто их формирует и на основании каких данных
- Кто является потребителем отчётов
- Какие отчёты могут понадобиться в будущем (их возможное содержание и структура)
Обязательно собрать все образцы используемых на данный момент отчётов, желательно, заполненные реальными данными. Эти данные пригодятся позднее в качестве тестовых примеров, когда будете проверять, правильно ли формируются отчёты.
Собрать имеющуюся нормативную документацию по работе с отчётами. Если вы работаете с госструктурами различных уровней, отчёты в таких системах зачастую формируются для передачи на уровень выше. При этом часть отчётов содержится в нормативной документации и, как правило, там прописана не только структура отчётов, но и вся информация о последовательности расчётов в них.
Этап формирования концепции ИС
На этом этапе нужно:
- Определить, какие отчёты будут реализованы в ИС и согласовать их с заказчиком как концепцию
- Проверить, что среди пользователей ИС есть потребители этих отчётов
- Проверить, что есть поставщики данных в ИС для проектирования реализуемых отчётов
- Проверить, что процессы поставки данных подлежат включению в состав ИС
Допустим, у нас есть система мониторинга использования автотранспорта и есть выделенные на этапе начального формирования концепции пользователи системы, которые могут быть как людьми, так и другими ИС.
Рассмотрим для примера отчёт об опозданиях на маршрутах.
Контекстная диаграмма с данными для отчёта об опозданиях на маршрутах (синий квадрат)
Потребителем этого отчёта является пользователь с ролью «Диспетчер».
Для формирования отчёта понадобятся данные о водителях, об автобусах, о маршруте и данные о назначениях на маршрут транспортных средств (ТС). Кроме того, понадобятся данные устройств телематики, которые определяют время прохождения ТС контрольных точек. Представляя структуру отчёта, которая была собрана на этапе предпроектного обследования, мы понимаем, что отчёт сформируется, так как все нужные для него данные у нас в системе есть.
Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.
Для формирования отчёта понадобятся данные о водителях, об автобусах, о маршруте и данные о назначениях на маршрут транспортных средств (ТС). Кроме того, понадобятся данные устройств телематики, которые определяют время прохождения ТС контрольных точек. Представляя структуру отчёта, которая была собрана на этапе предпроектного обследования, мы понимаем, что отчёт сформируется, так как все нужные для него данные у нас в системе есть.
Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.
Контекстная диаграмма с данными для отчёта о рентабельности маршрутов (зелёный квадрат)
Посмотрим, какие данные для этого нужны. У нас есть назначенные маршруты, есть данные о водителях и автобусах, поступающие из системы учёта кадров и системы учёта автотранспорта, и данные о платежах, которые поступают из системы платежей. Все эти данные в нашу систему поступают, а значит проблем с формированием отчёта не возникнет.
И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.
И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.
Контекстная диаграмма с данными для отчёта о простоях и ремонтах ТС (красный квадрат)
Для отчёта необходимы данные о ТС (они есть), но также нужны данные о ТС, которые находятся в ремонте, а эту информацию в систему никто не поставляет! Процесса поставки данных нет: его забыли указать при формировании ТЗ.
Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.
Соответственно, мы не только не получили такие отчёты, мы упустили целый набор либо технических интерфейсов обмена данными с другими системами, где они будут храниться, либо интерфейсов взаимодействия с пользователями, чтобы эти данные поступали.
Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.
Соответственно, мы не только не получили такие отчёты, мы упустили целый набор либо технических интерфейсов обмена данными с другими системами, где они будут храниться, либо интерфейсов взаимодействия с пользователями, чтобы эти данные поступали.
Если бы мы на данном этапе построили контекстную диаграмму для системы, то сразу же выяснили, что для механика необходим графический интерфейс, который бы подавал данные о ТС на ремонте, и система автоматически не давала бы диспетчеру их назначить на маршрут. Кроме того, данные о ремонте сохранялись бы в системе, использовались при формировании отчета и помогали принимать текущие управленческие решения. Но, так как это процесс поставки данных был упущен, ситуация обнаружилась, только когда писалась постановка на отчёт, что привело к задержке выпуска системы.
Этап разработки технического задания
На этапе разработки ТЗ нам нужно сформировать функциональные и нефункциональные требования (НФТ) к отчётам.
ФТ формируются в виде классических атомарных ФТ, либо в виде юскейсов функционального уровня.
ФТ формируются в виде классических атомарных ФТ, либо в виде юскейсов функционального уровня.
“
Например, система должна позволять пользователю с ролью «Кассир», «Администратор кассы» просматривать отчёт «Кассовый отчёт» с набором полей:
- Дата рабочего дня
- Номер рабочей смены
- Дата открытия рабочей смены
- Дата закрытия рабочей смены
- …
В НФТ мы формируем требования к качеству или доступности формирования отчёта (скорость формирования отчёта, количество одновременно работающих с отчётами пользователей и т. п.)
Например, скорость формирования отчётов не должна превышать 1 секунду в 80% случаев.
Например, скорость формирования отчётов не должна превышать 1 секунду в 80% случаев.
Ситуация 2: данные присутствуют, но нет ясности, те ли это данные и как это проверить
Причины, по которым возникла ситуация:
- В ТЗ отсутствует или плохо описана концептуальная модель данных (КМД)
- Модель предметной области плохо задокументирована
Последствия для проекта:
Дополнительные временные затраты аналитика и привлекаемых экспертов на доработку и/или документирование КМД.
Кто виноват:
Тот, кто разрабатывал и описывал концептуальную модель данных для проекта.
Как предотвратить:
- Всегда разрабатывать КМД как составную часть ТЗ
- Тщательно документировать КМД
В моем проекте для части отчётов было невозможно сформировать постановки на разработку отчетов, потому что я не понимал, какие данные из модели нужно брать, чтобы эти отчёты формировались. При этом концептуальная модель данных была зафиксирована в виде модели в Enterprise Architect (EA), но в ней были описаны только классы и атрибуты, а их значения — не были. Даже эксперты в предметной области не могли мне объяснить, что это значит, исходя только из названий в модели.
Как правильно документировать данные
Давайте сравним описание данных, каким оно было оставлено моим предшественником (слева) и каким его предлагаю делать я (справа).
Пример описания сущности с пояснениями
Попробуйте понять без пояснения, что «Время: int» это «Время движения от предыдущего Объекта движения. Плановый показатель». И даже эксперт предметной области в этом не поможет: это служебный (технический) атрибут, предназначенный для работы системы, и он появился только в момент автоматизации.
Я призываю вас подробно комментировать не только назначение сущностей в модели данных, но и все выявленные атрибуты. Любите себя и тех, для кого вы разрабатываете модель требований, частью которой является модель данных. Время, потраченное на документирование предметной области, позволит существенно сэкономить время и вам, и другим потребителям вашей документации.
Я призываю вас подробно комментировать не только назначение сущностей в модели данных, но и все выявленные атрибуты. Любите себя и тех, для кого вы разрабатываете модель требований, частью которой является модель данных. Время, потраченное на документирование предметной области, позволит существенно сэкономить время и вам, и другим потребителям вашей документации.
Ситуация 3: данных так много, что технических возможностей системы не хватает для их обработки
Мне было необходимо построить ряд отчётов о завершенности рейсов.
Рейс считался завершённым, если более 80% остановок были пройдены вовремя. Все данные хранились в системе телематики. Данные в систему телематики (с устройств, установленных на автобусе) собирались раз в несколько секунд или даже в секунду, то есть система телематики хранила огромные объемы данных.
Отчёты о завершённости маршрутов, как правило, строили помесячно, поквартально и ежегодно.
Чтобы построить отчёт о завершённости маршрута, нужно было выполнить ряд последовательных шагов:
- Сравнить данные координат остановки
- Сравнить, был ли на данном устройстве в тот день назначенный на рейс автобус
- собрать это по данным всего предприятия, в котором несколько сотен ТС, за определённый период.
Причины, по которым возникла ситуация:
- Особенность технической реализации информационной системы
- Неправильная оценка объема обрабатываемых данных
дополнительные временные затраты на разработку технического решения и возможное увеличение стоимости технической составляющей системы.
Кто виноват:
Архитектор
Как предотвратить:
Необходимы правильные проектные решения со стороны архитектора на этапе эскизного проекта.
Что может предложить системный аналитик
Когда нет возможности без сдвига сроков сдачи проекта применить технические средства, приходится решать проблему аналитическим способом: путем изменения логики работы.
Рассмотрим часть модели, в которую были внесены изменения для построения отчета о завершенности маршрута транспортного средства.
Рассмотрим часть модели, в которую были внесены изменения для построения отчета о завершенности маршрута транспортного средства.
Пример проектного решения для упрощения получения отчёта на больших данных
Итак, мы внесли изменения в логику работы системы. Теперь расчет того, успешен ли рейс, производился сразу после завершения рейса, а не в момент формирования отчёта. Признак успешного завершения мы хранили в базе данных. Для кого-то такое решение может показаться спорным и не очень изящным, но именно оно было применено в нашем случае, и проблемы с построением отчетов из-за недостаточной мощности были решены.
Нам не пришлось тратить деньги на сложные программные продукты, которые бы могли это решить, а также время на то, чтобы их разработать и внедрить. Мы обошлись теми техническими возможностями хранения и обработки данных, которые на тот момент были.
И хотя эта ситуация довольно нетипична для работы аналитика, если вы когда-нибудь столкнетесь с подобной проблемой в отчётах, обрабатывающих большой объём данных, знание о возможности хранения промежуточных данных может вам пригодиться.
Нам не пришлось тратить деньги на сложные программные продукты, которые бы могли это решить, а также время на то, чтобы их разработать и внедрить. Мы обошлись теми техническими возможностями хранения и обработки данных, которые на тот момент были.
И хотя эта ситуация довольно нетипична для работы аналитика, если вы когда-нибудь столкнетесь с подобной проблемой в отчётах, обрабатывающих большой объём данных, знание о возможности хранения промежуточных данных может вам пригодиться.
Ситуация 4: данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным
Это самая простая ситуация, которая случается буквально у всех аналитиков, которые работают с отчётами.
Причины, по которым возникла ситуация:
Ошибки при разработке постановок на реализацию отчёта и/или ошибки при реализации отчёта в коде.
Кто виноват:
Тот, кто разрабатывал и/или реализовывал отчёт.
Последствия для проекта:
Дополнительные затраты на доработку и/или реализацию отчёта в ИС. Если такие отчёты попали в релиз, это вызывает недовольство пользователей и заказчика.
Как предотвратить:
Предоставьте тестировщикам для проверки правильности результатов отчёта реальные тестовые примеры, согласованные с экспертами.
Причины, по которым возникла ситуация:
Ошибки при разработке постановок на реализацию отчёта и/или ошибки при реализации отчёта в коде.
Кто виноват:
Тот, кто разрабатывал и/или реализовывал отчёт.
Последствия для проекта:
Дополнительные затраты на доработку и/или реализацию отчёта в ИС. Если такие отчёты попали в релиз, это вызывает недовольство пользователей и заказчика.
Как предотвратить:
Предоставьте тестировщикам для проверки правильности результатов отчёта реальные тестовые примеры, согласованные с экспертами.
Системный анализ и Разработка требований в ИТ-проектах
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Выводы
Мы поговорили о том, какие ошибки при проектировании отчётов могут встречаться на проектах, а также обсудили, как аналитик может позаботиться о предотвращении этих ошибок. Давайте кратко резюмируем основные мысли статьи:
- Отчёты — замечательный источник требований к проектируемой ИС, и чем раньше вы начнете с ним работать (в идеале — на этапе предварительного обследования и концепции), тем больше вероятности избежать дорогостоящих ошибок. Кроме того, отчеты — важнейший инструмент принятия решений для бизнеса заказчика.
- Документируйте аналитические артефакты как можно более полно. Делайте это и на этапе предварительного обследования, и на этапе формирования концепции ИС, и тем более на этапе разработки ТЗ. Максимально подробное документирование — залог того, что при разработке и сопровождении ИС будет меньше проблем с построением отчетов.
- Проверка отчётов на реальных тестовых примерах — залог хороших отношений с заказчиком и участниками команды разработки.
- Соблюдайте методологию разработки ИС — и будет вам счастье!
Error get alias