Форум Сообщества Аналитиков
Обсуждения => Работа => Тема начата: Sunshine от 14 Февраля 2008, 12:17:50
-
Хочу пожаловаться.
Вчера показывала Менеджеру проекта со стороны заказчика ТЗ.
К ТЗ есть приложения, в них есть диаграммы. Я делала в нотации UML.
Система большая, одни модули пишу я, другие - К. К сделала приложения в виде блок- схем (между прочим, не учитывая реальную нотацию блок схем).
Менеджер пректа со стороны заказчика говорит мне, сделай приложения в нотации блок схем, как у К, чтобы был единый стиль всего ТЗ. Я говорю - у меня тут по ролям - чтобы было понятно, кто что конкретно делает. Он- в виде блок схем разработчику понятнее.
1. Какой разработчик, если ТЗ для бизнес-пользователя пишут...
2. Заставляют делать БЛОХ- схемы - это же 70е годы .... Менеджер тот молодой - лет 30..
Компания заказчика крупная - с филиалами в разных городах России, не гос.
-
Не понял, мысль оборвалась не начавшись ...
-
Сочувствую.
Есть такая проблема, вообще понятно, что согласование формата документации должно делаться до собственно разработки ТЗ. Нужно разговаривать со своим руководством, т.к. фактически тебя подставили и это оно отвечает за целостность и соответствие результатов работ (включая формат подачи) ожиданиям заказчика.
Если придётся всё-таки аргументировать нотацию лично, то надо будет сделать фактически мини-консалтинг своими силами, в защиту UML может помочь Юра Булуй.
В принципе если скажем use-case diagram и use-case представить в виде таблицы и нумерованной структуры, соответственно, то это может быть универсальным понятным всем форматом представления.
-
Хотя заказчик и молодой, он ничего может не смыслить в uML, а вот блок-схемы могут быть понятнее, таки в институте на информатике заставляли изучать. То что заказчик можнт не понимать разницы между божьим даром и яичницей - это понятно.
Может просто К замочить? :)
Насколько я понимаю в ТЗ Вы публикуете поясняющие схемы, может пояснения в виде блок-схем оказалось гораздо понятнее, чем UML?
-
2. Заставляют делать БЛОХ- схемы - это же 70е годы
Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.
А UML всё-таки не является пока общепринятым стандартом, и не стоит, наверное, разрабатывать документы в предположении, что все читатели его знают. Тем более "бизнес-пользователи".
-
Может просто К замочить? :)
=)))
Да ладно, пусть живет =)
Главное вместе на один проект не попадать.
Нарисовала уже эти блох схемы =) Заказчик смотрит.
Такой вот вопрос назрел: кто занимался согласованием ТЗ.
Сколько раз заказчик может на доработку отправлять? Пока сроки не иссякнут? =) Причем, он смотрит как менеджер проекта с их стороны, а бизнес пользователям ещё показывал ни разу. Мне кажется, сначала надо уточнить все ли правильно с точки зрения бизнеса, а не то, какое значение будет настраиваемым или менять названия разделов структуры ТЗ (минус ТЗ не по госту).
-
Блок-схемы действительно до сих являются самым наглядным способом представления последовательности действий для всех причастных к IT, и так будет ещё долгие годы. ИМХО, UML-ские нововведения вроде замены большого ромбика на маленький квадратик ничего по-настоящему нового к ним не добавили.
А UML всё-таки не является пока общепринятым стандартом, и не стоит, наверное, разрабатывать документы в предположении, что все читатели его знают. Тем более "бизнес-пользователи".
Это не гос заказчик. У них в официальном документе "Стандарт Компании №..." диаграммы в различных нотациях присутствуют, и ни одной блок схемы...
-
А что, реально помогают эти блок-схемы/UML в понимании текста? Может просто текстом описать требования? А динамику описать в виде сценариев :-), и пусть обчитаются :-). Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?
-
А Что за софт хоть на который ТЗ делается, какая область деятельности? И какие и для чего использовались диаграммы UML?
Документооборот Компании. Сибирская Угольная Энергетическая Компания- www.suek.ru.
В основном Договора, распорядительные документы, входящие, исходящие, внутренние...
Разработка на Lotus.
У них скати Саперов много и активно сейчас трудятся.
Юмл использовала обычные для пользователей - юз кейсы и активити.
-
Документооборот ... юзкейсы как текст вполне подошли бы. Но лучше для документооборота использовать диаграммы состояний и навешивать события на переходы, а события -- описывать как действия юзеров или как системные события. И будет достаточно целостная картина такой системы.
-
диаграммы состояний не нравятся заказчику. описали статусы в другой нотации. В целом так и есть.