Порядок работы по проектированию системы(Прочитано 7745 раз)
Добрый день, задание разработать "техническое задание" и "технический проект".

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

Представим что сам ИМ это система, сервис "обратной связи" это подсистема. ТЗ и ТП не обязательно должны быть по госту.

Что писать в ТЗ?
1. Назначение и цели подсистемы
2. Перечень функций реализуемых подсистемой
3. Требования к подсистеме
(тут описываем, функциональные и не функциональные требования)


Что писать в ТП?
1. Постановка задачи
2. Определение ЗЛ
4. Цели ЗЛ
5. ДВИ
6. Описание каждого ВИ


« Последнее редактирование: 30 Марта 2013, 19:18:28 от jura »



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

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

В вашем варианте ТП содержит менее детализированные требования, чем ТЗ. Это будет сбивать с толку людей, привыкших к устоявшейся терминологии. Я бы всё перечисленное для ТП включил в Концепцию, а если в вашем случае концепция не нужна, то в ТЗ.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Вот, нашёл ссылку, позволяющую соориентироваться в терминологии:
http://www.prj-exp.ru/dwh/dwh_stages_of_development.php
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Коллеги,

Я бы все же порекомендовал прочитать оригинал ГОСТа:
http://www.rugost.com/index.php?option=com_content&view=article&id=95
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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



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

А что тогда в ТП писать? :)
Как я понимаю, ВИ это не только способ выявления требований, но и способ реализации.

Или например так: выделить основные бизнес-задачи сервиса и их описать в ТЗ, а уже детали и проектные решения в виде ВИ писать в ТП?



jura,

Вы почитали, что должно содержать ТЗ и ТП?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



jura,

Вы почитали, что должно содержать ТЗ и ТП?
bas, да почитал, и вот что выяснил:
Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке.
Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании.

Вот из этой темы: http://www.uml2.ru/forum/index.php?topic=5238.0
есть комментарий Дениса Бескова:
Цитировать
Давайте возьмём 2 верхних уровня функциональных требований (без технических):

1. Бизнес-требования: «Система должна позволять отправлять почтовые сообщения» — этот уровень лучше описывается атомарными и группированными требованиями такого рода. Эти требования можно хранить в концепции и ТЗ.

2. Требования/решения пользовательского уровня: «Система должна позволять выбирать адресатов письма из адресной книги», «Система должна сообщать о факте успешной отправки письма» можно хранить атомарно, а лучше в способах применения. Эти требования можно документально хранить в приложении к ТЗ или уже в ТП.

Отсюда и вопрос, ВИ является технической реализацией или нет?



Как это описание сценариев использования менее детально, чем требования к функциям системы?

Может быть более детально, а может быть менее детально. Я воспринял в приведенном перечне ДВИ+описание каждого ВИ как концептуальное описание системы.

Если речь идёт о ВИ как о полноценных сценариях пользовательского уровня, то они, конечно, представляют более детальную модель.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Отсюда и вопрос, ВИ является технической реализацией или нет?
ВИ НЕ является технической реализацией.

Можно классификацию требований посмотреть у Вигерса:
http://www.uml2.ru/faq/%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/86-levels-and-types-of-requirements
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Как уже было отмечено выше, надо разобраться с терминами.
ТЗ - это документ, содержащий основные требования к Системе. Насколько подробно он будет написан - ваше дело. Структуру и содержание документа лучше взять по ГОСТ - легче потом в жизни будет (ИМХО).
ТП - это стадия создания Системы, которая включает в себя определенный перечень работ. Одной из таких работ является разработка/оформление документации технического проекта. Перечень документов определен в ГОСТ, но можно согласовать с Заказчиком свой перечень, благо ГОСТ не запрещает. Основной документ технического проекта - пояснительная записка.
Если вы под словами "разработать технический проект" имеете ввиду пояснительную записку, то опять же берите содержание и структуру по ГОСТ и будет вам счастье.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19