Разработка информационной системы учета работы строительного предприятия
2. Техническое задание на создание информационной системы
2.1 Общие сведения
Автоматизированная информационная система «Строительное предприятие»
2.2 Цели создания информационной системы
Для решения задач контроля и учета проектирования и изготовления, и продаж в данном предприятии создается автоматизированная информационная система, которая проектируется в среде СУБД ACCESS.
Информация в виде распределенной базы данных хранится частично на файл-сервере и частично на рабочих станциях, входящих в состав локальной вычислительной сети отдела продаж. Видом автоматизированной деятельности является учет.
Основными средствами работы данной фирмы являются здания предприятия ЗАО «УниСтрой - НН», в котором размещены средства автоматизации управления (компьютеры - рабочие станции, серверы, а также другие технические устройства).
Основные функции, которые решает ИС:
· Контроль работы предприятия;
· Учет продаж предприятия;
· Учет результатов (доходов и расходов предприятия).
Систематизация и автоматический контроль над работой предприятия, продажами, заказами.
2.3 Характеристика объектов автоматизации
Основной деятельностью данного предприятия является организация проектирования и продажи товаров, значит, деятельность экономического отдела по учету и будет основным объектом автоматизации.
2.4 Требования к системе
2.4.1 Требования к входной, нормативно-справочной и выходной информации
К входной информации отдела проектирования и изготовления, и продаж относятся данные, необходимые для решения всех задач, решаемые в этом подразделении. В первичной форме эти данные поступают в виде документов на бумажном носителе. К основной входной информации относятся следующие данные:
· Документы, поступающие из планово-экономического отдела 1 раз в месяц, которые содержат плановые задания по выполнению проектирования и продаж;
· Данные, поступающие из отдела маркетинга, которые содержат заявки на поставку товаров и выполнение других работ, сведения об установленных ценах;
Выходная информация может быть представлена в виде бумажного документа, в виде информационного сообщения или в виде файла (электронного документа) на магнитном носителе.
Эти данные представлены в виде таблицы БД, в виде запроса, а также в виде отчета на экране и на бумаге.
Выходные результаты решения задачи по учету результатов деятельности предприятия выводятся:
· На принтер и на жесткий диск в отделе проектирования и изготовления, и отделе продаж;
· Передаются по каналу связи в бухгалтерию и в планово-экономический отдел.
Выдача выходных данных осуществляется каждый квартал.
2.4.2 Предложения по кодированию и классификации информации
Кодирование входной информации должно производиться с учетом следующих требований:
· Сокращение временных и других затрат на решение задач в системе управления;
· Обеспечение высокого качества информации.
В информационной системе используется порядковый метод кодирования входной информации (Табл. Учет проектирования и изготовления, поле - номер записи, Учет продаж - номер записи).
Эти данные кодируются с использованием порядкового метода. Его достоинством является простота использования, недостатком - переполнение кодов.
Классификация информации.
Существует 2 метода классификации:
· Иерархический - под этим методом классификации понимается метод, при котором заданное множество последовательно делится на подчиненные подмножества, постепенно конкретизируя объект классификации. При этом основанием деления служит некоторый выбранный признак. Совокупность получившихся группировок при этом образует иерархическую древовидную структуру в виде ветвящегося графа, узлами которого являются группировки.
· Фасетный - этот метод классификации подразумевает параллельное разделение множества объектов на независимые классификационные группировки. При этом не предполагается жёсткой классификационной структуры и заранее построенных конечных группировок. Классификационные группировки образуются путем комбинации значений, взятых из соответствующих фасетов.
Качество информации в системах управления - совокупность свойств, обуславливающих пригодность данных для удовлетворения потребностей системы управления. Важнейшими свойствами информации, используемой в системах управления, являются:
Ш Кумулятивность - полнота информации;
Ш Достоверность - отсутствие скрытых ошибок;
Ш Защищенность - невозможность несанкционированного доступа;
Ш Оперативность - своевременность;
Ш Гомоморфность - данные должны быть представлены в одном виде;
Ш Идентичность - соответствие объектов на данный момент;
Ш Конфиденциальность - секретность.
Основным программным методом контроля качества информации, используемой в системе управления, является:
· Логический - смысловая проверка, т. е контроль по отклонениям, по заданной последовательности записей
· Программный.
В данной работе контроль качества информации осуществляется с помощью кнопки «Контроль достоверности». Проверяются таблицы: продукция, проекты и учет продаж. Если в таблице присутствует отрицательные значения себестоимости производства, цены продажи, стоимости проектирования и количества, то при нажатии кнопки выявляется ошибка. В противном случае сообщается что ошибок нет.
2.4.4 Предлагаемые меры по защите информации от несанкционированного доступа
Несанкционированный доступ - получение информации без разрешения ее владельца.
Его виды:
1. Косвенный - подслушивающие устройства, дистанционные фотографии, радиоперехват и др.
2. Прямой - непосредственное хищение носителей данных, считывающие данные с диска, вход в систему под чужим паролем, маскировка запросов под системные запросы, заражение программными вирусами и т.д.
Защита наиболее уязвимой части информации производится следующими методами:
· Процедурные - организационно - технические мероприятия - идентификация всех компьютеров и пользователей, установление регламента работы, конкретные базы данных и программы.
· Программные - защита БД и прикладных программ от копирования, антивирусные программы, шифрование, резервирование информации
В информационной системе применяется программный метод защиты (проверка на вирусы).
База данных создавалась в системе СУБД ACCESS т.к она больше ориентирована на обычного пользователя, по сравнению, например, с СУБД FOXPRO, которая ориентирована на прикладного программиста. Выбор СУБД определяется уровнем сложности решаемых в составе АИС задач управления. Поэтому для данной курсовой работы оптимальна СУБД ACCESS.
2.4.5 Требования к базе данных (БД) и системе управления БД
Система управления БД, которая будет использоваться в автоматизированной системе - СУБД ACCES, так как она больше ориентирована на обычного пользователя, а СУБД FOXPRO - на прикладного программиста.
2.4.6 Требования к техническим средствам
Рекомендуется использовать ПК с процессором Pentium -IV, с оперативной памятью объемом не менее 256 МБт, с дисковой памятью объемом не менее 200 ГБт. Это обеспечит высокопроизводительную работу ЛВС при использовании любой топологии и операционной системы.
Требования к вспомогательным устройствам. Для работы в сети устанавливаются 32 - разрядные сетевые адаптеры EtherNet с протоколом ISA или адаптеры TokenRing с протоколом MicroChannel, или сетевые адаптеры ArcNet с протоколом ISA.
Сетевой принтер должен соответствовать следующим требованиям:
· Иметь высокую производительность;
· Иметь достаточную буферную память;
· Иметь высокую надежность работы;
· Обеспечивать высокое качество печати;
· Желательно иметь возможность копирования документов.
Исходя из этого, применяется лазерный принтер - HP LaserJet 1100.
Для повышения надежности работы сети необходима установка устройств бесперебойного питания UPS, особенно для файл - сервера.
3. Технорабочий проект (Проектное решение)
Автоматизация процесса поиска плагиата
Автоматизация работы техподдержки пользователей
В соответствии с ГОСТ 34.601-90, настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях...
Автоматизация расчетов по оплате труда на примере ОАО "Нечкинское" Сарапульского района Удмуртской Республики с использованием программы 1С:Предприятие 8.0
Автоматизированная информационная система учета расхода воды
Общие сведения Полное наименование системы и ее условное обозначение Информационная системы учета расхода воды на примере общества с ограниченной ответственностью "Водоснабжение" (АИС УРВ "Водоснабжение")...
Автоматизированная информационная система учета хранения и обслуживания контрольно-измерительных приборов
Техническое задание разработано в соответствии с ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы"...
Виртуальный деканат
Для обновления сайта от Филиала предоставляется новая информация, фото и медиа файлы, которые нужно заменить на какой-либо из страниц. Замена производится с помощью руководства п.2...
Информационная система "Клинника"
1. Определение назначения разрабатываемой ИС Улучшить качество обслуживания клиентов организации, ускорить процесс оформления документации. 2...
Информационное обеспечение АТП
Подбор технического обеспечения производим с учетом организационной структуры СТО...
Проектирование информационной сети
Целью курсовой будет разработать информационную сеть в муниципальном образовательном учреждении гимназия №7, физически располагающегося в одноэтажном здании...
Разработка web-сайта организации (на материалах ООО "Автомир", г. Гомель)
Рассмотрим уровень технического обеспечения в ООО «Автомир». В организации все рабочие места автоматизированы. На рабочих местах установлены персональные компьютеры...
Разработка и проектирование информационной системы для салона мобильной связи при помощи Microsoft Access на языке программирования Visual Basic
Одной из стадий проектирования автоматизированной информационной системы является разработка и утверждение технического задания на создание системы. Техническое задание - это основной документ...
Разработка информационной системы администратора сети организации ООО "WestCall"
Разработка системы учета компьютерного и офисного оборудования и расходных материалов
1 Общие сведения. 1.1 Полное наименование системы и ее условное обозначение "Bentec IT & Soft invent" 2. Назначение и цели создания системы. 2.1 Назначение системы...
Разработка технического задания для автоматизации магазина "Буква"
Общие сведения Наименование системы автоматизированная система учета деятельности магазина "Буква-Серов". Предприятие заказчик - ООО "Эталон"...
Создание сайта группы
1) Тип изделия: Динамический web-сайт группы; 2) Цель: Создание сайта группы для удобства информирования студентов группы в неучебное и учебное время; 3) Целевая аудитория: Студенты группы и преподаватели ВУЗа; 4) Требования к сайту: 1)Удобный...
Техническое задание на проектирование информационной системы. Основные разделы технического задания. Стандарты, описывающие техническое задание. Анализ и разработка требований.
Техническое задание - технический документ (спецификация), оговаривающий набор требований к системе и утверждённый как заказчиком/пользователем, так и исполнителем/производителем системы. Такая спецификация может содержать также системные требования и требования к тестированию.
Техническое задание содержит следующие разделы:
Общие сведения. Данный раздел включает в себя: полное название разработки, полное название и реквизиты заказчика и исполнителя, перечень документов, являющихся основанием для разработки, возможные сроки начала и окончания работ, порядок оформления и предъявления заказчику результатов работ по созданию системы или её частей.
Основания и назначения разработки. Под назначениемразработки понимается вид автоматизируемых процессов деятельности.
Требования к системе. Содержит подразделы с требованиями к системе в целом и функциям, выполняемых системой.
Состав и содержание работ по созданию системы. Перечень работ и их содержание, которые предполагается выполнить в рамках данного проекта
Порядок контроля и приемки системы. Содержит ориентировочные даты промежуточного контроля и ориентировочную дату сдачи заказчику.
Требования к составу и содержанию работ по подготовке объекта разработки к вводу системы в действие. Описываются подготовительные работы по вводу системы в действие.
Требования к документации. Содержит перечень и состав документации системы.
Источники разработки. Содержит список документации, литературы, которая будет использована при разработке системы.
Существуют три стандарта, описывающих техническое задание на проектирование ИС: ГОСТ 34.602-89, ГОСТ 19.201-78, ГОСТ 19.102-77.
Разработка требований может формироваться на основе опросов, анкет и т.д. Кроме этого требования могут формироваться на основе проведенного мозгового штурма, наблюдения за производственной деятельностью, анализа нормативной документации, анализа уже созданных ИС, анализа версий используемой ИС.
При разработке требований часто возникают проблемы двусмысленности, неполноты и несогласованности отдельных требований. Устранение этих проблем на этапе разработки требований стоит на несколько порядков меньше, чем устранение этих же проблем на поздних стадиях разработки.
Пользовательский интерфейс информационных систем. Общие принципы построения. Стили пользовательского интерфейса. Критерии эффективности пользовательского интерфейса. Руководящие принципы построения пользовательского интерфейса. Правила проектирования.
Интерфейс пользователя – это программная часть информационной системы, отвечающая за управление устройствами, с помощью которых пользователь общается с программой.
Планирование и разработка пользовательского интерфейса должна основываться на следующих моделях:
- Ментальная модель – некоторые ожидания человека, основанные на ощущении действительности и на его знаниях и опыте работы с компьютером.
- Пользовательская модель - наблюдая за тем, как пользователи работают с новым для себя интерфейсом и анализируя их отзывы о работе, можно составить общие представления о будущем интерфейсе. Важно, чтобы пользователь был как можно раньше включён в работу над ИС.
- Модель программиста – рождается в голове программиста, основывается на его профессиональной деятельности.
Стили пользовательского интерфейса. Можно выделить четыре основных стиля пользовательского интерфейса:
- Графический пользовательский интерфейс (Graphical User Interface , GUI ) – в основе данного интерфейса лежат четыре фундаментальных элемента: окна, указателя (мыши), меню и пиктограммы. Используются и другие элементы: кнопки, переключатели, поля ввода и др. Особенностью данного интерфейса является развитые возможности оформления экрана и управление с помощью указателя мыши.
- Web -интерфейс (Web User Interface , WUI ) – интерфейс напоминаетGUIинтерфейс, но изначально был беднее его. В нём, в частности, использовался режим одного окна и не было возможности «перетаскивания» объектов. С развитиемJavaScriptиAjaxон становится более похожим на интерфейсGUI.
- Интерфейс HUI (Human User Interface ) – это пользовательский интерфейс карманных устройств. Обычно подобные устройства обладают очень маленьким экраном. В нём содержатся некоторые элементы графического интерфейса, например элементы меню и пиктограммы.
- Объектный стиль интерфейса. Возможности объектного программирования позволяют перенести объектную природу в интерфейс пользователя. Объектный подход характеризуется такими возможностями как перетаскиванием элементов, контекстным меню, всплывающими подсказками и т.п.
Рассмотрим набор критериев качества пользовательского интерфейса:
- Понимание пользователей – насколько потребности пользователей отражены в интерфейсе программы.
- Эффективность процесса проектирования – определяет является ли продукт тщательно продуман и спроектирован.
- Необходимость проекта – имеет ли продукт экономическую и общественную значимость.
- Пригодность к изучению и использованию – насколько сложен продукт для изучения и использования.
- Соответствие – соответствует ли дизайн продукта решению поставленных проблем.
- Эстетические чувства – насколько использование продукта эстетически приятно.
- Изменяемость – насколько дизайн может изменяться в соответствии с требованиями пользователя.
- Управляемость – в какой мере реализована функция управляемости продуктом: управлением инсталляцией, тренировкой, сопровождением.
Общие принципы построения графического интерфейса :
Использование единой среды пользователя в виде так называемого рабочего стола;
Использование графических окон для отображения данных;
Применение средств неклавиатурного ввода (с помощью мыши).
Правила проектирования пользовательского интерфейса:
- Контроль пользователя - разработчики должны дать пользователю наиболее полный контроль над ИС (на сколько это позволяет безопасность). Рассмотрим несколько частных реализаций данного принципа:
1) уменьшение нагрузки на память – память пользователя не столь велика и не столь быстра.
2) совместимость интерфейса – возможность пользователей переносить свой опыт и знания на работу с новым программным обеспечением.
Моделирования информационных систем. Необходимость в языках моделирования. Язык UML . Принципы объектно-ориентированного проектирования. Обзор диаграмм языка UML . Диаграммы прецедентов и диаграммы классов.
Моделирование – это замещение исследуемого объекта (оригинала) его условным образом или другим объектом (моделью) и изучение свойств оригинала путём исследования свойств модели.
Эффективность моделирования может быть достигнута при соблюдении двух условий: модель обеспечивает корректное отображение свойств оригинала; модель позволяет устранить проблемы, присущие проведению измерений на реальном объекте.
Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов.Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования с одной стороны должен делать решения проектировщика понятными пользователю, с другой стороны предоставлять проектировщикам средства для наиболее формализованного представления информационной системы. Графическое изображение нередко является наиболее понятной формой представления информации.
UML (Unified Modelling Language – унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения.UMLиспользует графические обозначения для представления абстрактной модели системы, называемойUML-моделью. Данный язык был разработан для моделирования ИС.UMLне является язык программирования, но на основеUML-модели производится генерация кода.
Объектно-ориентированная модель представляет собой совокупность диаграмм, описывающих с помощью языкаUML, различные аспекты структуры и поведения ИС.
Диаграмма UML – это графическое представление набора элементов, изображаемое чаще всего в виде графа с вершинами (сущностями) и рёбрами (отношениями).
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на разработку информационной системы
1. Общие сведения
4. Требования к системе
6. Порядок контроля и приемки системы
1. Общие сведения
В соответствии с договором № МП23 между "ООО ТехноПлюс " (в дальнейшем Разработчик) и ООО ОптоТорговля (в дальнейшем Заказчик), Разработчик проектирует БД, разрабатывает и вводит в эксплуатацию информационную систему «Учет торговых операций»
Днем начала проектирования БДБ считается день, следующий после подписания данного Технического задания
Если в процессе разработки Заказчик изменяет описанные в данном документе требования, то они оформляются отдельным документом и влекут за собой изменение или дополнение Договора между Заказчиком и Разработчиком БД в части срока выполнения и оплаты договора
Заказчик оплачивает работы Разработчика БД в соответствии с договором N XXX
2. Назначение и цели создания (развития) системы
ИС «Учет торговых операций» предназначена для хранения, обработки и анализа информации, относящейся к основной деятельности Заказчика.
Целью создания ИС «Учет торговых операций» является:
Хранение информации о совершенных торговых операциях;
Отражение торговых операций в бухгалтерском учете ;
Анализ финансовых результатов торговых операций;
Анализ торговой деятельности в разрезе номенклатура и контрагенты .
3. Характеристика объектов автоматизации
3.1. Основной деятельностью Заказчика является торговля мебелью и сопутствующими товарами по безналичному расчету .
3.2. Заказчик не является плательщиком НДС
3.3. За день Заказчик совершает не более 100 торговых операций по покупке и продаже товаров.
3.4. Общий объем номенклатуры товаров не превышает 3000 единиц
3.5. Общее количество контрагентов - поставщиков не более 100 единиц.
3.6. Количество контрагентов – покупателей – не ограничено. На момент подписание договора N XXX составляло 300 единиц.
3.7. Списывание товаров со склада Заказчик осуществляет по методу средневзвешенной стоимости.
3.9. В качестве счетов расходов используются только счета класса 9.
3.10. Фінансові результати торгівельної діяльності підприємства (прибутковість чи збитковість операцій) визначаються на основі різниці рахунків 702 та 902.
3.11. Совершение торговых операция регистрируются в первичных документах Приходная накладная, Расходная накладная, Банковская выписка.
Прибуткова накладна (ПН) відображує факт надходження товару на склад підприємства та містить таку інформацію:
– номер;
– дату;
– ім’я контрагента (фірми - постачальника);
– найменування товару;
– кількість;
– ціну одиниці товару;
– суму.
Видаткова накладна (ВН) відображує факт відвантаження товару зі складу підприємства покупцю та містить інформацію, схожу на інформацію в ПН (лише замість фірми-постачальника вказується фірма-покупець).
Рядок банківської виписки підтверджує факт надходження/вибуття коштів із розрахункового рахунку (р/р) підприємства та містить таку інформацію:
– дату;
– ознаку приходу/витрати коштів;
– ім’я контрагента (від кого надійшли / кому перераховано кошти).
3.12. Кожний первичный документ є підставою для здійснення певних проводок, які здійснюють зміни певних бухгалтерських рахунків. Операції торгівельного підприємства викликають такі проводки (табл.3.1)
Таблица 3.1 – Проводки, используемые в бухгалтерском учете на предприятии Заказчика
Операция | Документ | Дебет счета | Кредит счета | Сумма проводки |
Оприходование | Приходная накладная | сумма документа |
||
Отгрузка товара | Расходная накладная | сумма документа |
||
себестоимость отгруженного товара |
||||
Поступление денег на расчетный счет | Банковская выписка (приходная) | сумма документа |
||
Перечисление денег с расчетного счета | Банковская выписка (расходная) | сумма документа |
||
Определение финансовых результатов | на сумму закрытия 902 счета |
|||
на сумму закрытия 702 счета |
де 281 – товари на складі;
311 – розрахунковий рахунок у вітчизняній валюті;
361 – розрахунки з вітчизняними покупцями;
631 – розрахунки з вітчизняними постачальниками;
702 – доход від реалізації товару;
902 – собівартість реалізованих товарів (витрати).
3.13. У якості бухгалтерської звітності використовується оборотно-сальдова відомість синтетичного обліку вигляду як у таблиці 3.2.
Таблиця 3.2 – Оборотно-сальдова відомість синтетичного обліку
Номер позиції | Сальдо початкове | Обороти | Сальдо кінцеве |
|||
Разом |
4. Требования к системе
ИС «Учет торговых операций» должна отвечать следующим требованиям:
4.1. БД для ИС «Учет торговых операций» должна обеспечивать хранение, отображение и редактирование справочной и оперативной информации.
Справочная информация:
o описание товаров:
Номер номенклатуры (товара);
Название товара;
Описание;
o контрагенты – поставщики;
Номер контрагента;
Имя контрагента;
Адрес контрагента;
Контакты;
o контрагенты – покупатели;
Номер контрагента;
Имя контрагента;
Адрес контрагента;
Контакты;
o план счетов, на которых производится бухгалтерский учет для учета торговых операций и анализа финансовых результатов;
o перечень базовых проводок для отображения торговых операций в бухгалтерском учете, вызванных первичными документами, которые имеют следующий вид, как в таблице3.1;
Оперативная информация:
o Первичные документы: Приходная накладная, Расходная накладная, Банковская выписка (описание документов приведено в 3.11)
o Бухгалтерские проводки, вызванные первичными документами (вид проводок приведен в таблице 3.2)
o Информация о товарах на складе:
Номер товара;
Количество;
Сумма;
Средняя цена.
4.2. ИС «Учет торговых операций» должна позволять автоматизировать следующие действия:
4.2.1 Отражать факты оприходования (получения) и отгрузки товара на складе, а именно, пересчитывать количество товара на складе и его среднюю стоимость.
4.2.2 Формировать по первичным документам бухгалтерские проводки в автоматическом режиме.
4.2.3 Проводить поиск следующей информации:
Первичных документов указанного типа за определенный период;
Проводок для указанного типа документов за определенную дату;
Информации о контрагенте
Информации о товаре
4.2.4 Проводить анализ торговой деятельности за указанный период в следующих разрезах:
Финансовых результатов торговой деятельности;
Результатов расчетов по каждому контрагенту;
Остатков товаров на складе по каждому наименованию;
Стоимости сделок по каждому контрагенту;
Стоимости и количеству продаж по каждому виду товаров
4.2.5 Формировать отчеты за указанный период:
Оборудование, на котором установлена ИС, должно быть снабжено источником бесперебойного электропитания. При перебоях электропитания должно происходить автоматическое завершение работы ИС без потери данных.
В ИС должны быть предусмотрены механизмы резервного копирования, ИС должна быть оснащена соответствующим оборудованием и программным обеспечением:
Количественные значения показателей надежности:
- время автоматического завершения работы должно быть не более 1 минуты;
- время восстановления после сбоя должно быть не более 30 минут;
- показатель отказоустойчивости ИС должен составлять 11/7, т. е. бесперебойной работы ИС 11часов в день 7 дней в неделю.
Обслуживание ИС должно производиться без прерывания ее работы.
4.5 Требования к методам оценки и контроля показателей надежности на стадии опытной эксплуатации
Для контроля показателей надежности на этапах опытной эксплуатации ИС обслуживающий персонал должен вести Журнал отказов, который должен содержать следующие информационные признаки:
Дату возникновения ошибки;
Общую наработку объекта с начала его эксплуатации до момента выявления ошибки;
Внешние признаки и характер появления ошибки;
Вид работы, при которых была обнаружена ошибка.
4.6 Требования к производительности ИС
Система должна поддерживать возможность обрабатывать до 1000 документов в день
Система должна обладать следующей производительностью:
80% операций должны иметь время отклика (время выполнения операции) менее 1сек.;
15% операций – от 5сек. до 10сек;
5% операций - более 10сек, но не более 30мин.
4.7 Требования к объемам (масштабируемости)
Система должна поддерживать доступ к данным за 10 лет.
Предполагаемый прирост объема БД за один день эксплуатации 20Мб.
4.8 Требования к численности, функциям и квалификации персонала ИС и режиму его работы
Работу с ИС будет осуществлять следующий персонал Заказчика:
Администратор:
Количество: 1;
Квалификация: сетевой администратор, администратор баз данных ;
Функции: управление безопасностью системой, резервное копирование данных в начале каждого рабочего дня, архивирование данных один раз в год;
Режим работы: 1 час в день, 5 дней в неделю
Оператор (пользователь), фиксирующий факт торговой операции и анализирующих результаты торговой деятельности:
Количество: 2;
Квалификация: бухгалтер, пользователь ПК;
Функции: ввод первичных документов, поддерживание актуального состояния информации о складе, формирование бухгалтерских проводок, анализ результатов торговой деятельности, резервное копирование данных в начале рабочего дня, попадающих на субботу и воскресенье.
Режим работы: посменно для обеспечения работы системы 11 час в день 7 дней в неделю;
Доступ к работе: 8-й часовой курс обучения;
Перед ведением ИС в эксплуатацию для получения допуска к работе персонал должен пройти 8-часовой курс обучения. После окончания курса проводится тестирование, в процессе которого оцениваются правильность и скорость решения практических задач, а также знания должностных и технических инструкций.
Система должна предоставлять доступ к своим функциям только зарегистрированным пользователям ИС по указанию ими пароля.
4.10 Требования к программному обеспечению и составу, структуре и способам организации БД ИС
Данные в Системе должны храниться в реляционной СУБД МS SQL Server 2000.
- T-SQL (диалект языка SQL);
С # .
Программное обеспечение состоит из общесистемного программного обеспечения, приобретаемого за счет средств Заказчика (покупных программных средств), и специального программного обеспечения, разрабатываемого в рамках работ по созданию ИС.
В качестве общесистемного программного обеспечения должно использоваться следующее программное обеспечение:
Операционная система;
Система управления базами данных МS SQL Server 2000;
Программное обеспечение для резервного копирования;
4.11 Требования к аппаратному обеспечению
Сервер БД, 2 рабочие станции.
Пропускная способность сети - 100Мбит в сек.
4.12 Требования к перспективам развития, модернизации ИС
Должна быть предусмотрена возможность модернизации и развития ИС без привлечения Разработчика силами администратора ИС на уровне:
- добавления, изменения, удаления справочной информации ИС;
- подключения/удаления новых пользователей ИС;
- изменения паролей;
- импорт/экспорт данных из/во внешние источники данных.
Должна быть предусмотрена возможность модернизации и развития ИС с ограниченным участием Разработчика (телефонные консультации) на уровне модернизации старых и создании новых отчетов. Возможность и условия телефонного консультирования Разработчиком по модернизации ИС оговариваются отдельно путем подписания нового договора.
5. Состав и содержание работ по созданию системы
Работы по проектированию ИС «Учет торговых операций» производятся в три этапа.
Первый этап включает в себя:
Проверку возможности получения всей информации, затребованной Заказчиком, на основе исходных данных;
Проектирование БД ИС;
Заполнение разработанной БД тестовым набором данных;
Разработку дизайна интерфейса пользователя;
Разработка низкоуровневой технической спецификации на разработку ИС «Учет торговых операций»
Окончание первого этапа подтверждается подписание внутреннего Акта о выполненных работах и утверждением низкоуровневой технической спецификации на разработку ИС.
Второй этап - разработка тестовой версии ИС «Учет торговых операций». Окончанием данного этапа является ввод тестовой версии в опытную эксплуатацию.
Третий этап - опытная эксплуатация ИС «Учет торговых операций», включающая в себя устранение выявленных ошибок, недоработок и несоответствий с данным Техническим заданием. Окончанием второго этапа является ввод ИС в промышленную эксплуатацию.
Окончание каждого второго и третьего этапа подтверждается Сторонами договора подписанием Акта приема-передачи.
Длительность первого этапа составляет 10 дней. Началом первого этапа считается день, следующий за днем подписания Заказчиком и Разработчиком БД данного Технического задания.
Длительность второго этапа составляет 20 дней. Началом второго этапа считается день, следующий за днем утверждения низкоуровневой технической спецификации на разработку ИС.
Длительность третьего этапа составляет 20 дней. Началом третьего этапа считается день, следующий за днем подписания Заказчиком и Разработчиком БД Акта приема-передачи тестовой версии ИС в опытную эксплуатацию.
Набор данных для тестирования ИС предоставляет Заказчик.
По окончанию второго этапа работ Разработчик БД устанавливает тестовую ИС на тестовый сервер Заказчика и предоставляет Заказчику предварительное руководство пользователя, содержащее описание процедур, необходимых для работы с ИС «Учет торговых операций». Описания предоставляются в электронном виде.
По окончанию третьего этапа работ Разработчик БД предоставляет Заказчику программу установки базы данных на сервер, также инструкции пользователя, программиста и инструкцию по установке ИС с описаниями процедур, необходимых для работы с ИС «Учет торговых операций».
6. Порядок контроля и приемки системы
По окончанию первого этапа подписывается внутренний Акт о выполненной работе и утверждается низкоуровневая техническая спецификация на разработку ИС.
По окончанию второго и третьего этапов проектирования Разработчик устанавливает ИС у Заказчика, демонстрирует работу ИС в соответствии с требованиями, изложенными в данном Техническом задании, и подписывает Акт приема-передачи.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
В день начала опытной эксплуатации Заказчик обязан предоставить Разработчику необходимый доступ к серверу, на котором будет развернута тестовая версия ИС «Учет торговых операций».
Отсутствие сервера для установки БД ИС «Учет торговых операций» не может являться основанием в отказе подписания Акта приема-передачи ИС «Учет торговых операций» в опытную или промышленную эксплуатацию.
В конце второго этапа по разработке ИС «Учет торговых операций» Разработчик проводит 8-часовой курс обучения с персоналом Заказчика по обслуживанию ИС. По окончанию данного курса персонал Заказчика проходит тестирование.
8. Требования к документированию
По окончанию третьего этапа Разработчик ИС «Учет торговых операций» передает Заказчику следующую документацию:
1. Инструкцию программиста.
В Инструкции программиста описываются процедуры, необходимых для работы с ИС «Учет торговых операций». Описание процедур включает в себя:
Название процедуры;
Описание выполняемых процедурой действий;
Описание входных параметров, с указанием типа параметра, формата его записи и значения по умолчанию, если таковое определено для параметра;
Описание выходных параметров и (или) возвращаемых наборов записей с указанием их типов и форматов
Пример вызова процедуры и возвращаемых ею значений. Если процедура может иметь несколько вариантов вызова, то примеры для каждого варианта.
2. Инструкцию по установке ИС «Учет торговых операций».
3. Инструкция пользователя ИС «Учет торговых операций».
Иная документация Заказчику не предоставляется. Инструкции предоставляются как в печатном, так и в электронном виде. Инструкции в печатном виде предоставляется в одном экземпляре.
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.
ГОСТ 34
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
ГОСТ 19
“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
IEEE STD 830-1998
Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение
- 1. Назначение
- 2. Область действия
- 3. Определения, акронимы и сокращения
- 4. Ссылки
- 5. Краткий обзор
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователя
- 4. Ограничения
- 5. Допущения и зависимости
- 1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
- 2. Функциональные требования
- 3. Требования к производительности
- 4. Проектные ограничения (и ссылки на стандарты)
- 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
- 6. Другие требования
5. Алфавитный указатель
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.
Ну а кто дочитал до конца - тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
- Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
- Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
- Правила составления Software requirements specification (читать вместе с комментариями)
- Примеры ТЗ и другой документации по разработке АС для МЭР
- ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
- Шаблоны документов для бизнес-аналитиков из
Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.
- В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть ?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
- Вторая часть «Разработка Технического задания. Как формулировать требования ?» будет полностью посвящена выявлению и формулировке требований к информационной системе.
Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
- Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
- Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
- Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
- Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
- Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
- Возможны и другие, реже встречающиеся варианты;
Думаю, сейчас у читателя должны возникнуть вопросы:
- А почему нельзя разрабатывать Техническое задание всегда одинаково?;
- Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
- Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
- Как понять, хорошо составлено Техническое задание или нет?
- За чей счет должно оно разрабатываться, да и нужно ли оно вообще?
Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).
Что такое техническое задание?
Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».
Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по середине. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.
Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».
Если кому-то интересно, о каких ГОСТах я говорю, то вот они:
- ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Куда более удачное определение представлено в википедии (правда про ТЗ в целом, а не только для программного обеспечения): «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.)»
И так, как следует из определения, основное назначение Технического задания - сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.
Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.
Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:
- Требования в функциональности;
- Требования к безопасности и правам доступа;
- Требования к квалификации персонала;
- …. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).
Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания .
Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:
- Требование должно быть понятным ;
- Требование должно быть конкретным ;
- Требование должно быть тестируемым ;
Причем последнее свойство невозможно без двух предыдущих, т.е. является этакой «лакмусовой бумажкой». Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное. Подумайте об этом. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На само деле все очень просто. Когда разберешься.
На этом повествование о том, что такое Техническое задание можно было бы завершить и перейти к главному: как формулировать требования. Но не так все быстро. Есть еще один крайне важный момент:
- на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
- Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
- А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?
В ответах на эти вопросы кроется очень коварная вещь. Именно поэтому часто возникают споры о достаточности или отсутствии необходимой детализации требований, о понятности документа Заказчиком и Исполнителями, об избыточности, формате представления и т.д. А где вообще граница между Техническим заданием и Техническим проектом?
Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная Заказчику. Никаких привязок к особенностям технической реализации быть не должно. Т.е. на этапе ТЗ в принципе не важно, на какой платформе будут реализовываться эти требования. Хотя есть исключения. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик. И уж никак не программист (если только он не совмещает в себе эти роли, такое случается). Т.е. этот человек должен говорить с Заказчиком на языке его бизнеса.
Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуются техническим специалистам . Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально). А точнее группа специалистов АО главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.
Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.
Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени - это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.
Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.
А нужно ли вообще техническое задание? А Технический проект?
Не перегрелся ли я? Разве такое возможно, вообще без Технического задания ? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого» . Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.
А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.
Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.
Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»
Формулирование требований к информационной системе. Структура Технического задания
Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.
Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).
Несмотря на то, что формулировка требований является основной частью Технического задания , а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.
- общие сведения;
- назначение и цели создания (развития) системы;
- характеристика объектов автоматизации;
- требования к системе;
- состав и содержание работ по созданию системы;
- порядок контроля и приемки системы;
- требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
- требования к документированию;
- источники разработки.
Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.
Раздел 1. общие сведения.
| Рекомендации по ГОСТ | |
| полное наименование системы и ее условное обозначение; | Тут все понятно: пишем, как будет называться система, ее краткое наименование |
| шифр темы или шифр (номер) договора; | Это не актуально, но можно и указать, если требуется |
| наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; | указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли.Можно вообще удалить этот раздел (достаточно формальный). |
| перечень документов, на основании которых создается система, кем и когда утверждены эти документы; | Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую Вам предоставили для ознакомления с определенной частью требований |
| плановые сроки начала и окончания работы по созданию системы; | Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы |
| сведения об источниках и порядке финансирования работ; | Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников) |
| порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. | Не вижу необходимости в этом пункте, т.к. требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы. |
Раздел 2. назначение и цели создания (развития) системы.
| Рекомендации по ГОСТ | Что с этим делать на практике |
| Назначение системы | С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании». |
| Цели создания системы | Цели – это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит. |
Вообще, умение выделять цели, формулировать их, строить дерево целей это тема совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется.
Раздел 3. Характеристика объектов автоматизации.
Раздел 4. Требования к системе
ГОСТ расшифровывает перечень таких требований:
- требования к структуре и функционированию системы;
- требования к численности и квалификации персонала системы и режиму его работы;
- показатели назначения;
- требования к надежности;
- требования безопасности;
- требования к эргономике и технической эстетике;
- требования к транспортабельности для подвижных АС;
- требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
- требования к защите информации от несанкционированного доступа;
- требования по сохранности информации при авариях;
- требования к защите от влияния внешних воздействий;
- требования к патентной чистоте;
- требования по стандартизации и унификации;
Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным:
- Требования к квалификации . Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
- Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями
- Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правила, такие требования инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.;
- Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.
Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.Требования к функциям (задачам), выполняемым системойВот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье, которая войдет в 5-й выпуск рассылки. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.Требования к видам обеспечения
ГОСТ выделяет такие виды:
- Математическое
- Информационное
- Лингвистическое
- Программное
- Техническое
- Метрологическое
- Организационное
- Методическое
- и другие…
На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования:
- Решения о том, на каком языке (или какой платформе) будет вестись разработка не принято;
- К системе предъявляются требования мультиязычного интерфейса (например, русский/английский)
- Для функционирования системы должно быть создано отдельное подразделения или приняты на работу новые сотрудники;
- Для функционирования системы у Заказчика должны произойти изменения в методиках работы и эти изменения должны быть конкретизированы и запланированы;
- Предполагается интеграция с каким-либо оборудованием и к нему предъявляются требования (например, сертификации, совместимости и пр.)
- Возможны другие ситуации, все зависит от конкретных целей проекта.
Раздел 5. Состав и содержание работ по созданию системы
Раздел 6. Порядок контроля и приемки системы
Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;Настоятельно рекомендую с ответственностью отнестись к порядку сдачи работ и проверке системы. Именно для этого и нужны тестируемые требования.Но даже наличие тестируемых требований может оказаться недостаточно при сдаче системы, если четко не прописан порядок приемки-передачи работ. Например, распространенная ловушка: система сделана, вполне работоспособна, но Заказчик по каким-либо причинам не готов в ней работать. Причины эти могут быть любые: некогда, поменялись цели, кто-то уволился и т.п. И говорит: «Поскольку мы еще не работаем в новой системой, значит и не можем быть уверены, что она работает». Так что учитесь правильно выделять этапы работ, способы проверки результатов по этим этапам. Причем Заказчику такие способы должны быть понятны изначально. Если они зафиксированы на уровне Технического задания, то всегда можно при необходимости к ним обратится и подвести работы с передаче.
Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
Могут быть и любые другие правила ввода информации, принятые в компании (или планируемые). Например, информация о договоре раньше заносили текстовой строкой в произвольном виде, а теперь требуется номер отдельно, дату отдельно и т.д. Таких условий может быть очень много. Часть из них может быть воспринята с сопротивлением персонала, поэтому лучше все такие случаи прописать на уровне требований к порядку ввода данныхИзменения, которые необходимо осуществить в объекте автоматизации
Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗЛюбые изменения, которые могут потребоваться. Например, в компании отсутствует локальная сеть, устаревший парк компьютеров, на которых система не заработает.
Возможно, какая-то необходимая информация обрабатывалась на бумаге, а теперь ее необходимо вводить в систему. Если этого не делать, то какой-либо модуль не заработает и т.п.
Возможно, что-то упрощалось, а теперь требуется учитывать более детально, соответственно кто-то должен собирать информацию по определенным правилам.
Этот перечень может быть длинным, смотрите на конкретный случай своего проекта.Создание необходимых для функционирования системы подразделений и служб;
Сроки и порядок комплектования штатов и обучения персоналаПро это мы уже говорили ранее. Возможно, система разрабатывается под новую структуру или вид деятельности, которого раньше не было. Если не будет соответствующего персонала, да еще и обученного, то система не заработает, как грамотно ее не строй.
Раздел 8. Требования к документированию
Подумайте, как будут представлены руководства пользователя.
Возможно, у Заказчика есть принятые корпоративные стандарты, значит надо к ним обращаться.
Игнорирование требований к документации очень часто приводит к самым неожиданным последствиям на проектах. Например, все сделано и все работает. Пользователи тоже умеют работать. Про документацию вообще не договаривались и не разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика, который даже не участвовал в проекте, но участвует в приемке работ, Вас спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о наличии руководств пользователя договариваться было и не нужно, это «само собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей счет будете разрабатывать руководства? На этот крючок попадали уже многие команды.
Раздел 9. Источники разработки
Поэтому, лучше сослаться просто на отчет об обследовании, требования ключевых лиц.
И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.
Но вот без главного: функциональных требований ни одно грамотно Техническое задание не обходится. Хочу заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.
Во второй статье будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.
Почему требования должны быть понятными, конкретными и тестируемыми.
Потому, что практика показывает: по началу большинство ТЗ, которые разрабатывают специалисты либо оказываются не востребованы (не соответствуют действительности), либо становятся проблемой для того, кто из должен реализовать, т.к. Заказчик начинает манипулировать неконкретными терминами и требованиями. Приведу несколько примеров того, какие фразы встречались, к чему это приводило, а затем попробую дать рекомендации, как избежать подобных проблем.
Тестируемое ли это требование? Вроде бы простая вещь, но как ее проверять, если нет конкретики?
Как можно было бы это переформулировать: «Сумма затрат, указанная в документе, должна распределиться на все товары, указанные в данном документе пропорционально стоимости этих товаров». Получилось и понятно, и конкретно. Как проверить тоже не составит труда.
ЭргономичностьПрограмма должна иметь удобный интерфейсПризнаться, под данной формулировкой пришлось однажды подписаться самому – проблем потом было не сосчитать. Конечно же, подобных формулировок быть не должно. Тут нет не конкретики, ни возможность проверить это требование. Хотя, безусловно, понятное (субъективно). Тут переформулировать никак нельзя, надо подробно расписывать каждый элемент «удобности», раз Заказчик на этом настаивает. Например:
- Строки в документ должны добавляться как по нажатию на кнопку «Добавить», так и при нажатии на клавиши «insert», а также вводе пользователем части наименования;
- При просмотре списка товаров должна быть возможность поиска по наименованию, штрихкоду и артикулу;
- И пр.
Разграничение прав доступаДоступ к данным по прибыли должен быть доступен только финансовому директоруПонятно? Почти. Правда, прибыль бывает разная, надо уточнить.Конкретно? Конечно нет. Как это видится в реализации? Если речь идет о валовой прибыли, то значит необходимо ограничивать доступ к данным о стоимости закупки, т.к. в противном случае валовую прибыль вычислить не составит труда, поскольку данные о стоимости реализации известны широкому кругу лиц. К тому, что относится к правам доступа, надо относиться очень аккуратно. А если у менеджеров по продажам мотивация построена на валовой прибыли, так эти требования еще и противоречат друг другу, т.к. менеджеры никогда не смогут это проверить. Если уж включать такое требование, то нужно указывать конкретные отчеты и объекты системы, в которых указывать, какая часть данных должны быть доступна отдельным категориям лиц. И рассматривать каждый такой случай индивидуально.ПроизводительностьОтчет по продажам должен формироваться за 1 минуту.Да, понятно. И даже есть конкретное ограничение по времени: 1 минута. Но не известно, какая детализация при этом предполагается: по каждому товару, группам товаров, клиентам или как-то еще?Можно сформулировать примерно так: «Отчет по продажам в разрезе клиентов с детализацией до каждой товарной позиции (см. образец) должен выводится не более, чем за 1 минуту при условии, что количество товаров в выборке не превышает 5000 строк».
Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.
Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:
- Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.
- Следует стараться не использовать длинных предложений;
- Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;
- Используйте больше схем, графиков, таблиц, рисунков – так информацию воспринимается гораздо легче;
- Следует избегать таких слов: «эффективный», «адекватный», «простой», «понятный», «быстрый», «гибкий», «улучшенный», «оптимальный», «прозрачный», «устойчивый», «достаточный», «дружественный», «легкий» и др. Перечень можно продолжать, но, мне кажется идея понятна (попробуйте его продолжить самостоятельно).
Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».
В следующей статье мы будем говорить только о методиках выявления требований, а также рассмотрим, что общего между работой по сбору требований к информационной системе и сбору информации для описания бизнес-процессов.
Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов. Часть 2
В этой части мы будет говорить о том, как организовать этап работ по сбору требований, из чего он должен состоять и какими инструментами можно пользоваться. Повторюсь, что данные работы с точки зрения этапов очень похожи на обследование предприятия с целью описания бизнес-процессов.
Как обычно происходит в жизни:
| Как это происходит в большинстве проектов |
|
| Как это происходит |
|
| Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому. | |
| Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать). | |
| Документирование результатов работы | После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много. |
Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».
Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?
Как видим, процесс заканчивается вопросом, т.к. на этом работа далеко не закончена и дальше начнется самое сложное и самое практичное – именно то, что будет определять применимость полученного результата в реальной жизни. Именно то, что будет определять судьбу предыдущей работы: или она отправится в шкаф (на полку или еще куда-нибудь), либо будет представлять собой ценный источник информации. А еще лучше, если она станет образцом для последующих проектов.
Хочу особо отметить, что до последнего шага на схеме (там, где вопрос) общий принцип сбора информации о деятельности компании выглядит одинаково, независимо от того, что планируется делать в дальнейшем, описывать бизнес-процессы или внедрять автоматизированную систему. Да, сама последовательность шагов одинаковая, но инструменты, применяемые на некоторых из них, могут отличаться. Мы данный момент обязательно рассмотрим, когда будем изучать методики и инструменты отдельных этапов. Подробно будем это делать в отдельных статьях, а сейчас рассмотрим только самое главное. Дальнейшие шаги будут отличаться и определяться тем, что требуется от проекта: описать бизнес-процессы или внедрять систему учета.
Давайте посмотрим, как можно реорганизовать подход к сбору информации о деятельности компании.
| Как это может происходить при более грамотной организации работ |
|
| Как это происходит |
|
| Решение принято, проекту быть! | Тут ничего не меняется относительно первого варианта, эмоции никто не отменял |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким. |
| Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей | Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта). Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался. На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная. |
| Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации | Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны. |
| Анкетирование | Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами:
Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый. |
| Опросы | Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи. На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов) |
| Выделение ключевых бизнес- процессов или областей автоматизации | После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом. Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты. |
| Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения | К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов. Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании. При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным. Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется). Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально. |
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
| Что и как делать |
|
| Выделяем бизнес-процесс | Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично. |
| Детальное изучение бизнес- процесса | Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать) |
| Графическое и/или текстовое описание бизнес-процесса (первичное) | Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть. |
| Согласование с исполнителями и владельцем бизнес-процесса | Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить. |
| Выделение показателей бизнес-процесса | После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет. |
| Окончательное документирование бизнес-процесса | После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию. |
| Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов. |
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
| Что и как делать |
|
| Выделяем бизнес-требование/область автоматизации | Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад» |
| Детальное изучение бизнес-требования | Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2. |
| Моделирование требований в информационной системе | Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!» А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы:
Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам. |
| Демонстрация информационной модели рабочей группе | Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной. |
| Разработка тестов | Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно. Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования. |
| Документирование требований в виде Технического задания | Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации. |
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
