5356

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

« : 11 Мая 2007, 20:02:01 »

Я думаю - можно в отдельной ветке.
"Техническая организация управления требованиями"
Создадим?

why not?

5357

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

« : 11 Мая 2007, 17:47:54 »

Я - плохой аналитик. Я не умею ставить wiki. CaliberRM, RequsitePro - поставлю .

Хм, значит я хороший аналитик? Я умею ставить wiki, да чего его не поставить? Ставим Apache 2.x, PHP 5.x.x, mysql 4.x, качаем дистриб mediawiki и ставим его по инструкции. Или можно обойтись например dokuwiki там запросы скромнее и даже mysql ненужно.

А вот CaliberRM ставить не умею, ну не ставится он у меня, зараза! А вот DOORS поставился с полпинка.

Другой вопрос - как настроить все это хозяйство? Какая должна быть структура? И т.п.

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

5358

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 10 Мая 2007, 20:26:34 »

а может просто диаграмма ВИ сама по себе слабый инструмент?

давай рассуждать логически и исторически.

Сами варианты использования придуманы и введены ц употребление Якобсоном. Сначала они назывались usage case, потом превратились в брендовое название use case. Как я понимаю, исходно, это были действительно текстовые сценарии. Возможно содержащие простое описание и позволяющие структурное связывание. После объединения усилий по разработке единого стандарта объектной парадигмы, варианты использования были включены в нотацию UML. Овалы предназначены, на мой взгляд, для задания контекста и скрытия деталей на определенном уровне абстракции - классическая инкапсуляция. Детали варианта использования в зависимости от уровня представления раскрываются в текстовом описании или использовании других диаграмм: диграмм деятельности, последовательности и даже состояний.

Рамбо говорит, используйет текстовое описание там где это действительно проще и понятнее, а диаграмму деятельности лучше использовать, если ВИ имеет сложную структуру. Для отображения временной зависимости и отображения деталей используется диаграмма последовательности, которая в при проектировании классов еще добавляет и операции классов.

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

На уровне бизнеса или на уровне системы все это отображджает внешний взгляд на систему как черного ящика - ее устройство скрыто, внимание сосредоточено на том, что должна делать система для удоволетворения потребностей ДЛ и какие внешние связи-интерфейсы должны быть установлены.

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

Использование графических средств на ранних этапах позволяет моделировать разные слои решения в едином подходе, сокращая этап разработки и обеспечивае повторное использование ранее созданных элементов.

Конечно, можно разработать структуру, некую инструкцию, систему тестовых вопросов, но будет ли польза, поскольку веротяно ВИ одна и с самых неформальных частей проекта, на мой взгляд.

Я вот сейчас изучаю Telelogic System Architect. Он пока поддерживает версию 1.3 или 1.4 UML, но например там реализован такой инструментарий: делаешь диаграмму ВИ, входишь в редактирование самого ВИ, а там целый шаблон в виде формы ввода: шаги, предусловия, постусловия и т.п. Хорошо это или нет, удобнее такой подход или нет (по сравнению например с написанием в виде докмента док и подключения как гиперссылки) Возможно тут есть преимущество сопровождения, формирования отчета, использования трассировочного инструмента DOORS. Вероятно, из такой структуру при желании можно сгенерировать диаграмму дейятельности (правда я еще не пробывал только начал изучение)

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

5359

Сообщество Аналитиков / Re: Встреча Сообщества Аналитиков №3

« : 10 Мая 2007, 13:14:57 »

можно записаться или вход только для членов профсоюза аналитиков на моём круге?

Конечно, можно. Также можно стать членом сообщества, смотрите соответствующую тему

5360

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 10 Мая 2007, 13:13:01 »

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

5361

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 09 Мая 2007, 23:08:08 »

Семестр подходит к концу. Окончательные выводы делать пока рано, так как надеюсь, что работы студентов примут законченный вид. Но уже сейчас ясно, цель не достигнута, или не достигнута полностью. По крайней мере, студенты получили навык написания вариантов использования, навыки графического моделирования UML, навык публичного выступления и отстаивания своей позиции.
Результат, конечно, нельзя считать отрицательным. Но и положительным тоже. Возможная причина - малый объем курса. Попробую в следующем году постановочную часть перенести в первый семестр, а технологическую и моделирующую часть во второй. Кроме того, хочу вообще отказаться от лекций в традиционном их виде, а заменить скажем практическими занятиями.

Впереди экзамены. Есть мысль сфоримровать билеты таким образом:
Некая постановка задачи (задача должна быть достаточно простой). Исходя из формулировки задачи требуется ответить на скажем 5 вопросов:
1. выделить акторов и use cases, построить диаграмму UC
2. для одного варианта использования написать сценарий и построить диаграмму деятельности
3. построить диаграмму VOPC для варианта использования, или общую концептуальную модель классов предметной области, если есть желание
4. Построить диаграммы взаимодействия: последовательности
5. Построить диаграмму состояний для некоторого объекта

Экзамен письменный - 2.5 -  3 часа. Разрешено пользоваться печатной литературой

Оценка двойная: синтаксис и семантика

Есть проблема - это сами задачи - нужно примерно 30, десяток уже есть.

Может кто-то поможет?
Условия - задача должна быть ясной и понятной, количесвто действующих лиц 1-3 максимум, общее количество вариантов использования не более 5. Объекты предметной области достаточно простые и понятные, желательно, чтобы хотя бы один требовал изменения состояний

В качестве примера: Электронная версия сдачи экзамена по предмету( предложить решение). Описание сдачи экзамена традиционная: студент приходит на экзамен, имея допуск к сдачи экзамена по данному предмету. Студент выбирает билет и садится готовится. Преподаватель фиксирует ФИО студента, проверяет возможность сдачи им экзамена и фиксирует номер взятого билета. Студент готовится положенный срок и сдает ответы на вопросы экзаменнационного билета в письменном(устной) виде. Преподаватель, проверив ответы, выставляет оценку в зачетную книжку и ведомость. Закончив прием экзамена, преподаватель сдает ведомость в деканат. В ведомости указывается дата экзамена, название предмета, номер группы, факультет, семестр, учебный год. Для каждого студента выставляется рейтинг (минимум 26 максимум 50) за семестр (преподавателем который ведет практические занятия), результат за экзамен (минимум 26 максимум 50), итоговая оценка (рейтинг+экзамен) в виде баллов и оценки(неудоволетворительно(<52), удовлетворительно(<70), хорошо(<85), отлично(>=85)) либо не явился, если студент не явился или недопущен к экзамену. Экзаменнационный билет может содержать теретический вопрос, задачи или задания, или выглядет как тест.

5362

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 09 Мая 2007, 21:56:41 »

Если кому-то интересно - пишите в личку адреса электронной почты, я буквально в тот же день вышлю вам .xol-файл (это описание объектной модели для Sybase PowerDesigner). Предупреждаю сразу, что файл заточен под 11-ую версию, так что как младшие или старшие будут с ним работать, ничего сказать не могу.

Денис, нет у меня Дизайнера. Отказался от него, вернее есть 9.5, но давно не используется. Да и если честно, после других систем возвращаться пока к дизайнеру неохота. Потому нет ли у дизайнера возможности сохранять модели в формате, который могут понять Rational Rose 2003, Enterprise Architect, Telelogic Tau, Together, Visual Paradigm, Visio наконец. :-))

Заодно, если кому-то нужно, есть PD 12.1 с лицензией.

Стоит ли разрабасываться лицензией, еще осудять как Поносова

Вообще, объясните мне, пожалуйста, как такой гигант, как 1С, до сих пор так нелогично относится к процессу разработки конфигурации? Хотя, не в обиду будет сказано 1С-разработчикам, способы разработки продуктов на этой платформе очень ощутимо отличаются от общепринятых...

А зачем. Изначально это была коробочная версия с постпродажным или пост внедренческим обслуживанием. Причем вторая статья превалирует в доходной части и существенно. Например купили лицензию на рабочее место скажем за 10 тыс + всякое там ослуживание где-то 2-3 тыс в мес. уже через год это становится = 24-36 тыс. А если нужна адаптация стандартной конфигурации - а она практически нужна всегда - поскольку аже такие огранизации как вузы - вроде чисто бюджетную имеют бухгалтерию и по идее должны иметь единый набор процессов и их сценариев, все равно требуют переделки. Переделка в целом типичная и довольно понятная - тянет обычно тыс на 30-40 р. как минимум. Так что как понимаешь бабки крутятся - народ одинэсит во всю...

У меня был такой опыт - пивоваренная компания вышла на меня каким-то неизвестным мне образом - якобы я самый главный специалист в городе по корпоративным информационным системам - поговорили с людьми: товарищам хотелось через месяц получить конфигурацию управления складом, но с очень большими дополнениями и двойной бухгалтерией конечно. Я конечно ни какой не спец был, да и есть, просто читал курс по ERP :-). 1С только начинал осваивать. Однако поговорив с людьми, естественно загрузил их по полной программе. Сказал что за месяц, если и можно сделать но наверное еесли будут работать сразу 100 человек, да и то не возможно - будут друг другу мешать. В итоге я помог им связаться к компанией IT-soft, узнал примерно через полгода, что они даже пока еще не утвердили полностью ТЗ. Еще через год - был сделан проект, который даже был примерирован, а конфигурацию было решено внедрить на других пивоваренных площадках страны...
Однако в личных раговорах с разработчиками я понял, что никакие IDEF, UML, и другие нотации не используются, и даже не стремятся использоваться. Аргумент был таков, а как это нам использовать? Базу мы не разрабатываем, классов как таковых у нас нет - всю библиотеку мы имеем от движка, а что своего разрабатываем, то мол это свои dll, выгрузки, и т.п.
Я им пытался сказать, что мол ну и что - не путайте божий дар с морковкой. Одно другому не мешает. Они как-то предложили мне рассказать им об скажем использовании UML, но я к сожалению не был тогда столь подкован-раз, да и просто кому-то доказывать что-то, особенно когда люди явно настроены против.

Еще мысль - 1С-ники подготовили хорошую систему обучения и сертификации, стиль разработки конфигураций больше напоминает процедурный подход с хорошо развитыми библиотеками и приемами работы

5363

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 08 Мая 2007, 23:23:45 »

Не тем занимаемся :-)
1. Мечты но попробовать можно , за идею начать перевод с глоссария я двумя руками за :-)
2. Тупит но ехать можно.
3. Под нападением я понимал не профессора , а предложение сделать все по взрослому ,
А в проффесоре виноват один человек у которого был такой ник и его приходилось часто писать :-) Так что теперь пальцы иногда вворачивают выражение :-).

У меня почему-то этот ресурс совсем не работает через ИЕ еще кое-как захожу, через другие браузере уже не могу. Кривой ресурс и сильно кривой. Вот кстати это часто так бывает у больших умниц и умников от ИТ

5364

Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?

« : 08 Мая 2007, 12:45:15 »

p.s.  Делал тренинг так еле в 8 ч вещания с небольшой практикой  уложился :-)

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

5365

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 08 Мая 2007, 12:37:12 »

Во первых сам начал нападать ;-)
А во вторых я так и не поянл почему нельзя переводить Глоссарий в WiKi ? Зачем городить весь этот сыр бор с Excel?

1 - получить четкое и однозначное понимание треминов
2 - попробуй
3 - я на тебя 1 не нападал, а просто поправил неграмотное написание слова профессор

5366

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 07 Мая 2007, 16:34:28 »

Ну напали как коршуны на бедную овечку.

Вот всегда так, инициатива наказуема.
Я первод сделал - сделал, корректировал немного, привел в хорошее редактируемое состояние. Чего вам еще. Давайте работать, а не критику наводить.
Конечно все надо вылизать. Да текста не много, вот я его и скомпилировал. Теперь до ума доводить надо...
У меня и своих дел по горло... Берем делим глоссарий на участников и переводим, потом согласуем

Волки блин

5367

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 07 Мая 2007, 10:21:47 »

Здесь глоссарий, возможно не весь, либо не полный. Использовал свою локальную версию. Нуждается в доработке.
Предлагаю действовать так:
выдираем спорный или редактируемый термин(английский и русский варианты) и предоставляем вариант перевода для обсуждения.
Утвержденый перевод помещаем в репозиторий - т.е. в Excel-файл.

5368

Варианты Использования (Use Case) / Re: FAQ – Use Case

« : 07 Мая 2007, 00:17:09 »

Перевожу сейчас ресурс OpenUP. Обнаружил нечто для себя, что не до конца осознаю, вернее не до конца понимаю мысль авторов.
По замыслу авторов можно сказать, что требования к системе складываются из
1. поведенческих требований - например use case, так и написано было.
2. функциональных требований, не нашедших отражение в выше сказаном
3. ну и все остальные URPS+

Я хочу подчеркнуть, что говорю о требования к системе, а не вообще о всех типах и видах требований.
Дело еще в том, что требования под цифрами 2 и 3 авторы ресурса относят к дополнительным, поддерживающим (supporting) требованиям. Тогда use case являются главными. Однако являются ли они главными всегда? А если не являются? Что, тогда OPENUP просто не применим?

5369

Управление Проектом / Re: Принципиальные отличия in-house разработки от заказной

« : 07 Мая 2007, 00:08:59 »

Спасибо :-)

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

Извините за оффтопик, но уж больно гладко сообщение клеится

5370

Варианты Использования (Use Case) / Re: FAQ – Use Case

« : 05 Мая 2007, 23:41:13 »

Чем отличается диаграммы Бизнес ВИ и Системных ВИ?
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и  внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.
На Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние Пользователи с вашей автоматизированной Системой, т.е. отображаются пользовательские функциональные требования к ПО. Данная диаграмма используется на этапе Системного Анализа и формализации требований к ПО.

дополнения или мое видение
Диаграмма бизнес-вариантов использования представляет часть модели бизнес-анализа согласно Rational Unified Process. ДБВИ рассматривает моделируемый бизнес с внешней точки зрения, т.е. с точки зрения клиентов и партнеров бизнеса. Другая часть модели бизнес-анализа - модель бизнес-объектов - представляет внутренний взгляд на моделируемый бизнес или реализацию бизнеса. Модель бизнес-анализа определяет контекст, в котором строится будущее решение и служит для понимания проблемы или того, что необходимо изменить в бизнесе для решения проблемы.
Диаграмма системных вариантов использования отображает пользовательские требования, т.е. требования к разрабатываемой системе с точки зрения пользователей этой системы. Она является частью так называемой модели взаимодействия. ДСВИ задает контекст системы, который уточняется(детализируется) через диаграммы деятельности и диаграммы последовательности, если текстового описания системного варианта использования оказывается недостаточно для точной передачи смысла.
Важным является переход от диаграммы бизнес вариантов использования к диаграмме системных вариантов использования. Существуют разные рекомендации:
бизнес вариант использования может превращаться в подсистему разрабатываемой системы, либо становится вариантом использования системы
бизнес актор - может становится пользователем, превращаться в сущность(объект, класс) системы либо вообще исчезает из рассмотрения, оставаясь ограничением или неким требованием к системе
бизнез исполнитель (который проявляется только на диаграммах деятельности или диаграмме последовательности) - может становится системным вариантом использования или пользователем системы, либо становится управляющим классом системы