Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Redla

Страницы: 1
1
Я "за".
 
Я уже себе прикупила Karl E. Wiegers "Software Requirements" Second Edition

 Меня еще интересуют книги по прототипированию и usability. Кто-нибудь может что-нибудь порекомендовать?

2
У меня в общем сложилось положетельное впечатление о семинаре. Правда под конец немного затянули. Я тоже за создание раздела "Семинары", где можно было бы продолжить обсуждение.
Очень взбодрилась на докладе Евгения Манаева - для меня больная тема про варианты использования, где с одной стороны нужно вроде как описывать черный ящик, а с другой еще кучу подробностей, чтобы тестеровщики знали что тестировать, разработчики - что программировать. Но эта тема не была раскрыта до конца - была поставлена проблема, сказали, что пишут расширенный варианты использования - а как? очень хотелось бы поподробнее узнать как это происходит на практике, как к этому относяться разработчки\тестеровщики\клиенты? вобщем, если будет создан отдельный раздел, я бы там позадавала кучу вопросов ;)

3
А где именно в Люксофте будет проходить семинар, в какой переговорной? или все централизовано встречаются в холле в 19?

4
Я -она  :D

5
Хм ... чтобы можно было оценить качество русского перевода, нужно действительно сначала почитать оригинал.
А вобщем действительно было бы интересно узнать о том, какие вы обнаружили ошибки. Если не секрет -- поделитесь.
Я, конечно, так сходу не найду. Но в разделе "Документация требований" даются примеры некорректных фраз и выражений и затем идет объяснение, что не так и как было бы лучше. Так вот. Там даеться фраза. Затем в описании этой фразы, говориться, что вот это слово оно нечеткое, неконкретное. А этого самого слова в фразе, обозначенной выше, вообще нет. Для меня это очень критично, т.к. спецификации я пишу на английском языке.
Еще там очень плохое качество и при распечатке плохо видны диаграммы.
Если в следующий раз наткнусь на ошибку, отмечу и сообщу Вам.

6
Выкладывать не надо, спасибо, всё это есть на pdfchm.com, мы скорее всего тоже будем избавляться от книжек, ограничимся ссылками. Если Вигерса там не найдёте - скажите - вышлю.
Что-то я не нашла, как там скачивать книжки. Мне предлагают купить. Если не сложно, то вышлите (под Вигерсом я имела ввиду Software Requirements by Karl E. Weigers)
еще мне интересно было бы почитать Writing Effective Use Cases Addison Wesley на английском. если есть ссылка или можете выслать, то высылайте:-)
Заранее, спасибо!

7
Есть следующая литература в электронном формате (могу выслать, выложить):
1. Business Analisys Body of knowledge (ver. 1.6 Internation Institute of Business Analisys) - на английском
2. Larman. Applying UML and Patterns - на английском
3. John Wiley & amp_ Sons - Sensitivity Analysis in Practice.pdf - на английском
4. visual modeling with rational rose 2002 and uml [addison wesley'2002] - на английском
5. UnifiedModelingLanguageUserGuide by Booch Rumbaugh Jacobson на английском
6. PeopleWare (Productive Projects and Teams) by Tom DeMarco & Lister - на английском

P.S. Может у кого-нибудь есть Вигерс на английском? (русский невозможно читать. столько ошибок:-()

8
Эд, не хитрец ... это нормальный рефлекс консалтера.
Советую оставлять рефлексы консалтера на работе. А то новичков всех распугаете. Они вам вопрос, а вы им в ответ называете где он работеает и сообщаете, что счет уже выслан.
Вот и общайся так в форуме.  ;D

9
Ага. Можете высылать счет. >:(

10
Вот нашла сайт с электронными книгами. http://lex.in.ua/ooad1.html

11
http://ignatovaolga.moikrug.ru/

1. Цели - расти в профессиональном плане
2. Помощь - чем смогу, помогу. Могу поделиться материалами, мыслями, проблемами и их решениями

12
Огромное всем спасибо за советы. Сделала для себя определенные выводы.  ;)

В проекте используются шаблоны некой методологии microscope. модели рисуем в RRose. больше по сути не пользуемся ни чем.

Сейчас столкнулись с проблемой, что в use case не прописано ни одного поля, которые нужно заполнить. Например:
Пользователь добавляет новый элемент - Система открывает фору добавления нового элемента.
Пользователь заполнил атрибуты и нажал сохранить - Система проверила все ли обязательные атрибуты заполнены, сохраняет новый элемент. Если одно из обязательных полей не заполнено, система выдает ошибку.
Кстати, еще вопрос: Правильно ли прописывать текст сообщения об ошибке в use case? Мне пришлось это сделать, т.к. наши тестеровщики не могли тестировать - не знали, что должно всплывать и что должно писаться. В результате сначала прописали одни сообщения, потом поняли, что среда, в которой разрабатывают систему не может поддерживать такое поведение, переписали заново (у меня сейчас вся работа состоит в том, что я то что-то добавлю, то убиру, потом опять добавлю, то что недавно было убрано).

Если следовать совету  Александра Котельникова, то у нас на проекте кроме меня никого не останется, т.к. изменения требуют вносить и тестеровщики и разработчкики (причем разработчки не сообщают об этом аналитику!!! был скандал! При этом всегда крайний аналитик, т.к. клиенты увидели эту экстрафичу и сказали - мы этого не просили, зачем это? а ну уберите! вы не придерживаетесь наших требований! (это в случае, если эта экстрафича им непонравилась), или - а почему этого нет в требованиях, раз это уже есть в релизе, значит мы это ообсуждали этого хотели, ах как так аналитик это не прописал!)
Еще вопрос: К примеру, в use case описываю сценарий поиска "Элемента" в справочнике. Т.е. пользователь задает параметры, инициирует поиск - Система ищет "элемент" согласно заданным параметрам. На форме задается куча параметров - причем нужно проверять, чтобы дата была в формате DD/MM/YYYY, номер версии элемента не содержал букв, что в номер версии может быть введено только 12 символов с разделетелем ".", по умолчаню стоит "Искать последнюю утвержденную версию" но можно поменять на просто "последнюю", на "все", можно использовать ключевое слово (при этом система ищет соответствующее значение в поле1, поле2, коментариях и кратком описании)причем вводиться туда может до 8000 символов.
Подобной детализации в описании ограничений на вводимые данные от меня требуют тестеровщики, чтобы им можно было проверить влезает туда 8000 символов или 8001 (есть возможность завести дефект лишний раз) - что выводит из себя разработчков. Вобщем стоит ли все это прописывать в use case или для этого есть отдельный документ?   

Еще на прошлой работе у меня был опыт следующего оформления спецификаций требований: в каждую спецификацию вставлялась модель сущность-связь из Erwin, где можно было четко увидеть все атрибуты сущности, участвующей в данном сценарии, просделить связь между всеми сущностями, участвующмими в процессе. На этой работе мы так не делаем и менять методику написания use case уже невозможно (тем более шаблоны и методику диктует нам заказчик). В вашей практике занимаетесь ли вы построением модели базы данных, диаграмм классов - и где это прописываться у вас в use case или в каком-либо отдельном документе?

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

13
Всем привет.
Хотела поделиться проблемами и задачами. Вобщем, недавно я пришла работать в компанию, автоматизирующую бизнес-процессы. Я работаю системным аналитиком. Попала на проект в стадии, когда требования фактически уже собраны, мне их "пересказал" и дал почитать спецификации требований бывший аналитик. Сейчас уже идет стадия разработки - столкнулись с кучей неопределенностей, спотыкаемся на каждой мелочи. Я теперь единственный аналитик на проекте, все проблемы падают на меня и я совершенно не справляюсь! Хочу пересмотреть полностью концепцию написания спецификаций требований, но опыта не хватает грамотно к этому подойти и довести до конца. С принципами написания use case model у меня есть, но сейчас я столкнулась с тем, что не знаю, где мне прописать такие требования к системе, как ограничение полей, обязательность заполнения, взаимосвязи сущностей. Так, чтобы один раз написал спецификацию, где пользователь\заказчик сразу увидел четко обозначенные поля, что вводим, где выбираем, затем подписал это и все! А сейчас у нас постоянно добавляются новые поля, не можем разобраться с форматом вводимых данных. Вобщем ситуация бедственная! ???

Страницы: 1