|
Технология программирования
| |
| freespace | Дата: Пятница, 20.04.2012, 05:49 | Сообщение # 1 |
|
Группа: Удаленные
| Взято с http://www.programmersclub.ru/О-правильном-составлении-ТЗ-Часть-1/
Содержание ТЗ:
1. Введение
1.1. Наименование программы
1.2. Краткая характеристика области применения программы
1.3. Сроки исполнения работ
2. Основания для разработки
2.1. Заказчик
2.2. Исполнитель
2.3. Основание для разработки
3. Назначение разработки
3.1. Общая концепция системы
3.2. Описание функциональности системы
4. Требования к программе
4.1. Требования к информационным структурам и методам решения
4.2. Требования к функциональным характеристикам
4.3. Требования к надежности
4.3.1. Требования к обеспечению надежного функционирования системы
4.3.2. Типы отказов при работе с системой
4.3.3. Время восстановления после отказа
4.3.4. Допустимые потери данных при отказе
4.3.5. Важная информация, которая должна быть защищена от разрушения
4.3.6. Отказы из-за некорректных действий пользователей системы
4.4. Условия эксплуатации
4.4.1. Климатические условия эксплуатации
4.4.2. Требования к квалификации и численности персонала
4.5. Требования к составу и параметрам технических средств
4.5.1. Требования к серверному аппаратному обеспечению
4.5.2. Требования к клиентскому аппаратному обеспечению
4.5.3. Требования к сетевому аппаратному обеспечению
4.6. Требования к информационной и программной совместимости
4.6.1. Требования к исходным кодам и языкам программирования
4.6.2. Требования к программным средствам, используемым программой
4.6.3. Требования к защите информации и программы
4.7. Маркировка и упаковка
4.8. Транспортировка и хранение
4.9. Специальные требования
5. Требования к программной документации
6. Технико-экономические показатели
7. Стадии и этапы разработки
7.1. Стадии разработки
7.2. Этапы разработки
7.3. Содержание работ по этапам
8. Порядок контроля и приемки
8.1. Виды испытаний
8.2. Общие требования к приемке работ
9. Порядок корректировки Технического задания
Наименование программы
В данном пункте все довольно просто и банально… Мы просто пишем имя нашей программы. Ничего сложного, главное наша фантазия.
Краткая характеристика области применения программы
Здесь описываем, в какой предметной области будет применяться наше творение. Для того чтобы было более понятно приведу пример из моей практики: Программа применяется для автоматизации учета имеющихся книжных изданий, имеющихся читателей, выдачи книжных изданий.
Сроки исполнения работ
Вот мы и подошли к одному из самых сложных пунктов. Наверное, многие читали байку о том, как программисты строят дом. Для тех, кто не слышал, обязательно прочитайте. Да я согласна ставить перед собой сроки выполнения работ тяжело. Часто мы не укладываемся в указанные нами сроки. С чем же это связанно? С тем, что мы не умеем планировать свое время, не можем правильно рассчитать количество ресурсов, которые нам понадобятся для достижения поставленной цели, также нельзя сбрасывать со счетов прочие форс-мажорные обстоятельства.
Вообще советую прочитать такие книги как:
- Фредерик Брукс: «Мифический человеко-месяц или как создаются программные системы»
- Йордан Э., Йордон Эдвард: «Путь камикадзе: Как разработчику программного обеспечения выжить в безнадежном проекте»
Описывать этот пункт в общих чертах и на основе своих проектов, довольно сложно. Нужно помнить, что проекты могут отличаться в корне: сложностью, количеством исполнителей, профессионализмом исполнителей и т.д. Поэтому просто скажу: читайте про управление проектами, в частности про Project Time Management.
Но программу мы пишем для конкретного заказчика, и не факт что заказчик не поставит перед нами какие-то свои сроки. Скорее всего, поставит. Что же нам делать в этом случае? Мы на время забываем про сроки, предложенные или навязанные заказчиком, и рассчитываем их самостоятельно. Дальше все будет зависеть от того, насколько наши сроки и сроки заказчика будут отличаться. Если они совсем не различаются или заказчик предлагает более длительный срок, мы соглашаемся. Ни в коем случае нельзя говорить заказчику: «Что это за гигантские сроки, мы справимся в 2 раза быстрее». Мы, конечно, теоретически сможем это сделать, а если мы сократим сроки и не успеем, мы останемся в «минусе». Поэтому некий запас во времени никогда не помешает. Мы рассмотрели оптимальный вариант, но сроки, предложенные заказчиком, могут оказаться меньше. Что же делать в таком случае? Вариантов немного – всего 3.
- Первый вариант: сразу же скажу он самый наихудший. Согласиться на эти сроки. Почему же? Если сроки чуть меньше наших, это не смертельно, но довольно опасно. Согласитесь, работать на износ довольно тяжело, но все-таки возможно, вот только не известно насколько это уменьшит реальные сроки, и уменьшит ли. Вообщем решать придется самостоятельно, во многом решение будет зависеть от того насколько вас заинтересует проект и какие риски появятся, если вы не уложитесь в сроки.
Но, если сроки отличаются сильно, и мы беремся за этот проект, проект сразу, же можно записывать в безнадежные, а нам готовить компенсацию заказчику, потому как зачастую заказчику не достаточно фразы: «подождите еще месяц и все будет сделано». Нет, конечно, заказчик может подождать месяц, но вот, если нам понадобится второй, заказчик задумается, и все может закончиться плачевно для нас. Заказчик сможет наказать нас рублем или еще хуже – обратиться в суд, нужно отметить, что основания для этого у него будут. Также может пострадать наша репутация, и если заказчику понадобится еще какая-либо программа, вероятно, что к нам он уже не обратится, еще и отговорит своих партнеров и просто знакомых.
Тут мы снова подошли к мысли о том, что ТЗ документ официальный. И если там написано, что мы должны завершить свою работу 12.12.2010, то мы должны это сделать.
- Второй вариант: отказаться от выполнения этого проекта.
- Третий вариант: самый наилучший для нас, но не факт что это устроит заказчика. Необходимо ему объяснить, что уложиться в сроки, предложенные им нереально. Сделать это нужно в доступной для его понимания форме.
В заключение хочу сказать, что начинать нужно именно с 3 варианта. Заказчик тоже человек, и если грамотно аргументировать, почему наше детище не может родиться быстрее определенного нами срока.
Заказчик
В данном пункте нет ничего нетривиального, просто пишем, кто является нашим родным и любимым заказчиком
Исполнитель
Данный пункт похож на предыдущий, но есть одна особенность, если мы работаем в команде, необходимо упомянуть обо всех участниках проекта, указать одного себя любимого недостаточно. Нет, конечно, это можно сделать, но в таком случае, за все косяки будем отвечать самостоятельно. Заказчику будет все равно, что это ошибка Васи, которого заказчик никогда не видел, и ранее о нем не слышал.
Основание для разработки
Еще один довольно важный пункт. В большинстве случаев помимо ТЗ, заказчик и исполнитель заключают договор, за подробностями обращаемся к гражданскому и трудовому кодексам. В ТЗ указываем, что был подписан договор на указание услуги по созданию программного продукта, указываем номер договора. Если договора нет, этот пункт будет отсутствовать.
Общая концепция системы
Для того чтобы написать этот пункт необходимо провести анализ предметной области для которой предназначена наша программа, определить какие бизнес-задачи будут решать с ее помощью. Но в данном пункте не требуется глубокий анализ, все это ждет нас впереди. Просто описываем, зачем же наше творение создается, и какой же от него будет толк. Для того чтобы более понятно приведу пример: Система позволяет организовать работу библиотекаря, систематизировать информацию об имеющихся книжных изданиях, студентах, преподавателях и сотрудниках использующих библиотеку.
Описание функциональности системы
Вот мы и подошли к одному из самых важных пунктов. Именно в этом пункте описываются функциональные требования к приложению. Если вдруг случится так, что заказчик предъявит нам претензии, это будет, чуть ли не первый пункт проверки экспертов. Поэтому его написанию стоит уделить особое внимание. Именно здесь в большей степени описывается то, что от нас хочет заказчик. Но не нужно забывать, что в половине случаев, заказчик сам не совсем понимает, что, же его душе хочется увидеть в нашем творении, и мы должны каким-то образом это из него вытянуть. Как уже писала в предыдущей статье, это отдельное искусство. Договоримся, что все функциональные требования были сформулированы, осталось их записать в ТЗ.
Как же это сделать? Если в системе представлено несколько категорий пользователей, мы должны это отразить. Кроме того все функции нужно разделить между этими категориями. Если такого разделения нет, то просто перечисляем функции, которые будет выполнять наше приложение.
Есть небольшой нюанс, если приложение добавляет/изменяет какие-либо данные, в скобках необходимо написать какие именно данные добавляются/изменяются. В противном случае, когда при сдаче программы в эксплуатацию заказчик скажет: «А почему в этой табличке нет поля телефон» мы не сможем ему аргументировано возразить. А в случае если мы укажем, какие именно поля содержит таблица, мы просто показываем заказчику документ, в котором написано что этого поля быть не должно.
Требования к информационным структурам и методам решения
Название данного пункта звучит страшно, но на самом деле ничего страшного и не понятно в нем нет. Просто описываем, какие технологии будут применяться в нашем приложении. Чтобы стало совсем понятно, приведу пример: система должна быть реализована согласно технологии «клиент-сервер»; В качестве сервера используется СУБД – сервер; Взаимодействие клиентской и серверной частей системы должно осуществляться согласно протоколу TCP/IP.
Требования к функциональным характеристикам
Этот пункт дублирует пункт Описание функциональности системы, только в более литературной форме. Также здесь описывается, каким образом реализуется взаимодействие с пользователем, например, при помощи набора первичный и вторичных форм.
Требования к обеспечению надёжного функционирования системы
Вот мы и добрались до формальных пунктов, которые пишутся по шаблону. В данном пункте описывается что должен предпринимать заказчик для того чтобы наша программа работала надежно. Просмотрев большое количество ТЗ, я пришла к выводу, что текст данного пункта везде одинаков, поэтому просто приведу его ниже.
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
- Организацией бесперебойного питания технических средств;
- Использованием лицензионного программного обеспечения;
- Регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
- Регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов;
Типы отказов
Следующий пункт, текст которого тоже не меняется. Здесь мы просто описываем, какие типы сбоев возможны. В процессе работы системы могут случаться отказы следующих типов:
- Сбои в подсистеме работы с сетевыми соединениями (ошибки, связанные с передачей информации между сервером и клиентами, а также ошибки при работе с базой данных системы);
- Отказы, вызванные сбоем электропитания технических средств (иными внешними факторами);
- Отказы, вызванные неисправностью технических средств;
- Отказы, вызванные не фатальным сбоем (не крахом) операционной системы;
- Отказы, вызванные фатальным сбоем (крахом) операционной системы.
Время восстановления после отказа
Этот пункт напрямую связан с предыдущим. Мы просто указываем, какое количество времени понадобится на восстановление работы нашего приложения при возникновении сбоев типы, которых описаны выше. Причем конкретное время в минутах указывать не обязательно. Допустим, если произошел отказ, вызванный фатальным сбоем операционной системы, достаточно написать: время восстановления не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
Допустимые потери данных при отказе
Каким бы надежным приложением не было наше приложение, сбои в его работе и работе операционной системы и технических средствах возможны. Для того чтобы заказчик знал чего же ему ждать после сбоя как раз и пишется этот пункт. Мы, конечно же, мы можем написать, что при сбое данные потеряны, не будут. К сожалению это вариант утопический. Полная противоположность этому варианту, данные будут потеряны полностью. Но это не устроит нашего любимого заказчика. Думаю, это никого не устроит, тем более, когда транзакциями, механизмами резервного копирования и восстановления никого не удивишь. Думаю для того чтобы стало понятно что писать, я приведу пример: при сбое в подсистеме работы с сетевыми соединениями допускается потеря информации, относящейся к тому справочнику или к той читательской карточке, о которой информация передавалась по каналу связи в момент сбоя. Главным критерием при определении допустимых потерь информации при сбое в перечисленных компонентах является сохранение целостности данных системы.
Важная информация, которая должна быть защищена от разрушения
Почти в каждом приложении есть информация, которая всегда должна оставаться целостной. Данный пункт предназначен для того чтобы зафиксировать что именно относится к наиболее важной информации, какие именно данные необходимо обезопасить в первую очередь. Допустим, что наше приложение работает с какой-либо БД, то, прежде всего, необходимо обеспечить целостность этой БД.
Отказы из-за некорректных действий пользователей системы
Всегда нужно помнить о том, что пользователи бывают разные. Исходя из личного опыта, половина из них общается с компьютером на Вы. Следовательно, наше творение должно терпеть все нападки таких пользователей и не падать. Поэтому срочно вспоминаем про try catch =) Нет, конечно, можно не обрабатывать ошибочные ситуации, но это не правильно. Поэтому в данном пункте пишем, что такие отказы не возможны и реализуем это.
Климатические условия эксплуатации
Работа программы зависит от того сможет ли работать технические средства в данных климатических условиях, поэтому пишем: климатические условия эксплуатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Требования к квалификации и численности персонала
Здесь указываем минимальное количество персонала, который будет работать с нашей программой, также описываем требования к их образованию. Также для каждого пользователя указываем, какие задачи он будет решать, используя наше приложение.
Требования к составу и параметрам технических средств
Все мы хотя бы раз играли в компьютерные игры, держали коробочку от диска, на которой пишут какими характеристиками должен обладать компьютер, чтобы мы могли насладиться игрой. Вот замечательный пример, иллюстрирующий данный пункт ТЗ.
Требования к исходным кодам и языкам программирования
Данный пункт предназначен для отображения прихотей очень привередливых заказчиков разбирающихся в языках программирования. Если по каким-то причинам заказчик просит или требует, чтобы приложение было написано на конкретном языке, именно это отмечаем в данном пункте. Также здесь отмечаем, хочет ли получить заказчик исходники программы.
Требования к программным средствам, используемым программой
Здесь описываем, что же из стороннего софта необходимо для работы нашей программы, начиная с операционной системы и заканчивая каким-нибудь ODBC-драйвером.
Требования к защите информации и программы
Нам может несказанно «повести» и заказчик скажет, что в его приложении будет обрабатываться коммерческая тайна или еще хуже персональные данные или государственная тайна. В таком случае нам придется читать различные ФЗ и реализовывать все требования описанные там. А в ТЗ необходимо отметить какие именно требования по защите информации были выполнены. Но все может быть проще в том случае если заказчик просто попросит сделать авторизацию или что-то подобное.
Если же заказчик не предъявляет никаких требований к защите информации, мы должны не забыть указать это, чтобы исключить какие-либо вопросы при сдаче проекта.
Маркировка и упаковка
В данном пункте описывается, по какому принципу будут нумероваться версии данной программы. Также указывается, на каких носителях программа будет распространяться.
Транспортировка и хранение
Увидев этот пункт впервые, я улыбнулась, потому как что в нем писать не понятно. До сих пор данный пункт остается загадкой, поэтому просто приведу, если можно так выразить свою отписку: специальных требований к транспортировке и хранению не предъявляется.
Специальные требования
Для чего нужен данный пункт? Поясню, если у заказчика остались требования, которые мы не сможем включить ни в один из предыдущих пунктов, то записываем их сюда. Зачем их вообще записывать? Не забываем, что именно ТЗ определяет «все ли мы сделали» и в нем должны быть указаны все требования заказчика.
|
| |
| |
| freespace | Дата: Пятница, 20.04.2012, 05:53 | Сообщение # 2 |
|
Группа: Удаленные
| Требования к программной документации
Это один из самых простых пунктов ТЗ, хотя это недолжно уменьшать его значимости. Тут стоит еще раз отметить, что ТЗ документ официальный. В данном пункте мы описываем, какая документации будет идти вместе с нашей программой. Возможно, некоторые возмутятся, а зачем вообще какая-то документация, у нас же в программе есть help? Задам встречный вопрос, а чем программный продукт отличается от программы? Одним из отличий является как раз таки наличие документации, причем качественной документации, написанной и оформленной также по ГОСТам. Да, да и тут ГОСТЫ. Для того чтобы сориентировать вас перечислю названия: «Руководство оператора», «Руководство системного программиста» и т.д. На самом деле подобных руководств много. Да байка про программы приходящие в больших коробках с кучей руководств – это правда. Это идеал, к которому необходимо стремиться. Именно поэтому в крупных компаниях есть должности технических писателей.
Технико-экономические показатели
Вот мы и добрались до финансовых вопросов. Сразу же хочу признаться, действительно крупных проектов у меня еще не было, поэтому этот пункт я опишу очень сжато, чтобы не ввести вас в заблуждение. В данном пункте, если разработка по своей идее не уникальна, стоит произвести сравнение стоимости с другими аналогами, показать что заказчик сможет выиграть за счет использования нашей программы. Если разработка уникально и финансист из вас не очень можно отписать следующей фразой: ориентировочная экономическая эффективность не рассчитываются. Аналогия не проводится ввиду уникальности предъявляемых требований к разработке.
Но в идеале необходимо расписать, какие преимущества именно с точки зрения ресурсов наш заказчик получит, а также необходимо разъяснить, за что заказчик будет платить нам деньги.
Стадии разработки
В данном пункте необходимо указать, через какие стадии разработки пройдет наша программа. Тут существует огромное количество всевозможных вариантов. Это объясняется тем, что существует не один способ создания ПО. Например, существуют каскадная и итерационная модели. Все будет зависеть в первую очередь от специфики проекта, во вторую очередь от разработчика. Но, если вы разработчик не очень опытный, а быть может это ваш первый проект или вы пишите систему (скажем для наших госорганов), то для вас есть ГОСТ. Называется этот ГОСТ: «ГОСТ 19.102-77 ЕСПД Стадии разработки». В этом документе и расписаны все стадии, кроме того, каждая стадия поясняется. Поэтому советую использовать поначалу именно этот ГОСТ. Но если ваш проект не очень большой и вы не любите изучать ГОСТы, предлагаю вам упрощенный вариант этого пункта ТЗ:
- Разработка технического задания
- Рабочее проектирование
- Внедрение
Этапы разработки
В данном пункте происходит разбиение стадий на более маленькие этапы, опять же данный пункт будет зависеть непосредственно от конкретной ситуации. Но все, же необходимо не забывать о ГОСТе, про который я упомянула выше, там все стадии как раз таки разбиты на этапы. И все же рискну посоветовать вам, использовать именно данный ГОСТ. Криво на вас после этого никто не посмотрит, ну, наверное, кроме иностранных заказчиков, и то, только потому, что в их странах разработаны подобные ГОСТы, и им будет более понятно и приятно, если стадии и этапы будут совпадать с теми, которые описаны в ГОСТах их стран.
Содержание работ по этапам
В данном пункте необходимо еще более детализировать стадии разработки. В ГОСТе это тоже есть. Зачем же нам это нужно? В прошлой статье я говорила о том, что одной из самых важных вещей в ТЗ является указание сроков выполнения работ. Какая же связь между этими 2 пунктами?
Думаю, вы и в повседневной жизни замечали, что если у нас есть большая задача, требующая для своего выполнения большого количества времени, но сроки выполнения ограничены. Дела идут намного лучше, если разбить ее на более маленькие и определить даты окончания каждого маленького этапа. Мы, ориентируясь по этим срокам намного проще сможем определить успеваем-ли мы, сколько еще времени понадобится, чтобы завершить дело в целом, может нам стоит ускорить выполнение. Вообщем плюсов уйма, а явных минусов не видно.
Именно этот прием стоит использовать и в разработки ПО, также благодаря этому мы в любой момент сможет отчитаться перед заказчиком о том, как у нас идут дела. И он будет хоть, сколько-то уверен в благоприятном исходе. И мы сможем себя контролировать, и если что подкорректировать свои действия.
|
| |
| |
|
