406

Термины и Определения / Re: [Термин] Vision

« : 02 Сентября 2008, 10:07:32 »

Где то встречал перевод "Документ об образе и границах проекта"
Но мне больше нравится Концепция.

407

Примеры / Re: Проверьте диаграмму деятельности, пожалуйста

« : 27 Августа 2008, 14:12:28 »

Я пользуюсь в общем только одной книгой - http://www.ozon.ru/context/detail/id/2473023/
да и она порой расходится со спецификацией и к тому же является справочником. Ее трудно использовать, когда не знаешь, что ищешь.

Тоже рекомендую эту книгу, но ее лучше использовать когда немного знаешь UML и можешь в нем ориентироваться.
Можно еще почитать
http://www.ozon.ru/context/detail/id/2260613/
http://www.ozon.ru/context/detail/id/3118206/

408

Примеры / Re: Проверьте диаграмму деятельности, пожалуйста

« : 25 Августа 2008, 15:02:30 »

2) Нельзя, чтобы в одну деятельность ("Постановка в картотеку 1"), входило больше чем 1 стрелочка. В данном примере стрелочки должны сойтись в ромбике, а потом из ромбика одна стрелочка должна указывать на деятельность. Если этого не сделать, а оставить как есть, то измениться семантика.

474, ниже диаграммка подтверждающая слова Дениса.

409

Примеры / Re: Проверьте диаграмму деятельности, пожалуйста

« : 22 Августа 2008, 18:32:00 »

Если автор под жирными линиями подразумевал параллельные потоки, то он вообще ерунду нарисовал.
Самая левая верхняя жирная линия принимает в себя два потока управления. А откуда они взялись?
Ну и далее тоже не лучше....

Ага согласен с предыдущим оратором .
Вместо жирных линий (Fork и Join) нужно элемент Merge. Если я правильно помню Join это операция AND логическая, а Merge - это OR
Другими словами на жирной линии программа остановится, тк она будет ждать когда выполняться все входящие стрелики, а этого не будет потому, что выше у нас принятие решения (только одно из нескольких), в итоге все повиснет

Да, условия для ромбиков (decision node) пишутся в прикрепленном примечании.

Или в самом ромбике

410

Идеи и мозговой штурм / Re: Парадоксы общения

« : 19 Августа 2008, 15:47:06 »

Есть неплохая книга

http://www.amazon.com/System-Analysis-Design-Development-Engineering/dp/0471393339

Могу выслать. Весит 4.25 Mb

411

Идеи и мозговой штурм / Re: Парадоксы общения

« : 19 Августа 2008, 15:23:44 »

А какой?

Владение теорией системного анализа, имхо, позволяет развить в человеке умение смотреть на окружающий мир (любая предметная область) с системной точки зрения, выделяя ее элементы, их взаимосвязи и границы. Системное мышление помогает абстрагироваться от деталей и четко представлять как будет выглядеть будущая система. Мне кажется, что именно системное мышление и аналитический склад ума позволяют аналитики выполнять свои задачи в различных областях.
Развивать системное мышление можно почитав книжки по системному анализу и немного по практиковавшись. Книжек много, стоит только в поисковике набрать системный анализ или системный подход.
Вот список книг, которые довольно не плохие.
 1. Антонов А.В. Системный анализ
 2. Гараедаги Д. Системное мышление. Как управлять хаосом и сложными процессами.  Платформа для моделирования архитектуры бизнеса.
 3. Крон Г. Исследование сложных систем по частям (диакоптика)
 4. Блауберг И.В., Юдин Э.Г. Становление и сущность системного подхода

В книге E. Hull, K. Jackson, D. Dick, Requirements Engineering, есть интересный пример когда чашку представляют как систему, которая состоит из разных частей: ручка, чаша и др. причем каждая часть является интерфейсом, например ручка - интерфейс взаимодействия с рукой, подставка - интерфейс взаимодействия со столоим и т.д.
Примеров можно придумать много, например стул с его интерфейсами для спины, пола...   

412

Термины и Определения / Re: Перевод mechanism и framework

« : 18 Августа 2008, 12:47:49 »

Добавил голосование за перевод термина mechanism, Если выбираете значение Другой, пишите пожалуйста ваш вариант перевода в ответе темы.

413

Идеи и мозговой штурм / Парадоксы общения

« : 15 Августа 2008, 09:30:16 »

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

Эдуард, не расстраивайся  . Просто тебе немного не повезло и ты занимаешься не тем чем тебе хотелось бы.

А пока скорее интересен человек, разбирающийся в предметке - эксперт. Но эксперт не обязательно должен быть аналитиком. Хотя по определению аналитик это тот, кто понимает нужды заказчика и умеет их переложить на язык разработчика, ну и наоброт. Получется не аналитик, а переводчик

ИМХО, не обязательно совмешать в одном лице эксперта и аналитика. По своей практике могу сказать, что работал на нескольких проектах абсолютно разных предметных областей и никто никогда от меня не требовал быть знатоком предметной области. Если знаешь - да большой плюс, без спорно, но у вы не всегда можно найти хорошого аналитика и эксперта в одном лице.
Обячно у нас в команде всегда был эксперт, которого можно поспрашивать, что-то узнать. Этот человек описывал бизнес процессы "как есть". А аналитик, учитывая ограничения и потребности заказчика вырабатывал требования и строил бизнес процессы "как будет". Ко всему выше сказаному хочется добавить, что эксперты - это не айтишники и многие не знают различных методов анализа,  работы с требованиями и проектирования систем.

PS Предлагаю эту часть темы пернести в новую тему.

414

Термины и Определения / Перевод mechanism и framework

« : 13 Августа 2008, 11:09:25 »

Друзья, давайте сначала обсудим несколько вариантов перевода слов mechanism и framework.
У меня пока только предложения из лингво 

1. Mechanism - механизм, алгоритм, принцип действия, схема действия, закономерность
2. Framework - каркас, структура, основа, "скелет", принципиальная схема, структурная схема, концепция, исходная структура, базовая структура...

Давайте ваши предложения, а я оформлю их в виде головования.
PS Если говорить про Architecture Framework (DODAF, MODAF, Zachman, TOGAF)? то по смыслу больше наверное подходит концепция или принципиальная схема, исходная структура. Хотя каркас тоже неплохо. А вот слово фреймворк я бы здесь применять не стал 

415

Сообщество Аналитиков / Сообщество аналитиков - Санкт Петербург

« : 12 Августа 2008, 11:33:43 »

Друзья, пришло время Питерским аналитикам/архитекторам и другим заинтересованным лицам, создавать сообщество в славном городе Санкт-Петербурге.
Цели сообщества:
 1. Объединение людей с общими интересами и целями
 2. Обмен опытом
 3. Обсуждение интерсных тем по аналитике, проектированию и др...

Цели будут дополняться и развиваться со временем и в общем они такие же как у наших Московских коллег  .
Форумчане из Петербурга, откликайтесь!

416

Термины и Определения / Re: Образец или паттерн?

« : 12 Августа 2008, 10:44:36 »

Мне кажется pattern нельзя переводить вот так просто без контекста.
Pattern (на моей памяти) всегда идет с прилагательным.

Денис, как вы сказали паттернов бывает много различных: Design, Use Case, Analysis, GUI ...
Если для каждого словосочетания давать свой перевод, например один говорит Образец проектирования, другой шаблон ВИ и т.д то будет наоборот путаница. Поэтому лучше если слово pattern в данном контексте (я имею ввиду IT) будет переводится одинаково. Поэтому и предложил именно перевод слова pattern, как независимой единицы к контексте разработки информационных систем.

417

Термины и Определения / Re: Образец или паттерн?

« : 12 Августа 2008, 09:23:52 »

Добавил голосование на перевод слова pattern. В общем голосуем.
Эдуард, на счет неологизма, вот что написано в Lingvo

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

ПАТТЕРН
(англ. pattern – образец) повторяющаяся комбинация действий, событий или элементов системы.
Понятие "паттерн" широко используется в прикладных науках (например, в программировании) и в психологии. В последней паттернами обычно обозначают устойчивые модели поведения индивида или сообщества, а также систематически повторяющиеся распределения ролей.

Я бы использовал термины паттерн, механизм, каркас - так проще. А можно ли (в метод. руководстве, например)?

Телемед, может быть в метод. руководстве привести список терминов и использовать необходимые слова ссылаясь на глоссарий?

Framework наверное лучше переводить как каркас, вроде бы понятно, еще мне нравятся перводы: основа и "скелет", которые точно передают суть термина.

418

Термины и Определения / Re: Образец или паттерн?

« : 11 Августа 2008, 17:54:40 »

На практике сталкивался с тем, что когда говоршь коллеге слово образец или типовое решение - тебя никто не понимает. Когда говоришь паттерн - понимают все и сразу.
Эд, не совсем согласен что паттерн это шаблон. Но это мое мнение. Шаблон - это нечно пустое, что заполняется смыслом. А паттерн - это именно пример решения конктретной задачи или проблемы.
У меня есть два предложения pattern - паттерн, типовое решение.
+ дать четкое определение не design pattern, а pattern в общем.
У американцев для примеров решения конкретных задач также используется слово Blueprint.

419

Системный Анализ и Требования / Re: Требования и интерфейсы

« : 08 Августа 2008, 16:38:55 »

Именно так, Виталий. Правда мы сначала описываем требования в виде иерархии, основанные на ВИ, а потом создаем интерфейсы в соответствии с пунктами требований. Мне хотелось бы знать как правильно все это дело оформлять.

Анастасия, если я правильно понял, схема у Вас следующая:
1. Создается набор вариантов использования и описываются их сценарии
2. Из сценариев получается набор функциональных требований
3. Создаются GUI на основе функциональных требований.

Трассировка у вас в таком случае UC-->RQ-->GUI ?
1. В документе, как уже говорил Выше Александр и немного я , создаете раздел в котором описываете набор вариантов использования и их сценарии. Лучше каждому ВИ присвоить уникальный номер, например UC1, UC2...
2. В следующем разделе приводите список функциональных требований, которые вы получили из сценариев ВИ. Каждому требованию тоже лучше присовить идентификатор, например REQ1, REQ2...
Далее делаете матрице трассировки требований на ВИ, или если описываете требования в таблице, то прямо в таблице для каждого требования пишете ВИ к которому оно относится
3. В следующем разделе рисуете GUI и точно также трассирует на требования.

Анастасия, а какого уровня абстракции у вас варианты использования: Business, Summary или System?
Если системные ВИ то может не стоит тогда функциональные требования писать, а достаточно лишь сценариев?

420

Системный Анализ и Требования / Re: Требования и интерфейсы

« : 08 Августа 2008, 12:28:40 »

Виталий, о чем я и говорил в своих постах.

Ага :-) . Я только немного добавил про классы анализа.