4756

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

« : 12 Ноября 2007, 17:50:50 »

Очень рад, что начал эту тему. Дело в том, что в ходе своей дейятельности мне не удается организовать управление требованиями. А хотелось бы поставить такую задачу в рамках практикума.

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

Выбрать неочень сложную, но обязательно коллективную задачу. Обыграть роли, распределить обязанности и посмотреть, что из этого получиться. Здесь я буду работать примерно неделю по 5-6 академических часов в день. так что следует успеть.

Что это будет за задача пока не понятно. Ясно, что некие предварительные материалы по ней будут. Хотелось бы расмотреть пусть не все - но некоторые этапы фиксации, управления и работы с требованиями.

Главное мне не очень понятно с чего все-таки начать.Предположим я буду использовать RaQuest или нечто другое (будет зависить от возможности приобретения лицензии на вуз, личная у меня есть).

В самом общем понимании что нужно будет делать:?
1. осуществить сбор требований
2. осуществить извлечение требований
3. осуществить ранжирование требований
4. осуществить моделирование части требований
5. осуществить фиксацию базовой линии

Предположим бизнес-цели или цели создания у нас будут поставлены.
мы будим формировать Видение. Сразу вопрос имеет ли смысл фиксировать бизнес-требования в системе управления требованиями? Если да то как грамотно это делать, Если нет то почему?

Далее функциональные требования будем в первую очередь описывать через прецеденты. Вопрос - ВИ и есть функциональные требования? имеет ли смысл разбивать ВИ на списки требований и фиксировать их в RaQuest? Или в RaQuest описать фичи? выделенные при создании Видения, а сами прецеденты описывать в рамках ЕА (Enterprise Arcitect) с трассировкой их к фичам описанным в RaQuest

4757

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

« : 12 Ноября 2007, 17:36:48 »

Хочу обратить внимание на "рулёзные" особенности ВИ:
- хорошее, а местами - единственное в своём роде, описание  КОНТЕКСТА процесса: пред-, пост-условие, ДЛ-ы, Заинтересованные Лица с их интересами и т.д.
(единственное в своём роде - в том смысле, что других мест для описания всего этого в стандартах на структуру соответствующих документов иногда вообще нет)
- СОЗНАТЕЛЬНО снижены требования к строгости и детальности описания САМОГО процесса

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

В противовес(а точнее - в дополнение) к ВИ, ДД рулит:
- обеспечивает строгость и наглядность представления именно ПРОЦЕССА,

особенно когда ВИ сложный

- даёт возможность учитывать в явном и стандартизированном виде поток входных\выходных объектов, да ещё и отслеживать их состояния на входе и на выходе каждой активности,

Но эта особенность появилась только в UML2 я имею в виду объекты, просто мы пользовались Розой, а она потоки объектов не разрешала размещать. Правда до UML2 ДД была подмножеством диаграмм состояний. А вот в UML2, ДД имеют совершенно иную интерпретацию, и построены на теории сетей Петри со всеми вытекающими отсюда особенностями логики переходов, правил срабатывания переходов, чтения диаграмм, проверки безопасности, живости сети. хотя мне кажется ценнее было бы E-сети, поскольку они безопасны по определению

- СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.

Т.е. Вы полагаете - это зер гут? А почему если не секрет

4758

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

« : 12 Ноября 2007, 17:27:59 »

тогда точнее будет так:
- сначала ДД или БВИ на бизнес-уровне, а затем
- снова ДД или СВИ на уровне пользовательских требований?
всего по комбинаторному принципу получается 4 возможных варианта :-)

Да вариантов не много :-) Дело и в вариантах,а в удобстве. Главное все равно в понимании  того, что нужно сделать. И совершенно не важно как и что. Главное чтобы все разговаривали на одном языке, так ведь?

4759

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

« : 12 Ноября 2007, 15:08:19 »

ЫМХО: Активити-диаграммы в UML - есть результат эволюции блок-схем.
Так что в этом смысле для дилемма ВИ\блок-схема вообще не стоит:
- одно другому не противоречит, а второе является результатом развития первого,
- первое - ближе Заказчику, второе - Разработчику,
- в зависимости от специфики проекта, одного из них может не быть.

Согласен. Но применять диаграммы видо деятельности или нет должно истекать из того, оправдано это или нет.

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

Опять же ДД может и предшедствовать ВИ. Есть такой интересный пример у Шмуллера "Освой UML за 24 часа".
Аналитик берет интервью у администратора и по ходу дела рисует ДД. Затем по ДД рассказывает ему, что он понял и администратор вдруг видит какие-то слабые или некорректные места.

Анализ же ДД позволяет выделить задачи участников и скомбинировать из этой большой ДД массу ВИ и соотвественно небольших ДД.

Т.е. сначала ДД используется на уровне бизнеса, как некая сложная комбинация блок-схемы, IDEF3 и возможно DFD.

Затем реализуются уже ВИ к системе и соотвественно ДД системы.

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

Например в VP-UML даже есть инструментарий перевода ВИ в системную диаграмме последовательности. Правда ВИ нужно набиратьпрямо в спецификации ВИ (там используется табличный шаблон ВИ). При этом поддерживается round-trip сопровождение. Но это естественно касается анализа требований. А не самого формирование требований

4760

Конференции Семинары и Тренинги / Re: [Семинар] - Альтернативные системы поддержки процесса разработки ПО (МСК)

« : 11 Ноября 2007, 21:35:45 »

Эд ... по целям и задачам. Цель имеет не столько ограничения, сколько численные критерии

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

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

outmost use case. "выбрать тул ", килобаксов, фреймворки, инстанс процесса, траблы .

Юр, я начинаю писать словарь с Юриного языка на русский :-)

Посему ЛЕГЧЕ строить доклад в форме "МЫ РАБОТАЕМ ВОТ ТАК (описываем детали процесса и требования к артефактам) и используем вот такой набор инструментов для <того-то>. Таким-то образом автоматизирован наш процесс. При этом вот эти части процесса на ура автоматизируются, а это приходится делать наполовину вручную. Отсюда выводы ...

На 100% с тобой согласен, интересен именно опыт. Думаю именно опыт сейчас важнее всего. Как делается у других, что они сумели сделать, а что не сумели. Проблемы ли это инструментов? используемых процессов? ошибок команды?
А вот обобщение этого опыта могло бы послужить отличной научной работой.

Если формат доклада будет таким как я говорил, не забудьте упомянуть меня "в благодарностях за оказанную поддержку" на слайдах доклада :-)))))).

А ты, меркантилен

А вообще, по-моему, неплохо бы тебе самому бы выступить. Ну выступи, Юра, пожалуйста 

4761

Примеры / Re: Примеры сказок, оформленных в виде UML диаграмм

« : 11 Ноября 2007, 12:19:53 »

Разместил сказку про курочку Рябу на www.umljokes.com

Сказка помечена как Hen The Specky. Всего 4 слайда. Прошу оценить, посмотреть и проголосовать, если понравилось.

Всем спасибо

4762

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 10 Ноября 2007, 12:50:17 »

Получить новую/интересную информацию
Апробировать возможность проведения таких мероприятий м/у студентами

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

А потом получить новую и интересную информацию. Ты вот сам можешь предложить новую информацию?

4763

Конференции Семинары и Тренинги / Re: [Семинар] - Альтернативные системы поддержки процесса разработки ПО (МСК)

« : 10 Ноября 2007, 12:44:06 »

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

Ты просто начитался дискуссии. Когда семинар был объявлен, я интересовался, а что это такое альтернативные - альтернативные чему? Платным, популярным, признаным, по технологии, по методологии, по реализации. ну и т.д.
Или тут просто имеется в виду обзор существующего рынка и подходов?

"Выбрать/предложить тул" -- это как-то на цель мало похоже :-). Больше на задачу :-).

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

Но я бы не стал таким образом ее ставить ... ибо в такой постановке тебе придется давать обоснованные критерии выбора.

А вот это всегда самое интересное. Как мне кажется нужно сначала выдвинуть требования (а тут этих требований может быть не мало - процесс до все-таки большой), а уже потом критерии. Хотя наиболее важные моменты многим практикам уже известны я думаю.
Но вряд ли это будет по силам данному семинару. Вообще - семинары должны оглашаться существенно заранее. Четко озвучена программа и сроки. Тогда можно, по-тихоньку, готовится. Кроме того - это конечно не единственный семинар по теме, его можно продолжать.

рассмотреть "пригодность" тулов под некий "условный" процесс -- тогда можно давать оценку и делать сравнение. Но этот условный процесс нужно описать.

Ну можно оттолкнуться от OpenUp или RUP. Ведь по большему счету - все процессы в целом схожы, различны технологии, акценты, методы и методики.
Либо так инструменты и рассматривать в рамках подходов, а может быть в их способности адаптироваться к любому процессу. Это было бы просто +

4764

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 09 Ноября 2007, 22:10:14 »

Так для этого я и хочу написать четко тем 10-15 и что мы хотим от конкретной тематике, чтобы не было раздрая. А если указать в общем как ты пишешь, то никто ничего никогда не сделает, т.к. не поймет за что хвататься, это я знаю по своей студенческой жизни. В общем можно написать, чтобы у студента была возможность предложить свою тему.

Ради бога - напиши темы. Только я например не очень понимаю зачем? Зачем уточнять темы, пусть пишут что хотят и как понимают. Если не понимаю пускай не пишут. какова цель конкурса?

4765

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 09 Ноября 2007, 22:07:22 »

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

Гриша, давай не будем:-) Есть OpenOficce наконец. кроме того вузы могут и часто имеют программу от msdnaa. Так что

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

Вот это дело

Или упростить требования.

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

4766

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 09 Ноября 2007, 17:24:10 »

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

Мне кажется нужно точно указать тематику статей.

Ты пишешь: на тему ИТ анализа. А что такое ИТ-анализ? Что к нему имеет смысл отнести. В объявлении написано и методологии разработки ПО.

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

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

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

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

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

Другие просто опубликуют свой опыт использования. Например пример выполнения некоторого курсового задания по проектированию с использованием той или иной нотации, систем проектирования, средств разработки.

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

Вряд ли интересно читать что такое P-моделирование. Гораздо интереснее увидеть как это применено на практике.

Кроме того можно выделить тематику оригинального использования UML, что мы как-то высказывали на форуме.

Т.е. любая тема свзяанная с разработкой проектного решения, а не с описанием например некой программы и ее возможностей.

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

Нам же следует просто указать:
1. тип файла (например word 2003)
2. типы используемых стилей заголовков
3. правила подписи рисунков
4. правила подписи таблиц
5. правила указания ссылок
6. типы и размеры шрифта
7. правила ведения списка
9. правила формирования шапки файла-документа:
Название статьи
ФИО авторов статьи
Адреса контактов
Вуз и возможно руководитель от вуза

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

4767

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 08 Ноября 2007, 23:37:35 »

А как проверять, что представитель - студент?

Объявление хорошее.

Только постараяся писать по русски и без ошибок. Бенефиты? и т.п. Насчет курсовой - это следует договариваться с преподами. Я за  - но у меня нет курсовых, правда я пробью поощрение для своих через заведующего кафедрой.

Естественно пробный.

Неплохо бы объявить возможные журналы

Насчет приехать, тоже нужно искать варианты, а то 1000 р премия и 800 р на дорогу - невелика доходность :-)

4768

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 08 Ноября 2007, 22:50:48 »

Финансирование на проведение конкурса предоставлено - 10 000 руб.

Теперь надо начинать деятельность по привлечению ВУЗов:
1. У кого есть где-то знакомые или сами преподаватели - давайте контакты.
2. Так же где можно найти перечень всех ВУЗов (а лучше с указанием кафедр/факультетов) , в которых есть ИТ специальности?
3. Нужно составить текст объявления для конкурса
4. Нужно предоставить по каждой анонсированной выше теме - цель статьи и краткий план (или что там должно быть)

1. ИГХТУ - представитель имярек собственной персоной (но очень сомневаюсь)
2. ИГЭУ - ивановский государственный энергетический университет www.ispu.ru - там есть кафедра пограммного обеспечение компьютерных систем и еще кажется информационных технологий
3. ИвГУ - ивановский государственный университет - сайт точно не знаю - мощная кафедра по ИТ
4. ИГТА - ивановская государственная текстильная академия - что-то вроде информационных технологий в маркетинге или что-то подобное

Но по опыту проведения разных конкурсов нужно:
предоставить список направлений в которых следует писать статьи, либо список актуальных тем (тогда он должен быть обширным)

объявить призовой фонд и премии за места

объявить критерии оценки

объявить формат статей

объявить команду экспертов и механизм связи и предложения статей на рассмотрение

определить рамки проекта - его начало, дедлайн, время рассмотрения конкурса

4769

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 08 Ноября 2007, 22:41:39 »

Эд, а можно прикрутить какой-нить компонент к Джомле для того, чтобы зарегистрированный пользователь мог выбрать себе тему и приложить файлик со статьей?
А м.б. использовать для этого дела Гидру? Или может Вики установить или использовать уже существющие?

Да в ремозитории можно открыть разрешение для закачки файлов, только мне думается а зачем. Можно же спокойно дать адрес куда предоставлять статьи

4770

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

« : 08 Ноября 2007, 20:45:58 »

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

А кто спорит. Вещь надежная. Структурный подход однако никто не отменял. а компутеры в реале последовательные машины Тьюринга пока