1966

ПО Аналитика / Re: Посоветуйте с выбором CASE-средства

« : 29 Марта 2011, 11:04:18 »

Case-средства момент вторичный. Первичный умение использовать их начинку. А умение использовать начинку case-средства (чаще всего UML) вовсе не требует наличия case-средства.

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

Их много, как платные, так и бесплатные.

Я могу посоветовать:
платные
Magic Draw
Visual Paradigm
Enterprise Architect

бесплатные
зависит от среды, но
StarUML
UML for Eclipse

Более подробно тут: http://en.wikipedia.org/wiki/UML_tools

1967

RUP EUP AUP OpenUP / Re: UP: Документ с исходной архитектурой

« : 29 Марта 2011, 10:56:28 »

Большое спасибо за ответ!
Хоть книг у меня и много, но они редко могут ответить на вопрос "а что, если вот ТАК попробовать?" Я очень рад возможности услышать ответ, пусть даже на нелепый вопрос

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

1968

RUP EUP AUP OpenUP / Re: UP: Документ с исходной архитектурой

« : 29 Марта 2011, 08:04:15 »

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

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

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

ВИ типа "управление чем-либо" - это типичный шаблон CRUD. Его можно использовать, а можно незаморачиваться особо.

1969

Проектирование / Re: Проектирование ИИ бота

« : 29 Марта 2011, 07:48:51 »

Идея хороша, но здесь народ не поддержал

Что значит не поддержал? Вы кроме слов ничего не предложили.

1970

RUP EUP AUP OpenUP / Re: UP: Документ с исходной архитектурой

« : 28 Марта 2011, 18:41:58 »

Если следовать унифицированному процессу (или его конкретным проявлениям в виде RUP, OpenUP и иже с ними), тогда ответ прост. Берем рекомендации оных процессов и делаем как велено:)

Следуя UP. Часто выделяется спецификация требований в виде описания вариантов использования. Все что не относится к ВИ или по тем или иным причинам решено в ВИ не включать, может быть отражено с спецификации дополнительных требования в классификации FRUPS+

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

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

Возьмем любую cms, например, joomla. Она сделана ровно так как вы хотели бы (правда тут все проще, код не компилирован и доступен в исходном виде). Но сути не меняет, в любом случае клиент должен знать каким -образом создать и подключить модуль в работающую систему.

Или пример Miranda. Примеров масса

1971

RUP EUP AUP OpenUP / Re: UP: Документ с исходной архитектурой

« : 28 Марта 2011, 08:27:30 »

Не совсем понятно, какой смысл вкладывается в понятие "группа".
Что значит группа моделей почему она отделяется от группы доступа.
Что это такое группа модулей "обычный пользователь" и т.п.

В каком формате (каком документе) ПРИНЯТО описывать такие архитектурные требования?

Какие такие архитектурные требования?

1972

Книги, статьи и ресурсы / Re: Фримен, Фримен, Сьерра и Бейтс "Паттерны проектирования"

« : 26 Марта 2011, 16:40:38 »

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

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

1973

Работа / Re: Куда дальше? О чем мечтают бизнес-аналитики.

« : 25 Марта 2011, 14:51:55 »

Кажется, пока работала - мечтала уволиться.
А с переходом в руководство проектами жизнь стала такой фееричной, что даже мечтать нет необходимости - сказка на работе ежедневная

Похожая ситуация

1974

Работа / Re: Работа для тех, кто только закончил ВУЗ (начало карьеры)

« : 24 Марта 2011, 16:40:42 »

Девушка или ... а вы форум то правильно выбрали?

Наболело

1975

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 23 Марта 2011, 23:08:13 »

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

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

1976

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

« : 21 Марта 2011, 22:48:10 »

Я бы посоветовал новичку начать с изучения, имеющегося в интернете и литературе материала.
Вигерс вполне классичен и достаточно доступен.
Есть материалы и на Intuit.ru.
Да и здесь на форуме + в нашем FAQ сайта вы можете найти достойные советы.

1977

Управление Проектом / Re: Средство автоматизации доски Scrum

« : 21 Марта 2011, 17:06:03 »

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

Еще попробуйте, подышите посильнее Ну серьезно там нужно смотреть в сторону итераций и планировать задачи

1978

Управление Проектом / Re: Средство автоматизации доски Scrum

« : 21 Марта 2011, 14:27:28 »

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

Григорий, ты, конечно, прав. Но параллельно с доской реальной, сильно хотелось бы иметь доску электронную.
1. Как не хороша реальная - все-таки прочитать мне тестировщику, что кто делает можно только подойдя к ней непосредственно - а я в очках, и я лентяй
2. по доске я создаю тестовый план, а на доске картинка может меняться (что-то добавляться, что-то убираться) в электронной вресии мне это проконтролировать проще - опять же я в очках, да и лентяй порядочный
3. мы еще доску пользуем и как некоторый индикатор, отмечаем на полях, что проверено тестеровщиками, частенько хочется комментарий добавить, а на реальной не получается, ну не очень она большая. Кроме того в электронной можно было бы привязаться к номерам работ в системе управления работами

Резюме - я делаю эту доску в примерном виде руками, хотя и лентяй, но поскольку лентяй - забываю синхронизировать вовремя

1979

Тестирование / Re: Тестовые примеры

« : 19 Марта 2011, 14:39:30 »

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

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

А еще ...бывало ли в вашей  практике- разработка по тест кейсам?

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

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

Однако мой товарищ, работает в фирме по производству игр на ruby on rails, у них чистый TTD в действии и ему очень нравится.

1980

Примеры / Re: Диаграма класов: обработка изображения

« : 18 Марта 2011, 17:43:37 »

Возьмем для начала первую диаграмму, по второй возможно догадаетесь сами.

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

Резюме
тут изображена по сути DFD диаграмма, блок схема, с передачей управления от одного действия другому.
все это еще перепутано со структурным аспектом

Что делать
Отделить поведения от данных и корректно определить операции классов

Да забыл изучать UML (коли пользуемся) и ООП