166

Обучение / Re: Журнал для аналитиков "AnalyzeIT"

« : 30 Января 2009, 18:31:08 »

Мне будет интересно прочитать A Taxonomy of Stakeholders, линка на которую появлялась на сайте в новостях. Если это интересно,  могу ее перевести для журнала. Но статья очень большая, так что если переводить, то надо будет решить, что нужно, отдельные интересные куски или последовательные главы из номера в номер.

167

Примеры / Re: Выполнение примера описания требований для ИС "Аттестации Студентов"

« : 27 Января 2009, 18:14:54 »

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

168

Примеры / Re: Выполнение примера описания требований для ИС "Аттестации Студентов"

« : 14 Января 2009, 11:05:13 »

А обязанности Рецензента - это проанализировать входные данные и результат с т.з. соответствия, полноты и т.п.? Если да, то возьмете меня рецензентом?

169

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

« : 15 Декабря 2008, 23:37:15 »

В начале февраля планируем провести семинар по теме "Планирование процесса разработки и управления требованиями". Более подробно о сроках и плане семинара сообщу позже.

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

170

О Сайте и Форуме / Re: Снова о логотипе

« : 15 Декабря 2008, 23:35:43 »

Ну вы, ребята (Гриша и Эд), сегодня даете! Вас читать просто праздник какой-то! :-)

171

Sparx / Re: Enterprise Architect: Надпись from под элементом

« : 15 Декабря 2008, 18:32:15 »

Irr, честно просмотрел свойства диаграммы и не нашел там "show namespace". Если не затруднит, опишите, пожайлуста, как добраться до этой галочки )

Зависит от версии ЕА. У меня 7.1. В ней по диаграмме щелкаем правой кнопкой мыши, properties, находим вкладку diagram и там галку снимаем. В старой версии было по-другому, как именно, не помню, возможно где-то в меню по правой кнопке мыши - Appearence или Visibility :-( Но, хелп ЕА поможет: ключевые слова для поиска: Show Namespace, Set Appearance Options, что-нибудь в этом стиле.

172

Sparx / Re: Enterprise Architect: Надпись from под элементом

« : 15 Декабря 2008, 15:50:12 »

Может вы еще знаете, как убрать надпись "from ....." у объекта, который берется из одной диаграммы и переносится, в виде ссылки, на другую?

Убрать галочку Show namespace в свойствах другой диаграммы.

173

Тестирование / Re: Test Case & Test Analyst

« : 12 Декабря 2008, 15:28:40 »

А какова в среднеем время изготовления одного Test Case?
И каково в среднем их колличество(10 , 50,100 шт)?

Ну как можно ответить на эти вопросы, не зная конкретики системы и квалификации писателя?!

174

Тестирование / Re: Test Case & Test Analyst

« : 12 Декабря 2008, 13:10:31 »

Вопрос по Test Case
Какой вариант более правильнее в написании.Вернее сказать более распространен.
Вариант 1
3 Описание ожидаемого результата

Вариант 2 (См вложение)
3 Скриншот ожидаемого действия
4 Результат

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

175

Тестирование / Re: Test Case & Test Analyst

« : 08 Декабря 2008, 11:34:27 »

Вопрос.
Какова стоимость или время разработки Test Case?

Не зная контекста задачи, сказать очень сложно. Это все равно, что вопрос "А сколько будет стоить написать ТЗ?" без указания конкретики о системе.

Каковы должны быть причины , чтобы не разрабатывались Test Case в компании?

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

176

Конференции Семинары и Тренинги / Re: [Семинар] Классификация требований, 29 ноября, СПб

« : 02 Декабря 2008, 10:33:36 »

Ну Вы после семинара посидели в кабачке?

Все закончилось в 2, до 3 обсуждали процессы и артефакты, а в 4 у меня поезд был, еле успела :-)

177

Конференции Семинары и Тренинги / Re: [Семинар] Классификация требований, 29 ноября, СПб

« : 01 Декабря 2008, 22:52:21 »

Большое спасибо Виталию Григорашу, организовавшему этот семинар,  компании EPAM, давшей в период кризиса не только приют, но и чай-кофе-печенюшки, и докладчикам, Алексею Шемису и Сергею Атрощенкову, за подготовленные материалы и выступления.

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

1 выступление. Классификация требований к ПО.
В принципе, тема раскрыта за исключением того, что приведены 2 варианта классификации (по Коберну и по RUP), но они не трассированы друг с другом.
Замечания к презентации:
- хорошо бы приводить иногда английские названия терминов (в скобочках, чтоб не было путаницы, например концепция (vision)).
- в таблицах иногда некорректно названы столбцы (столбец категории требований называется просто требования, типы требован ий названы методами выявления). Это может запутать начинающих.
- в презентации активно используются списки, но не всегда отделяется общее от его частей, что тоже сбивает.
- не везде структура презентации и доклада ясна и последовательна (например, дважды всплывает тема документирования требований).

2 выступление. Связь требований с артефактами тестирования.
Тема раскрыта. Удивило то, что аудитория абсолютно спокойно восприняла сообщение докладчика о том, что в Agile роль аналитика не выделена.
Замечания к презентации и докладу:
- по презентации не всегда понятно, какой вопрос мы обсуждаем на этом слайде,
- ролевые функции аналитика и тестировщика описаны как-то смазано.

Общее замечание к обоим презентациям – хорошо бы таки проверять ошибки хотя бы spellchecker'ом MS Office. А то нехорошо писать на слайде про то, что аналитик должен владеть русским языком, и оставлять в презентации много лишних запятых и несогласованных  по падежам фраз.

Как можно заметить, мои основные замечания – к форме, а не к сути докладов, что не может не радовать!

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

3 – практическое задание
Идея была хорошая, но в ходе выполнения была потеряна цель задания – классифицировать выявленные требования,  так как большая часть аудитории увлеклась выявлением ВСЕХ требований по маленькому письму от заказчика, что было в сложившихся условиях нереально, но очень занимательно. Зато это показало, насколько тема выявления требований всех уровней близка и интересна аудитории. В общем, чудно время провели :-)

Заинтересовавшие темы, обсуждавшиеся в кулуарах:
- обучение аналитиков с нуля,
- написание аналитической документации на изменение существующей системы и сопровождение требований к системе нарастающим итогом,
- роли, модели и документы, использующиеся в реально работающем процессе производства ПО.
Не могу удержаться и не поделиться: во вложениях приведены картинки, нарисованные Асей Руденко прямо на семинаре.
rj.jpg описывает ощущения от описания agile-разработки во втором докладе.
rj2.jpg - впечатления от увлекшейся извлечением требований группы товарищей во время практического задания.

178

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

« : 29 Ноября 2008, 22:48:13 »

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

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

179

Системный Анализ и Требования / Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б

« : 27 Ноября 2008, 18:12:00 »

Отлично! По п.2 получены ответы. ГОСТы авторы статьи знают. Снимаю. Спасибо, Mouse, Galogen!
П. 3 это придирка к стилю, тоже можно снять.
Остались претензии по п. 1 и 4.

Ну и добавлю вопрос к знатокам требований и use case:
5. Я по этой статье поняла так: требования выявляются и формируются в виде списка Requirement-ов, а каждый элемент этого списка требований порождает один или несколько use case? Т.е. у нас есть модель требований (Requirements), покрывающая все предполагаемые изменения, и страссированная с ней модель use case, которая так же покрывает все предполагаемые изменения, но описывает более детально, в виде целевых функций.
Правильно ли я поняла ход мысли авторов стати и суть способа? Если да, вы согласны с таким выделением требований и use case?
Galogen, если мы проведем аналогию с приведенной тобой схемой Коберна, то у нас получится, что Требования из статьи - это цели действующих лиц, правильно?
6. И еще вопрос к знатокам UML:
Смотрим на описание процесса выполнения функции, к сожалению, рисунки не пронумерованы, ссылку поставить не могу:
А из Activity может выходить более чем 1 control flow? Например, товар найден, товар не найден.

180

Системный Анализ и Требования / Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б

« : 27 Ноября 2008, 15:06:58 »

Прочитала. Все тоже самое, что читалось в 2006 году.
О хорошем:
Эта статья редкий случай, когда предлагается работающая на практике инструкция по разработке моделей разных уровней детализации.
А теперь о плохом:
1. при чем здесь UML? В этом документе вообще нет ссылок на спецификации UML, а определения Use Case и др. даются либо в трактовке RUP, либо цитатами из файла помощи средства моделирования. Да-да, и этой ссылке "В спецификациях OMG UML ( UML Superstructure Specification, v2.0, p. 17 ) элемент  "Use Case" определяется как: "The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system"." вплоть до указания страницы p.17 текст совпадает с текстом хелпа средства моделирования EA.

2. "Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы [6], а под задачей - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида [4]."
По этой цитате возникает впечатление: если не натянули определение use case на функцию, так мы определение функции дотянем до use case! Интересно, в ГОСТах определение функции такое? Прям через слово "подразумевается"?

3. "В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели "Use Case Model", функции системы и элемента "Use Case" в соответствии с описанием UML 2.0."
эээ в соответствии описанием UML откуда?
Хотя... это частный случай п.1

4. "элемент UML "Requirement"" - меня терзают смутные сомнения, что в спецификации UML нет элемента Requirement. Что скажут знатоки?