Форум Сообщества Аналитиков

×


Заказчики(Прочитано 11461 раз)
Заказчики : 14 Февраля 2008, 12:17:50
Хочу пожаловаться.
Вчера показывала Менеджеру проекта со стороны заказчика ТЗ.
К ТЗ есть приложения, в них есть диаграммы. Я делала в нотации UML.
Система большая, одни модули пишу я, другие - К. К сделала приложения в виде блок- схем (между прочим, не учитывая реальную нотацию блок схем).
Менеджер пректа со стороны заказчика говорит мне, сделай приложения в нотации блок схем, как у К, чтобы был единый стиль всего ТЗ. Я говорю - у меня тут по ролям - чтобы было понятно, кто что конкретно делает. Он- в виде блок схем разработчику понятнее.
1. Какой разработчик, если ТЗ для бизнес-пользователя пишут...
2. Заставляют делать БЛОХ- схемы - это же 70е годы .... Менеджер тот молодой - лет 30..
Компания заказчика крупная - с филиалами в разных городах России, не гос.
« Последнее редактирование: 14 Февраля 2008, 12:24:27 от Sunshine »



Re: Заказчики Ответ #1 : 14 Февраля 2008, 12:19:10
Не понял, мысль оборвалась не начавшись ...
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Заказчики Ответ #2 : 14 Февраля 2008, 12:43:11
Сочувствую.
Есть такая проблема, вообще понятно, что согласование формата документации должно делаться до собственно разработки ТЗ. Нужно разговаривать со своим руководством, т.к. фактически тебя подставили и это оно отвечает за целостность и соответствие результатов работ (включая формат подачи) ожиданиям заказчика.

Если придётся всё-таки аргументировать нотацию лично, то надо будет сделать фактически мини-консалтинг своими силами, в защиту UML может помочь Юра Булуй.

В принципе если скажем use-case diagram и use-case представить в виде таблицы и нумерованной структуры, соответственно, то это может быть универсальным понятным всем форматом представления.



Re: Заказчики Ответ #3 : 14 Февраля 2008, 12:45:53
Хотя заказчик и молодой, он ничего может не смыслить в uML, а вот блок-схемы могут быть понятнее, таки в институте на информатике заставляли изучать. То что заказчик можнт не понимать разницы между божьим даром и яичницей - это понятно.

Может просто К замочить? :)

Насколько я понимаю в ТЗ Вы публикуете поясняющие схемы, может пояснения в виде блок-схем оказалось гораздо понятнее, чем UML?



Re: Заказчики Ответ #4 : 14 Февраля 2008, 13:44:03
2. Заставляют делать БЛОХ- схемы - это же 70е годы

Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.

А UML всё-таки не является пока общепринятым стандартом, и не стоит, наверное, разрабатывать документы в предположении, что все читатели его знают. Тем более "бизнес-пользователи".
greesha.ru

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



Re: Заказчики Ответ #5 : 14 Февраля 2008, 16:49:48
Может просто К замочить? :)
=)))
Да ладно, пусть живет =)
Главное вместе на один проект не попадать.

Нарисовала уже эти блох схемы =) Заказчик смотрит.

Такой вот вопрос назрел: кто занимался согласованием ТЗ.
Сколько раз заказчик может на доработку отправлять? Пока сроки не иссякнут? =) Причем, он смотрит как менеджер проекта с их стороны, а бизнес пользователям ещё показывал ни разу. Мне кажется, сначала надо уточнить все ли правильно с точки зрения бизнеса, а не то, какое значение будет настраиваемым или менять названия разделов структуры ТЗ (минус ТЗ не по госту).

« Последнее редактирование: 14 Февраля 2008, 16:55:42 от Sunshine »



Re: Заказчики Ответ #6 : 14 Февраля 2008, 17:14:22
Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.

А UML всё-таки не является пока общепринятым стандартом, и не стоит, наверное, разрабатывать документы в предположении, что все читатели его знают. Тем более "бизнес-пользователи".

Это не гос заказчик. У них в официальном документе "Стандарт Компании №..." диаграммы в различных нотациях присутствуют, и ни одной блок схемы...



Re: Заказчики Ответ #7 : 16 Февраля 2008, 02:00:41
А что, реально помогают эти блок-схемы/UML в понимании текста? Может просто текстом описать требования? А динамику описать в виде сценариев :-), и пусть обчитаются :-). Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Заказчики Ответ #8 : 18 Февраля 2008, 10:42:53
А Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?
Документооборот Компании. Сибирская Угольная Энергетическая Компания- www.suek.ru.
В основном Договора, распорядительные документы, входящие, исходящие, внутренние...
Разработка на Lotus.
У них скати Саперов много и активно сейчас трудятся.
Юмл использовала обычные для пользователей - юз кейсы и активити.



Re: Заказчики Ответ #9 : 18 Февраля 2008, 23:21:29
Документооборот ... юзкейсы как текст вполне подошли бы. Но лучше для документооборота использовать диаграммы состояний и навешивать события на переходы, а события -- описывать как действия юзеров или как системные события. И будет достаточно целостная картина такой системы.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Заказчики Ответ #10 : 19 Февраля 2008, 12:19:29
диаграммы состояний не нравятся заказчику. описали статусы в другой нотации. В целом так и есть.




 

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