Как и зачем документировать требования?(Прочитано 29209 раз)
Re: Как и зачем документировать требования? Ответ #15 : 04 Октября 2009, 17:26:38
В общем, я понял, что пытаюсь тебя отговорить от "правильного" оформления документов по ГОСТ. :) Если потребители твоего документа не предъявляют никаких требований, кроме понятности и здравого смысла, этому только радоваться надо. А ГОСТ использовать только как справочник по возможным разделам.
Да мне он тоже особо не нужен и важен. Этот ГОСТ :). Но есть и иные стандарты: IEEE, ISO и т.п.

В общем твоя позиция мне понятна :)



Re: Как и зачем документировать требования? Ответ #16 : 04 Октября 2009, 17:42:51
Несколько раз сталкивался с тем, что нужно написать ТЗ, а шаблонов  в компании никаких не используется.
Поэтому каждый раз создавал его таким образом, чтобы было понятно тому, кто его читать будет.



Re: Как и зачем документировать требования? Ответ #17 : 04 Октября 2009, 19:03:45
Т.е. описание классов будет составлять программист?
Затрудняюсь ответить точно. Я думаю, что разумно, что описание класса будет осуществлять программист после его разработки. Существующие классы, возможно, будут описываться выделенным человеком или группой людей в сотрудничестве с отделом проектирования и программистами.

Цитировать
При описании он будет пользоваться модулем (назовем это так), который еще на разработан, чтобы получить некоторую информацию об описываемом классе из системы (или среды - непонятно, несколько там систем или одна)?
Скорее всего так. Программист, разработав  класс, будет вызывать модуль (или в нашей терминологии задачу) документирования класса, выбирать проект, топик (возможно топик придется создавать, если он отсутствует) и выгружать из системы описание структуры класса в требуемом формате прямо в справочную систему в указанном ранее топике. Затем вручную будет формировать семантическое описание составляющих класса - т.е. дискрипшен: типа Атрибут Сотрудник - ссылка на справчоник сотрудника, Метод - ПолучитьУченоеЗвание(ДатаАктуальности) - метод предназначен для получение ученого звания сотрудника на указанную дату акутальности.

Цитировать
А сам модуль нужен для того, чтобы ускорить процесс получения информации о классе в процессе описания, и сделать ее единообразной?
Именно так.

Цитировать
И на этот модуль было написано ТЗ, которое кому-то не понравилось?
Да было написано ТЗ в духе ГОСТ 34, которое оказалось непонятным для соотвествующих читателей

Цитировать
Это вопросы по частной задаче (собственно, это и есть задача, как я поняла).
Совершенно верно - это частное ТЗ

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

Цитировать
Так вот о чем речь сейчас - об общей задаче или о частной?
Пока речь идет о частной задаче

Цитировать
Может темы разделить все-таки?
Да возможно Вы правы.

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

Но пожалуй уже поздно :)



Re: Как и зачем документировать требования? Ответ #18 : 05 Октября 2009, 11:01:30
Цитата: Galogen
Затрудняюсь ответить точно. Я думаю, что разумно, что описание класса будет осуществлять программист после его разработки. Существующие классы, возможно, будут описываться выделенным человеком или группой людей в сотрудничестве с отделом проектирования и программистами.

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

IMHO  нужно документировать классы/методы в процессе проектирования, чтобы программист получал готовую спецификацию и только исполнял ее в соответствии с определенными нормативами по времени. Таким образом документация будет создаваться по мере продвижения разработки ДО того, как что-то будет закодировано. Ну а программист станет, наконец, обычным кодером и займет свое положенное место в пищевой цепочке.

Ничего личного.
« Последнее редактирование: 05 Октября 2009, 12:42:08 от Водолей »
Лью воду...



Re: Как и зачем документировать требования? Ответ #19 : 05 Октября 2009, 11:56:09
А если классы разрабатываются программистами? Не везде же есть отдел проектирования, где ребята проектируют, а после чего программист только кодирует.



Re: Как и зачем документировать требования? Ответ #20 : 05 Октября 2009, 12:40:25
и что, пользователь теперь должен документацию писать чтоли, как в соседней теме?
Лью воду...



Re: Как и зачем документировать требования? Ответ #21 : 05 Октября 2009, 14:17:22
и что, пользователь теперь должен документацию писать чтоли, как в соседней теме?
пользователем и будет программист.



Re: Как и зачем документировать требования? Ответ #22 : 05 Октября 2009, 16:19:20
даже если его должность - программист, и он обладает соответствующей квалификацией, с точки зрения системы он всё равно будет ПОЛЬЗОВАТЕЛЕМ, как бы это ни было унизительно для него :о))

Лью воду...




 

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