Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Тема начата: lenat82 от 28 Октября 2010, 12:02:35
-
Пробовал по верхам разные инструменты для рисования диаграмм (не "case-средства"), лучше доски, фломастеров и бумажных наклеек ничего не нашёл. Доску при необходимости фотографирую. Если очень уж хотят получить "красивую картинку" для презентации, использую Visio, но каждый раз плююсь.
Некоторые мысли по теме. (http://www.greesha.ru/index.php?livejournal_page&id=1263810411)
Рисовать в редакторе быстрее, чем на бумаге, так и не научился - наверное, необходимости не было.
Согласна с greesha. Рисовать диаграмы мне лично с помощью ПК для меня достаточно трудно. Потому использую подручные средства, в крайнем случае простейший редактор.
-
Пробовал по верхам разные инструменты для рисования диаграмм (не "case-средства"), лучше доски, фломастеров и бумажных наклеек ничего не нашёл. Доску при необходимости фотографирую. Если очень уж хотят получить "красивую картинку" для презентации, использую Visio, но каждый раз плююсь.
Некоторые мысли по теме. (http://www.greesha.ru/index.php?livejournal_page&id=1263810411)
Рисовать в редакторе быстрее, чем на бумаге, так и не научился - наверное, необходимости не было.
Рисовать руками безусловно проще, быстрее и даже наверно эффективней. Но такой рисунок не всегда можно вставить в ТЗ
-
В ТЗ вообще рисунки лучше не вставлять.
А вот в описание проектного решения можно.
Visio во всем.
-
В ТЗ вообще рисунки лучше не вставлять.
А вот в описание проектного решения можно.
Visio во всем.
То есть вы не добавляете диаграммы в ТЗ ?
-
зависит от заказчика. Некоторым нет дела до непонятных рисунков - они только раздражают.
-
То есть вы не добавляете диаграммы в ТЗ ?
Стараемся не добавлять.
Только контурное видение.
Например, система состоит из таких-то подсистем.
А дальше требования к системе (подсистема - должна быть возможность делать что-то).
Потому что не всегда сначала можно точно определить сам процесс.
А ТЗ это фиксация фактом, как потом сдавать?
Пишем ТЗ, думаем сразу о ПМИ.
-
Стараемся не добавлять.
Только контурное видение.
Например, система состоит из таких-то подсистем.
А дальше требования к системе (подсистема - должна быть возможность делать что-то).
Потому что не всегда сначала можно точно определить сам процесс.
А ТЗ это фиксация фактом, как потом сдавать?
Пишем ТЗ, думаем сразу о ПМИ.
Ну а если есть требования к структурам данных например и связях между ними. Тоже описываете словами?
-
А как потом внести небольшое изменение в сфотографированную диаграмму? :)
-
А как потом внести небольшое изменение в сфотографированную диаграмму? :)
А как вы вообще вномите изменение в согласованное с заказчиком ТЗ ? Или показали одно, а сделали другое ?
-
2LastLegion86:
А как потом внести небольшое изменение в сфотографированную диаграмму? :)
Думаю тут вопрос чисто технический. Заново рисуете на доске и фотографируете? :-)
-
зависит от заказчика. Некоторым нет дела до непонятных рисунков - они только раздражают.
Моя схема работы с диаграммами такова: сначала всегда рисую на бумаге от руки карандашом, обдумываю, а позже переношу всё это дело в средство моделирования и там уже осуществляю доводку до ума. MS Visio (хотя не особо люблю этот продукт) - в основном для схематичных рисунков, поясняющих то или иное решение. Например, концепцию Системы (часто вставляю в начальные разделы ТЗ, чтоб было понятно о чём речь). StarUML и подобные - для UML-моделирования (диаграмма вариантов использования, которые потом описываю как требования к Системе). Пока схема работы такая. Может с течением времени и набором опыта буду действовать по-другому.
-
А как потом внести небольшое изменение в сфотографированную диаграмму? :)
Если диаграмма осталась на доске, то дорисовать там же и заново сфотографировать. Поэтому, кстати, желательно иметь несколько досок. Вон в "Яндексе", говорят, почти все стены покрыты белым пластиком, на котором можно писать.
Если снимок только в архиве, то распечатать старую картинку, дорисовать прямо на ней, снова отсканировать и положить в архив. :)
Но чаще всего эти картинки нужны только разработчику, а после реализации они выбрасываются.
Да, я понимаю, что этот подход имеет смысл только в небольшой команде. Если ТЗ (требования, тех.проект, и т. п.) разрабатывает одно подразделение, а реализует другое, да ещё с большим временным разрывом, то его использовать трудно. А если их производственные культуры несовместимы, то и невозможно.
-
Ну а если есть требования к структурам данных например и связях между ними.
Ситуации разные бывают. В данном случае главное есть требования.
В ТЗ можем и рисунок из Visio вставить (тк данное ПО в основном и стоит у сотрудников).
Но обязательно добавить, что это предварительная структура и на стадии тех проектирования может быть изменена.
ТЗ это все-таки требования к функциям. А как я реализую ПО, БД и логику, точнее с помощью каких средств - это моя задача.
К примеру, см вложение (Основные связи между объектами Автоматизированной Системы Контроля и Управления Проектной Деятельностью Гимназистов).
И сказать это предварительная структура.
Основной упор был на слово стараемся не добавлять.
А вот изменение в согласованное с заказчиком ТЗ
оформляют дополнением или подписанным заказчиком и разработчиком протоколом.
-
В ТЗ можем и рисунок из Visio вставить (тк данное ПО в основном и стоит у сотрудников).
То есть вы все таки рисуете в Visio и добавляете в ТЗ ?
-
В конечном итоге , для ТЗ в Visio.
Но сначала на Лист А4 -> Доска белая большая -> Visio. :)
Но это я и говорил ранее - Visio во всем
.
-
В ТЗ вообще рисунки лучше не вставлять.
Вы говорили об этом.
-
Да говорил, но стараюсь не вставлять.
Все зависит от требований заказчика.
Потому что в итоге получается только контурно, система контурно выглядит так и выполняет заданные требования.
А вот, к примеру что поле в БД FIO называется именно так это ???
И все-таки рисование проектирование это уже другой этап.
Еще один довод, рисовать это чьи-то трудозатраты ... и все такое , а в основном данных часов нет.
-
Да говорил, но стараюсь не вставлять.
Все зависит от требований заказчика.
Потому что в итоге получается только контурно, система контурно выглядит так и выполняет заданные требования.
А вот, к примеру что поле в БД FIO называется именно так это ???
И все-таки рисование проектирование это уже другой этап.
Еще один довод, рисовать это чьи-то трудозатраты ... и все такое , а в основном данных часов нет.
Что-то я вас не понимаю.
У нас в ТЗ довольно часто входят особенности реализации. Вплоть до макетов интерфейса. И просто так его менять нельзя, только по согласованию с заказчиком и т.д.
Что значит проектирование это другой этап? Другой от чего? От написания ТЗ ? ТЗ бывают разными, для разных людей и с разной степенью детализации.
Рисовать это чьи-то трудозатраты - безусловно. Любая работа - это трудозатраты, тестирование тоже трудозатраты - но это не значит что его не надо делать. Тут вопрос в правильной оценки времени и бюджета и вопрос распределения ресурсов.
-
Я лишь хотел сказать что когда вставляем схему то пишем в ТЗ, что предварительная.
Вплоть до макетов интерфейса
Именно макет, а не окончательная реализация.
Или схема БД может быть уточнена на этапе тех проектирования.
Это макет решения.
После выработки решения как ая будет схема, рисуем в основном в Visio.
-
Я лишь хотел сказать что когда вставляем схему то пишем в ТЗ, что предварительная.
Извините, я не могу понять смысл этого высказывания.
-
Что схема или диаграмма, это предварительное решение, макет. Будет вот такой процесс, но он может быть и уточнен.
Интерфейс формы будет похожим на макет -а поля к примеру будут другие.
-
Что схема или диаграмма, это предварительное решение, макет. Будет вот такой процесс, но он может быть и уточнен.
Интерфейс формы будет похожим на макет -а поля к примеру будут другие.
То есть мы все таки пришли к тому, что вы так же рисуете диаграммы и так же вставляете их в ТЗ.
-
Да вставляем, но очень редко.
Вопрос был "Лучше рисовать диаграммы на бумажке или в CASE?"
Ответ: Что лучше каждый решает сам как ему удобней.
Мы делаем так : сначала на бумаге (a4, a2, a1 :)) , обсуждение (доска и тому подобное), рисуем схему в визио.
-
Да вставляем, но очень редко.
Вопрос был "Лучше рисовать диаграммы на бумажке или в CASE?"
Ответ: Что лучше каждый решает сам как ему удобней.
Мы делаем так : сначала на бумаге (a4, a2, a1 :)) , обсуждение (доска и тому подобное), рисуем схему в визио.
Ну, мне кажется, что так делают большинство.
-
У нас в компании всегда рисуются все диаграммы в Enterprise Architect, после их согласовывают с заказчиком - вносят изменения, проверяют тестировщики - вносят изменения. Потом в процессе реализации от программистов или заказчика порой поступают предложения/замечания и опять таки вносим изменения.
В итоге за время жизни проекта первоначальные UC могут быть перерисованы в значительной степени.
И если это не хранить в векторной форме - то это будет вынос мозга и трата кучи времени.
-
Что лучше - бумага или CASE? Для меня все зависит от момента, в который рождается диаграмма. Если она рождается в интерактивном обсуждении, то бумага или доска. Так, кстати, могут рождаться и достаточно сложные схемы, которые потом фиксируются в CASE - иначе их сложно менять. А простые - обычно на уровне бумаги и идут в реализацию.
Если же схема вырабатывается к обсуждению в одиночку, то я сразу рисую в CASE-средстве. Потому что обычно провожу некоторое количество итераций и на бумаге - оно гораздо менее удобно. Дело в том, что диаграмма должна давать целостность восприятия, обычно какой-то сложной вещи, а тут многое зависит от расположения, это надо пробовать.
В качестве средства рисования для простых схем использую встроенные средства MediaWiki (мы ведем постановки в wiki). А для более сложных - сразу в MS Visio, шаблон UML (только не родной, а с http://softwarestencils.com/uml), если речь идет о формальной области, или набор из нескольких шаблонов, адекватных задаче.
По поводу добавления в ТЗ. Все понимают, что диаграммы и картинки могут изменяться. Но они являются очень эффективным средством получения общей картины, в том числе - согласования ее с заказчиком. Так что у нас - предъявляются ему сразу, обсуждаются и согласуются. Особенно vision на новые части или изменения. Другое дело, что при работе с некоторыми заказчиками надо различать формальное ТЗ и реальные обсуждения. Но обсуждения должны быть, и картинки - эффективный инструмент для этого.