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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
1141

Нам же следует просто указать:
1. тип файла (например word 2003)

Откуда у студента деньги на Office 2003? :)

Если есть такие такие подробные требования к оформлению работы, то проще подготовить шаблон.
Или упростить требования.

1142
Цитировать
Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.
А например?

Читаю очередные обновления спецификаций EMV, увидел блок-схему и вспомнил это "например".
http://emvco.com/documents/bulletin/view/AN35_Draft%20DCC%20Clarification%20v1.0.pdf

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

1143
Я проголосовал за 15-е, но 29-е меня тоже вполне устроит. А пятница - однозначно нет.

1144
Просто надо всех заставить говорить только на ЮМЛ, тогда и будут все картинки в ЮМЛ, а не художественные изыски (это к теме про безмолвное моделирование)

А зачем? По этой картинке ни у одного из клиентов не возникало вопросов.

1145
А  в чем нет необходимости

в ведении требований по прецедентам? (тут я понял Вы прецеденты используете мало или вообще не используете. Это может быть вполне обусловлено решаемыми задачами. По крайней мере Лифеннгуэлл пишет об этом достаточно подробно).

Вот только не надо меня своей бандой пугать. :)

В том, что касается приложений для POS терминалов, прецеденты (не люблю я это слово) идеально подходят для описания пользовательского интерфейса. Но мы вместо них до сих пор использовали либо наборы рисунков с изображением экранных форм, либо блок-схемы алгоритмов - ни у одного заказчика вопросов по форме представления не возникало.

Тут имелось в виду сам способ разработки. сначал требования кровь из носу, потом проект и реализация. Либо все в перемежку по спирале?

Наша ситуация примерно описана вот здесь:
http://www.uml2.ru/forum/index.php?topic=219.msg4016#msg4016

С августа не очень много изменилось, но какие-то подвижки, конечно, есть.

Ну нормальной гибкий подход :) А если решение удачное, репозиторий не ведёте?

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


А например?

Порылся в документах, не нашёл.

Зато нашёл вот такую диаграмму в концептуальном документе. Просто для иллюстрации. Интересно, если использовать только UML, какая диаграмма здесь должна быть и как она выглядела бы?


1146
Ну, а если всерьез. Хотелось привлечь внимание к теме. Люди уже 6 лет этим занимаются и утверждают - эффект есть! Почему бы и не проанализировать, не попробывать в конце концов

Там какой-то подвох. Либо архитекторы так глубоко знают UML, что он им окончательно заменил естественный язык ;) , либо круг задач ограничен так, что все базовые решения по архитектуре уже приняты (или тривиальны).

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

1147
Вот что написано:
" Безмолвное Моделирование - мощный метод моделирования, который помогает увеличивать производительность проектировщиков и улучшать качество дизайна.

Сущность Безмолвного Моделирования - ограничение на использование в ходе взаимодействия непосредственного или косвенного применения естественного языка. Через этот метод, группа проектировщиков вынуждена использовать язык моделирования как единственный язык, доступный для связи в течение сеанса дизайна. Любая устная или письменная связь, вовлекающая естественные языки запрещается.

УжОс. Первый вопрос, который приходит в голову - а каковы критерии "качества дизайна"?

Язык моделирования, как мне представляется, это РАСШИРЕНИЕ естественного языка, а не альтернатива ему. Не преставляю реальных задач, которые могут быть решены таким методом.

1148
Хотел бы задать вопрос общественности форума, особенно той ее части, которая реально работает с требованиями на практике и имеет насущную потребность в управлении ими.

Я реально работаю с требованиями, и в нашей полсотне проектов есть роль "Аналитик", которую делят примерно поровну два человека. При этом значение слов "Требования" и "Аналитик" понимаю, пожалуй, только я, причём не факт, что правильно. :)

На самом деле, "управление требованиями" у нас в зачаточном состоянии, хотя раздел "Требования" в нашем внутреннем трекере задач существует уже года два. Ситуация такая: специального образования аналитика ни у кого нет, я пытаюсь быть локомотивом внедрения более-менее внятных подходов к разработке. Собственно, это в моих интересах и входит в мои обязанности. :)


Каким образом Вы управляете требованиями?

Обычно требования содержатся в разрозненных документах или в электронной почте. При начале нового проекта или очередной итерации на изменение приложений мы сводим требования в список и отправляем его заказчику на утверждение. Заказчиков у нас много, и способ взаимодействия с каждым из них свой. В общем, "идеальный" подход к сбору требований - встречи с участием как можно большего количества заинтересованных лиц - мы только-только начали применять, и не со всеми заказчиками находим взаимопонимание.

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

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

Что Вы понимаете под управлением требованиями?

Учёт и отслеживание выполняемости. Это если в двух словах.

Какие системы управления требованиями Вы пользуетесь и как?

Собственная разработка - учёт требований объединён с учётом проектов, запросов (багов), тестов и текущих задач. Полной интеграции с разработкой и тестированием пока нет. Каждый раз, когда нужно использовать требования (разработать план тестирования, план работ, собрать документ для обсуждения с заказчиками и т. п.), это нужно делать "вручную". То есть открывать трекер, выбирать проект и читать все требования подряд.

Самые очевидные недостатки, которые будем исправлять в ближайшее время:
- отсутствует автоматическая трассировка требований на тесты и релизы - требования хранятся "сами по себе", без связи с другими объектами учёта;
- при изменении требований не сохраняются старые версии.


Как обеспечивается управление требованиями в стиле прецедентов и стиле списков свойств системы?

Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.

Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?

Даже слов таких не знаю. :) То есть слова знаю, но применительно к разработке программ, а не формулировке требований.

Какое место занимает в Вашем случае моделирование?

Последнее. Максимум, что иногда используем - подобие диаграммы развёртывания при объяснениях с заказчиком. Иногда, в сложных для понимания вопросах, используем диаграммы состояний "на салфетках", которые после обсуждения выбрасываются.

Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.

Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?

Нет.

Какие требования к системе управления требованиями Вы лично предъявляете?

В двух словах не выразить, а на подробное изложение сейчас нет времени.

1149
Однако хотя в курсе проектирования ИС и читается UML, но явно не в том ракурсе. Практически читается не использование UML в проектировании, а просто нотацию и ее особенности.

А нужно ли специально читать "UML" или "UML в проектировании"? Как мне кажется, достаточно дать базовые знания за пол-пары в каком-нибудь вводном курсе, а потом просто неуклонно использовать его при изображении любой схемы или диаграммы.

Там, на самом деле, отдельно изучать-то нужно только "правильное" направление стрелок. ;)

1150
Данная работа действительно "заказана" моим начальником. Что интересует его - дословно "прозрачность всех процессов предприятия" и уяснение, чем же действительно заняты многие службы, потому что иногда появляется мнение, что просто нифига не делают чесно говоря . Им был выделен процесс к моделированию "Бухгалтерский учет". Хотя как я понял - интересует его именно вопрос по улучшению взаимодействия служб и отделов с  отделом бухгалтериЯ. это начальный этап. В будущем планируется наложить на существующую бизнесс-модель предпрятия КИС. но это в далеком будущем :)

Как всё-таки видится задача вашему начальнику - смоделировать реально существующий процесс, или смоделировать "идеальный" процесс и потом "внедрить" его?

Он вообще "по цехам" периодически ходит? Никакой инструмент не заменит реального общения, а может только создать иллюзию "прозрачности".

1151
О Сайте и Форуме / Re: Баннеры на форуме
« : 29 Октября 2007, 18:58:53 »
А как на главной не режет, а на форуме режет??

Да я Касперским на работе не пользуюсь - просто так, к слову пришлось. :)

Выдам я свой секрет, не буду больше голову морочить. А то ещё забанят. :)

Судя по всему, баннеры добавлены только в таблицу стилей для темы по умолчанию (SMF Default Theme - Core). Её используют все, кроме двух человек. Один из этих двоих - я.

1152
О Сайте и Форуме / Re: Баннеры на форуме
« : 29 Октября 2007, 17:15:36 »
А на главной странице САЙТА, Вы их видите??

На главную я обычно не хожу. Сейчас зашёл - вижу.
Более того, я догадываюсь, почему я их в форуме не вижу. И честно признаюсь: меня это совсем не расстраивает. :)

Кстати, Касперский режет гуглевскую рекламу.

1153
О Сайте и Форуме / Re: Баннеры на форуме
« : 29 Октября 2007, 16:44:19 »
А что значит "ОСТАВИТЬ наверху и внизу"? Они там есть разве сейчас?

Есть один секрет. Я, например, их тоже не вижу.
И вот думаю - выдавать секрет или сидеть тихо и по-прежнему не видеть никаких баннеров. :)

1154
А что значит - "создать структуру архива"? В чём состоит работа добровольцев - движок там написать, аннотацию сочинить или тупо переложить файлики из одного места в другое?

1155
Забавная, но как я понимаю жизненная ситуация. Странная, хотя бы по тому, что решение же делается для Заказчика, а он ишь вроде как неособо и заинтересован.

Ну, как говорится, "зри в корень".

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

Так что если вернуться к теме топика (про целеполагание), цель нужно искать совсем не там, где она по логике должна быть. :)

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »