Принципы составления технического задания

Принципы составления технического задания

Введение

Техническое задание (ТЗ) является основным документом, определяющим требования заказчика к системе, в соответствии с которыми осуществляется разработка программного продукта.

ТЗ может разрабатываться на систему в целом и/или на ее составные части.

В ТЗ на систему, включающей группу взаимосвязанных подсистем, следует включать только требования, общие для группы подсистем. Специфические требования для отдельной подсистемы следует отражать в ТЗ на подсистему.

1 Основные подходы к составлению ТЗ

При подготовке технического задания (ТЗ) необходимо придерживаться ряда принципов. Это поможет избежать излишней поверхностности в описании работ по проекту, а также урегулировать интересы консультанта и клиента.

1.       Совместная работа.

2.       Детальное описание результата.

3.       Механизм контроля за ходом проекта и квалификация консультантов.

4.       Согласование результата.

Гибкость.

1.1 Совместная работа

Лучше всего, если первый вариант технического задания (ТЗ) предприятие - заказчик составит еще до подписания контракта на внедрение системы автоматизации. В нем следует описать проблемы, которые необходимо решить в ходе внедрения, и определить желаемый результат. Затем при участии консультантов разрабатывается детальный план работ по реализации проекта в рамках конкретной автоматизации системы, уточняются способы решения поставленных задач, определяются критерии достижения целей проекта.

Но на практике многие предприятия поручают составление технического задания консультантам. Важно помнить, что на основе этого документа определяются стоимость и объем необходимых работ. Поэтому создание и утверждение ТЗ не следует полностью перекладывать на консультанта — эта работа должна проводиться совместно.

Пример:

В компании две трети работы по написанию ТЗ сделали консультанты: исследовали потребности компании, проводили интервью с персоналом и сводили все данные в единый документ. Затем этот документ согласовали с руководством, которые исправили некоторые неточности, допущенные консультантами. Важно отметить, что в момент создания технического задания на внедрение в комании – заказчика шла реструктуризация и некоторые процессы к моменту реализации системы должны были измениться. Например, схема товарных и финансовых потоков, все это заложили в систему что дало в результате успешный результат.

1.2 Детальное описание результата

Много внимания нужно уделить описанию результатов, которые заказчику требуется получить после окончания проекта, и обязательно зафиксировать их в техническом задании. Например, вам необходимо получать отчет о движении товара в соответствующих аналитических разрезах ежедневно в 9.00, то в ТЗ должны быть подробно описаны параметры отчета (строки, аналитика, период, за который составляется отчет) и источники данных для его формирования. Самое важное - не допустить расширенного толкования технического задания, поэтому все источники данных должны быть строго определены. В противном случае, если вы не указали периода или источников данных, конечный результат может сильно отличаться от ваших ожиданий, а доработка потребует дополнительных средств и времени.

Результирующие показатели проекта представляют собой следующее.

1.       Бизнес-модель вашей компании.

2.       Структура плана счетов

3.       Список необходимых документов (отчетов)

4.       Структура данных для генерации отчетов

5.       Структура аналитических кодов

6.       Описание структуры учетной модели в компании

7.       Описание результа работы и методов приемки

Бизнес-модель компании. Это описание бизнес-процессов, которые необходимо реализовать в системе, в виде последовательности действий, совершаемых для получения результата (генерирования проводки, получения отчета). Например, при регистрации в системе сделки продажи проводки по продаже и начислению налогов должны быть сгенерированы только в случае выставления счета-фактуры, что должно быть возможным только после заполнения всех его реквизитов.

Структура рабочего плана счетов с детальным описанием субсчетов второго и третьего порядка, принципов кодировки субсчетов.

Список документов (отчетов), которые должны быть настроены в информационной системе по завершении проекта под конкретную компанию (название документа, описание строк документа и их форматов вплоть до количества знаков, периодичность получения, период формирования, валюта, предприятие, язык отчета и пр.).

Структура данных для подготовки отчетов (описание источников данных для заполнения каждой строки отчета: субсчетов рабочего плана счетов и конкретных значений аналитических кодов и периода, из которого берутся данные).

Структура аналитических кодов с детальным определением значений аналитических кодов, типов полей, принципов присвоения кода.

Описание структуры учетной модели (если речь идет об автоматизации учета). Описание включает альбом проводок (описание деталей проводок, аналитических кодов, которые должны быть внесены при заведении тех или иных проводок или при задействовании того или иного счета), учетную политику (методы учета — ЛИФО, ФИФО, средневзвешенной стоимости, учетный метод начисления амортизации).

Описание результатов работ и методов их приемки (методика и сроки проверки и тестирования клиентом соответствия выполненных работ написанному техническому заданию, протоколирование приемки).

Пример:

Аналитические разрезы, в которых должны быть представлены отчеты, описали в учетной политике они стали основой для отчетных форм внедряемой системы. Но количественные результаты проекта, такие как скорость подготовки отчетов, не прописалась, потому что ни заказчик, ни консультант не смогли точно определить объемы и структуру данных, которые придется анализировать для составления этих отчетов.

1.3 Механизм контроля за ходом проекта и квалификация консультантов

Для эффективного решения проблем, возникающих в ходе реализации проекта, необходима определенная команда, обладающая достаточными полномочиями и компетенцией в рамках проекта. Кроме того, в тех.задании очень желательно определить уровень квалификации консультантов, участвующих в проекте. В противном случае есть риск того, что при описании финансовых процессов консультанты будут путать дебиторскую задолженность с кредиторской.

1.4 Согласование результата

В техническом задании нужно указать ответственных за согласование результата внедрения системы. Ведь результаты работ по проекту должны согласовываться с различными департаментами и службами для внесения корректировок в отчет о проделанной работе. Этот процесс занимает много времени, и при отсутствии разграничения ответственности за данный этап таким согласованием занимается консультант. А оплата работы консультанта почасовая, поэтому он может потребовать за это дополнительное вознаграждение. В то же время справиться с согласованием могут и специалисты предприятия.

Пример:

При приемке результатов очередного этапа внедрения сотрудники соответствующих отделов компании самостоятельно тестировали систему и в специальной анкете отмечали, принимают они результаты или же необходима дополнительная доработка системы. Кроме того, для каждого этапа разрабатывалась практическая ситуация, например приемка товара, консолидация отчетов, переоценка с учетом передачи другому поставщику. Порядок реализации каждой ситуации в системе демонстрировали консультанты

1.5 Гибкость

В техническом задании должны быть предусмотрены механизмы его корректировки (добавление или исключение этапов из проекта) и оговорена система увеличения или уменьшения вознаграждения консультанта для каждого случая. Это позволит избежать конфликтных ситуаций.

Пример:

В контракте оговорено, что в случае конфликтов по поводу полноты выполнения ТЗ привлекается третья сторона (аудиторская фирма), она то и проводит аудит внедрения. На основании выданного заключения решается, кто прав, и производятся соответствующие доработки или выплата компенсации. Но на практике подобные конфликты лучше решать в договорном порядке. На любом предприятии может быть ситуация, когда описанный в задании отчет приходится переделывать, потому что требования к системе изменились. Если консультант заинтересован во внедрении, он пойдет навстречу и доработает программу за разумную плату или даже бесплатно. Если же нет, то требовать от него выполнения большего объема работ, чем описано в техзадании, будет очень сложно.

2 «Подводные камни»

У компаний, привлекающих консультантов для внедрения автоматизированных систем (АС), обычно, возникает довольно много претензий к их работе. Связаны они как с соблюдением сроков выполнения работ, так и с решениями предлагаемыми консультантами.

Со своей стороны, консультанты упрекают клиентов в неумении описать ту задачу, которую необходимо решить с помощью АС, и в постоянном изменении своих требований к системе. Такие противоречия можно решить с помощью технического задания (ТЗ), которое регламентирует требования заказчика к будущей системе и объем работ по ее внедрению. 

2.1 Причины разногласий

В реализации проекта по внедрению АС всегда участвуют две стороны заказчик и исполнитель. В роли заказчика выступает предприятие или его подразделение, в роли исполнителя — IT отдел того же предприятия или, консалтинговая компания. В процессе обсуждения заказчиком и исполнителем предполагаемых результатов проекта решается вопрос о том, какие задачи и в какие сроки должен завершить исполнитель, а также какие ресурсы ему для этого потребуются. И если с собственной IT-службой договориться сравнительно просто, то при общении с внешними консультантами – может возникнуть ряд специфических проблем.

При согласовании целей и задач внедрения системы консультант и клиент фактически разговаривают на разных языках. То, что является очевидным и понятным для компании, может не быть таковым для консультанта. Консультанты же в свою очередь часто не считают нужным объяснять привычные для них технически сложные выкладки и термины, которые, все равно, непонятны заказчику.

Проблема поиска общего языка с консультантами может возникнуть при распределении ответственности и обсуждении набора документов, требуемых для реализации проекта.

Консультанты не всегда понимают особенности ведения бизнеса, стараются подогнать бизнес-процессы компании под имеющийся алгоритм системы, не вникая в тонкости работы. В частности, при описании бизнес-процессов компании не смогли договориться с консультантами о реализации в системе расчетов ретро-бонусов, являющихся важной частью политики продаж.

2.2 Нечеткие требования к проекту

Стороны всегда стремятся упростить процесс обсуждения и согласования объема работ по проекту, чтобы быстрее перейти непосредственно к внедрению. Консультанты по нескольким формальным признакам делают вывод о том, что задачи, стоящие перед заказчиком, являются типичными для данной отрасли или вида деятельности, и предлагают решение, уже применявшееся в таких проектах. Работы в этом случае стоят гораздо меньше, чем разработки уникального решения для конкретной компании. Предприятие, которое стремится сэкономить и время, и средства, с готовностью идет на это. В результате требования к проекту так и остаются нечеткими. С другой стороны, компании-клиенты часто сами апеллируют к предыдущим проектам («сделайте так же») и не отводят времени на детальное ознакомление консультантов со спецификой своего бизнеса. Получается замкнутый круг: заказчик полагает, что консультанту изначально известны все его проблемы, а консультант считает, что эти проблемы стандартны и к ним можно применить однажды разработанное решение. В ходе реализации проекта требования предприятия уточняются и детализируются. Как правило, при этом увеличивается объем задач и, как следствие, сроки и стоимость проекта.

Например, в крупной компании осуществляется проект внедрения информационной системы. Когда система была выбрана и одобрена, а проект внедрения прошел несколько фаз, согласно утвержденному техническому заданию, руководство предприятия решило пересмотреть ТЗ. В результате проект сильно изменился, расширился, а уже внедряемая система оказалась не соответствующей новым требованиям. Сторонам в этом случае не удалось договориться о новом объеме работ, что привело к разрыву отношений и финансовым потерям обеих сторон.

Для того чтобы избежать вероятных конфликтов между заказчиком и исполнителем составляется подробное техническое задание на автоматизацию. В нем определяются терминология проекта, его цели, требования и исходные данные, необходимые для разработки (настройки) системы, а также последовательность этапов проекта внедрения и критерии, по которым компания-заказчик оценивает качество проделанной работы. Этот документ утверждается обеими сторонами и является приложением к договору на внедрение системы.

3 Принципы составления ТЗ (ТЕХНИЧЕСКИЙ РЕГЛАМЕНТ «Процессы жизненного цикла программного обеспечения» RT 38370656 - 002:2006)

Жизненный цикл программной системы состоит из ряда этапов, на которых программная система планируется, создается, внедряется, эксплуатируется, сопровождается и списывается.

Типичная модель жизненного цикла программной системы состоит из шести этапов:

a) предпроектные работы;

b) разработка программной системы;

c) внедрение программной системы;

d) эксплуатация программной системы;

e) сопровождение программной системы;

f) утилизация программной системы.

Используя указанные этапы и процессы, поставщик совместно с заказчиком должны создать модель жизненного цикла конкретной программной системы.

Начало и конец каждого этапа и процесса должны быть документально оформлены в установленном в организации порядке.

3.1 Этап предпроектных работ

Этап предпроектных работ начинается с первоначального осознания потребности создания новой или модификации существующей автоматизируемой информационной системы (АИС) (группы АИС) или путей автоматизации деятельности и процессов. Данный этап является периодом начального изучения, сбора фактов и анализа, изучения действующего законодательства и существующей организационной структуры, обзора аналогичных существующих АИС. Для разработки выходных документов данного этапа разработчику требуется обратная связь с пользователями.

Посредством анализа, определения осуществимости, оценки затрат, маркетинга, интеллектуальных способностей и материально-технического снабжения, изучения альтернатив, а также экспериментальной разработки, вырабатываются одно или несколько альтернативных решений для удовлетворения потребности заказчика или реализации концепции. Также на этом этапе определяется потребность в одной или нескольких подсистемах для реализации программной системы.

Выходными элементами этапа предпроектных работ являются следующие основные артефакты:

— концепция системы;

— бизнес–предложение.

На этом этапе принимается решение: продолжать реализацию программной системы или прекратить дальнейшую работу.

3.2 Этап разработки

Этап разработки начинается с достаточно подробного уточнения требований заказчика и проектного решения и преобразует их в один или несколько жизнеспособных программных продуктов, которые обеспечивают работу в течение этапа эксплуатации. На этом этапе программная система может быть прототипом.

Оговариваются, анализируются, разрабатываются, создаются, испытываются и, при необходимости, оцениваются механизмы взаимодействия программных элементов и организационных структур, а также определяются требования к аппаратным средствам, инфраструктуре пользователя, обучению и сопровождению.

Результатом выполнения этапа являются разработка программного продукта, работоспособность и функциональность которого подтверждена квалификационными испытаниями, необходимой документацией, а также проведение других необходимых разработок.

На этом этапе посредством привлечения всех заинтересованных сторон обеспечивается включение в проект аспектов будущих этапов, а также требований и возможностей соответствующих систем обеспечения. При этом требуется обратная связь с заинтересованными лицами, которые отвечают за реализацию последующих этапов.

Выходными элементами этапа разработки являются следующие основные артефакты:

— техническое задание;

— технический проект;

— версия программной системы;

— техническая документация;

— протокол квалификационного тестирования;

— акт передачи в опытную эксплуатацию.

В случае объявления тендера на разработку программной системы техническое задание должно являться составной частью тендерного предложения.

Планирование этапа разработки начинается на предыдущем этапе, чтобы обеспечить наличие или возможность создания в организации инфраструктуры систем обеспечения разработки, состоящей из методов, технических средств, инструментов и компетентных людских ресурсов для осуществления анализа процессов, моделирования, создания прототипов, проектирования, интегрирования, испытания и документирования. Эти элементы разрабатываются или приобретаются по мере необходимости для поддержки этапа разработки.

3.3 Процессы жизненного цикла программной системы

Определенные в настоящем техническом регламенте процессы жизненного цикла программной системы могут использоваться любой организацией (подразделением), приобретающей и использующей, и/или создающей и поставляющей программную систему. Процессы могут применяться на любом уровне в иерархии программной системы и на любом этапе жизненного цикла программной системы.

Процессы жизненного цикла программной системы базируются на принципах модульности (максимальная связанность функций процесса и минимальная связь между процессами) и ответственности (процесс ассоциируется с ответственностью за его реализацию). Функции, выполняемые этими процессами, определяются специфическими целями, требуемыми результатами и наборами деятельностей, которые составляют этот процесс.

Любой процесс, применяемый в жизненном цикле программной системы, продолжителен во времени. Структурно он может состоять из трех фаз, как показано на рисунке 3.

Структура выполнения процессов

Во время подготовительной фазы может происходить ознакомление с предметной областью, изучение результатов ранее выполнявшихся процессов, производиться предварительные планирование и расчеты.

Во время активной фазы происходит непосредственное выполнение процесса. В настоящем техническом регламенте при описании процессов освещаются действия только активной фазы.

Страницы: 1, 2