ТЗ на разработку и интеграцию
- Войдите на сайт для отправки комментариев
Добрый день!
Извините, что так много пишу, хочется, чтобы сразу всё было понятно.
Совсем недавно вступил в должность руководителя проектов в компании разработчиков (web и win решения).
У нашего потенциального заказчика есть система электронного документооборота, реализованная как web-приложение. Для этой системы мы вероятно будем разрабатывать web-модуль, решающий определенные задачи. Перед тем, как заказчик примет окончательное решение, заключать с нами договор или нет, мы должны написать ТЗ, чтобы затем обосновать сроки и затраты.
ТЗ я до этого не разрабатывал. Сейчас смотрю ГОСТы и статьи по написанию ТЗ.
В данном случае мы будем разрабатывать модуль и интегрировать его с системой заказчика. На первый взгляд для ТЗ по этой задаче подходит ГОСТ 34.602-89.
Читая его у меня возник вопрос, что писать в "назначении и цели создания (развития) системы", "требования к системе", во всех пунктах, описывающих "систему". Что в данном случае будет являться "системой"? Ведь мы реализуем определенную функциональность именно в нашем модуле и всего лишь интегрируем его с системой заказчика.
И еще вопрос: Как оценить время на создание ТЗ? Особенно для новичка. За ТЗ заказчик платит отдельно, поэтому мой начальник просит обосновать время, затраченное на каждый пункт ТЗ.
Какие еще документы будут сопутствовать ТЗ?
Можете заказать это ТЗ мне.
Спасибо за предложение, но, во-первых, наша компания пока не готова привлекать специалистов со стороны, а, во-вторых, я сам заинтересован это ТЗ написать, получить опыт.
Тогда открывайте ГОСТ 34.602 и разрабатывайте ТЗ на РАЗВИТИЕ (модернизацию) системы. Так будет правильно.
Тогда открывайте ГОСТ 34.602 и разрабатывайте ТЗ на РАЗВИТИЕ (модернизацию) системы. Так будет правильно.
Есть еще вариант написать ТЗ на модуль (или компонент) по ГОСТ 19.201-78, и добавить разделы по интеграции. Что думаете?
Чтобы писать ТЗ на развитие АС, нужно будет отталкиваться именно от системы заказчика, описывать её. А в ТЗ по "ГОСТ 19" базовым будет наш компонент, но большое внимание уделим требованиям к интеграции с конкретной системой: архитектура взаимодействия, обмен данными, безопасность.
Заказчик, правда, может попросить писать ТЗ именно по "ГОСТ 36". Но вначале мы покажем ему наше видение ТЗ.
Есть еще вариант написать ТЗ на модуль (или компонент) по ГОСТ 19.201-78, и добавить разделы по интеграции. Что думаете?
На программный модуль - да, без сомнения. Но если сильно расширять разделы будете, то все равно упретесь в ГОСТ 34.602. Лучше сразу с него начните, только "кастрируйте" максимально - оставьте функционал программного модуля и подраздел взаимодействия.
- Войдите на сайт для отправки комментариев
Можете заказать это ТЗ мне. В свое время работал в интересах компании "Электронные офисные системы" ("Дело"), а позже пришлось поработать и с "Оптима-Воркфлоу". Десятка полтора подобных ТЗ разработал. Про трудоемкость и стоимость можете почитать здесь - http://tdocs.su/12136 и http://tdocs.su/12168