Gcb[jkjubz

  • 27 нояб. 2011 г.
  • 4119 Слова
АННОТАЦИЯ

В рамках данной курсовой работы будут рассмотрены основные положения ГОСТ 19.201-78 и ГОСТ 19.404-79, а также требования к содержанию и оформлению технического задания.

Содержание

ВВЕДЕНИЕ

Практическая часть
Рано или поздно в жизни разработчика появляется заказчик с неким проектом. Разработчик берется за этот проект, но результатом каждой последующей встречи с заказчикомстановится появление новых функциональных и нефункциональных требований, в то время как сроки сдачи и бюджет остаются прежними.
Для того, чтобы такая ситуация не наступила, с заказчиком нужно договориться заранее. Но нельзя полагаться на какие либо словесные договоренности, разработчик должен максимально себя обезопасить. Разрабатывая программу, он преследует определенную цель, ставит перед собойопределенные задачи. Успех разработки во многом зависит от того, насколько цель будет четкой и ясной. Знакомясь с выполненной работой, заказчик, естественно, будет анализировать, выполнил ли разработчик поставленные задачи, поэтому все требования должны быть четко сформулированы, описаны и согласованы с ним. Для этого составляется техническое задание в соответствии с установленными стандартами.Техническое задание.
Техническое задание (ТЗ) – точная формулировка задачи. Жизненный цикл ПО – системы процедур, правил и инструментальных средств, используемых для разработки и поддержания работоспособности программной системы. Жизненный цикл включает в себя этапы создания программы. Существует множество версий: по Глассу, по ГОСТ ЕСПД, по Майерсу. Все эти версии имеют общие черты и различия, внекоторых версиях, например в ГОСТ ЕСПД, эти этапы объединены в один. Это идея и ТЗ: иногда вместо ТЗ можно встретить требования, но это одно и то же.
У заказчика появляется идея создать программу для решения какой-то бизнес-задачи, он приходит к разработчику. Мы «достаем» из него то, что он в итоге хочет. Как правильно это сделать – отдельный разговор, я бы даже сказала – искусство. После того как мы поняли, чтозаказчик хочет, мы приступаем к созданию ТЗ. Почему именно мы будем использовать ТЗ? Как я уже сказала, первым кирпичиком нашей успешно выполненной работы является точная формулировка задачи. Используя ТЗ, мы как раз формулируем то, что нужно заказчику, в довольно наглядной и формальной форме; кроме того, мы получаем некий план наших действий: согласитесь, когда есть план, работать проще. Еще разповторюсь: избегайте словесных договоренностей, тетрадочек с записанными функциональными и нефункциональными требованиями – нам с вами нужна официальная бумага. ТЗ можно не использовать, когда мы пишем программу для себя, но когда мы пишем программу для кого-то и за определенное вознаграждение, ТЗ необходимо!
Многие из читателей – студенты (я, кстати, тоже), для них пара строк отдельно. Всем нампредстоит писать курсовые, дипломные и прочие работы, и чтобы ваш руководитель знал, что именно в итоге вы должны сделать, сразу же представьте ему ТЗ – поверьте, он будет доволен, заодно подскажет вам, что в нем нужно исправить и т. д. Благодаря этому получите хороший опыт. Лучше, если побурчит руководитель, чем дать возможность наживаться на вас реальному заказчику.
Нужно отметить, что помимоТЗ существуют и другие документы, применяемые в объектном подходе при проектировке систем. В частности, на практике я встречалась с технологией RUP. В ней для формулировки задачи используется не один документ, а целый набор (Vision, Search, UseCases и т. д.). Почему же я использую ТЗ, а не спецификации RUP? Потому что ТЗ более известно в нашей стране, писать его намного проще, особенно если вынепрофессиональный проектировщик и аналитик. Спецификации RUP более подходят для крупных фирм, где есть аналитики, проектировщики, и для фирм, работающих на иностранных заказчиков. Если же вы работаете в одиночку или маленьким коллективом, ТЗ подходит вам больше. К тому же, чтобы использовать RUP, нужно хорошо знать объектный подход к проектированию и UML.
Итак, вы решили, что...
tracking img