 |
Написание технического задания на создание/ изменение ИС
|
|
|
|
Главной целью и результатом Инструмента самопроверки (методики SAT) является написание отчета и плана действий по реализации ICT-проекта. В этих документах не акцентируется внимание на техническом задании (ТЗ) на проектирование информационной системы (ИС). Тем не менее, по ряду причин, изложенных ниже, при адаптации методики SAT к российским условиям вопросы, связанные с ТЗ, целесообразно рассмотреть более подробно. Ни в России, ни за рубежом никто не сомневается, что для успешной реализации любого ICT-проекта, такой документ, как ТЗ, необходим. Правда, называться он может по-другому, например «Технические требования к проекту» или просто «Требования к проекту».
При этом значимость ТЗ или подобного ему документа намного выше в России, чем за рубежом, что объясняется не только спецификой взаимоотношений в российском бизнесе, сложившейся практикой оформления договоров, но и нормативной базой на создание информационных систем.
Российское законодательство не регламентирует текст договоров, состав приложений к договорам, но из практической деятельности постепенно сложились некоторые неформальные правила. При заключении внутрироссийских договоров на поставку оборудования или на работы технические требования в «тело договора» чаще всего не помещаются. Но при этом «Предмет договора» формулируется со ссылкой на выполнение требований ТЗ. При этом ТЗ является неотъемлимой часть договора. Объясняется это тем, что сложившаяся практика учитывает требования нормативных документов советского периода, многие из которых действуют и поныне.
«Техническое задание является основным документом, в соответствии с которым проводят создание автоматизированной системы и приемку его Заказчиком» - это выписка из стандарта серии «Информационные технологии» (ГОСТ 34.602-89 «Техническое задание на создание автоматизированных систем»). Акт о приёмке выполненных работ по договору чаще всего составляется таким образом, что в нём отражаются результаты проверки выполнения требований ТЗ. Такой подход разумен, так как позволяет разрешать конфликтные ситуации, которые при разработке информационных систем и программных продуктов возникают намного чаще, чем при создании проектов другого назначения. Речь идёт конечно о технических заданиях, составленных качественно, то есть о таких, где Заказчик и Исполнитель одинаково трактуют предъявляемые требования. А что получается, в противном случае, иллюстрирует рис.1, где изображена картинка, обошедшая на заре разработки программных продуктов весь мир.
|
|
|
Рис.1. О значении правильного формулирования требований ТЗ
Как показывает опыт работы с зарубежными поставщиками оборудования и услуг на российском рынке, в их договорах присутствуют только спецификации на оборудование, услуги, и прописываются отдельные технические требования по тексту договора. Конечно, это можно трактовать как менее строгий подход, отражающий практику оформления договорных отношений, рассчитанную на ответственные отношения между квалифицированными договаривающимися сторонами. Но если мы опять обратимся к рис.1, то нецелесообразность такого подхода, тем более в российских условиях, станет очевидной. ТЗ должно быть достаточно детализировано для того, чтобы Заказчик получил по содержанию то, что заказывал. Обязательно должно быть прописано (и в российской практике это принято) требование о возможности изменять и дополнять ТЗ в процессе работы по согласованию сторон. При этом согласование сторон должно быть письменно заверено с обязательным фиксированием, как влияет изменение ТЗ на условия и цену договора.
|
|
|
Роль детализированного ТЗ особенно велика на этапе приёмки работы, т.е. на том этапе, когда требуется формализация описания результатов работы: что выполнено в рамках договора, а что – нет. Этого требуют интересы обоих сторон. Как любят повторять опытные специалисты-разработчики информационных систем: «Аппетит приходит во время еды». Действительно, Заказчик в процессе работы над проектом «умнеет» и наращивает объём требований, предусмотренный требованиями Договора. При неконкретном ТЗ в таком случае пострадавшей стороной является Исполнитель. Он вынужден выполнять больший объём работ, чем планировалось по Договору. С другой стороны, не менее часто в роли пострадавшей стороны выступает Заказчик. Речь идёт о случаях, когда Исполнитель по самым разным причинам не стремится в ходе работы излишне уточнять требования Заказчика и многие вопросы решает так, как он их понимает. Так что, при приёмке работ конфликт интересов – обычное дело, и детализированное ТЗ помогает его разрешить.
Детализированное ТЗ играет огромную роль в оценке преимуществ и недостатков различных исполнителей при проведении тендеров. Достаточно проанализировать таблицу показателей удовлетворения требований ТЗ, чтобы получить сравнительную оценку. Детализированное ТЗ позволяет реализовать механизм «приведения к общему знаменателю» различных тендерных предложений.
Отечественные нормативные документы всегда уделяли большое значение ТЗ, не только, как документу, но и как важнейшему этапу (разработки, поставки), т.е. как процессу. Как показывает анализ, за рубежом вопросам ТЗ также уделяется серьёзное внимание, особенно в последние годы в рамках принятой сегодня во всём мире интегрированной модели качества CMMI (Capability Maturity Model Integration). В CMMI две области процессов посвящены работе с требованиями — «Управление требованиями» (Requirements Management) и «Разработка требований» (Requirements Development). Область процессов «Управление требованиями» подразумевает, что организация-Исполнитель получила требования от Заказчика, а область процессов «Разработка требований» — что организации-Исполнителю известны потребности Заказчика, но эти потребности должны быть трансформированы в требования к продукту (проекту). Общепризнанно, что CMMI - большая по объему и сложная для понимания модель. Тем не менее в рамках нашего курса мы обратимся к ней, чтобы продемонстрировать единство взглядов на формирование ТЗ в рамках CMMI и в рамках отечественных ГОСТов.
|
|
|
Общая схема разработки требований, рекомендованная СMMI, представлена на рис. 2. При установлении потребностей Заказчика следует учитывать нужды всех заинтересованных сторон–заказчиков, конечных пользователей, поставщиков, проектантов, тестировщиков. Эти потребности и ожидания, а также налагаемые ограничения, интерфейсы, концепции работы системы и продукта следует тщательно проанализировать, гармонизировать, уточнить и транслировать в комплект требований Заказчика.
Рис. 2. Процесс разработки требований в соответствии с CMMI
По сути СММI рекомендует то, что почти всегда делалось в соответствии с ГОСТами советского периода: Этапу создания продукта (проекта) предшествовал этап проработки требований Заказчика, формализации его пожеланий качественного характера, а также согласования со всеми заинтересованными сторонами будущего проекта. Назывался этот этап аван-проектом, заканчивался аван-проект подготовкой ТЗ. На рис. 3 представлены основные стадии разработки проекта на создание информационной системы, рекомендованные отечественными нормативными документами. Этот рисунок иллюстрирует место появления «Технического задания» в жизненном цикле процесса разработки ТЗ. Но здесь необходимо отметить, что ТЗ не является жёстко зафиксированным документом. Как отмечалось выше, в него по ходу создания ИС могут вноситься изменения и дополнения. Достаточно часто в качестве приложения к ТЗ используется документ «Исходные данные», который в течение разработки проекта постоянно пополняется и совершенствуется.
Рис.3 Место «Технического задания» в процессе создания информационной системы (ИС).
Эта российская практика постоянного совершенствования ТЗ в процессе разработки полностью совпадает с рекомендациями, содержащимися в материалах CMMI.: «Довольно часто потребности, ожидания, ограничения и интерфейсы могут быть плохо установлены на этапе формирования требований или конфликтовать друг с другом. Поэтому данная работа проводится итеративно в течение всего жизненного цикла проекта».
|
|
|
Приведённые результаты сравнения отечественных нормативных требований и практики проектирования с зарубежными рекомендациями, говорит об их схожести. В этих условиях целесообразно более подробно изучать отечественные стандарты, связанные с информационными технологиями и с разработкой программных продуктов. Наибольшее внимание тем, кто хочет научиться технически грамотно составлять техническое задание, следует обратить на следующие нормативные документы:
- ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, ГОСТ 24.602-86).
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85)
- ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем (Взамен ГОСТ 24.104-85 в части разд. 3.)
- РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов. ГОСТ 19.102-77. Единая система программной документации. Стадии разработки.
На основании анализа перечисленных выше документов, предлагается следующий состав документа «Техническое задание на создание (развитие) ИС» для проектов внедрения ИКТ в компаниях малого и среднего бизнеса:
1. общие сведения;
2. назначение и цели создания (развития) ИС;
3. характеристика компании и «цепочки поставок»;
4. требования к ИС;
5. состав и содержание работ по созданию ИС;
6. порядок контроля и приемки ИС;
7. требования к составу и содержанию работ по подготовке компании к вводу ИС в действие;
8. требования к документированию;
9. источники разработки.
Раздел 1) «Общие сведения»:
· полное наименование ИС и ее условное обозначение;
· номер договора;
· наименование компаний Исполнителя и Заказчика ИС и их реквизиты (если ТЗ не является приложением к договору);
· плановые сроки начала и окончания работы по созданию ИС;
· порядок оформления и предъявления Заказчику результатов работ по созданию ИС (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов ИС.
Раздел 2) «Назначение и цели создания (развития) ИС»:
- назначение ИС (вид продукта ICT и перечень мест его установки).
· цели создания ИС (наименования и требуемые значения экономических, технических, технологически или других показателей компании, которые должны быть достигнуты в результате создания (развития) ИС.
|
|
|
