2071

Для всех / Re: Юнит тесты и работа аналитика.

« : 01 Февраля 2011, 11:20:59 »

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

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

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

Т.е. аналитик занимается приемычным тестированием по сути, проводит мини опытную эксплуатацию.

Это конечно мое личное мнение и наблюдение.

2072

Для всех / Re: Юнит тесты и работа аналитика.

« : 01 Февраля 2011, 09:21:33 »

А при помощи какого продукта автоматизируете?

Используем TestComplete. Мы используем 7. На 8 там драконовские условия по лицензированию, имхо

2073

Для всех / Re: Юнит тесты и работа аналитика.

« : 31 Января 2011, 23:02:09 »

Спасибо! А автотесты есть? И вообще тестирование как-то автоматизировано? То есть я прошёл при тестировании логики маршрут часа на 2 и каждый раз тестировать бы это не хотел, но тк я аналитик, то с автоматизацией не знаком, но, догадываюсь, что это можно сделать..

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

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

2074

Sparx / Re: Тренинг по Sparx Enterprise Architect

« : 31 Января 2011, 22:48:36 »

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

2075

ПО Аналитика / Re: StarUML. Как включать Attachments, Constraints... в template.

« : 31 Января 2011, 16:20:31 »

Спасибо за реплики. Я уже не надеялся.
>Galogen: Но, стоит ли тратить силы на неразвивающийся инструмент?
- мне нужно дать студентам немного элементов UML (с упражнениями и использованием в курсовом по проектированию). StarUML - бесплатный. На Rational Rose мне денег не дадут ($7000). Есть ещё Enterprise Architect - на него, может, дадут. Предложите совет за что браться.
Форум, который вы упоминаете - малопосещаемый и добиться ответа будет трудно.

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

На розу денег не дадут - факт, да и на ЕА могут не дать. Пока есть альтернатива тот же VP дает нормальную академическую версию без денег, наверняка есть и другие. Можно попробовать заключить соглашение с IBM, варианты есть

Да можно использовать и StarUML, но риск понятный есть

2076

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 31 Января 2011, 09:56:58 »

4. Цели использования системы:
а)Открыть новый сервисный лист для внесения данных о клиенте, СВТ, причине обращения с возможностью печати копии для клиента.
б)Сформировать заявку на ремонт/обслуживание СВТ клиента по открытому сервисному листу.
в)Отслеживать сформированные заявки на предмет своевременного их выполнения.
г)Формирование отчетов для анализа эффективности выполненных работ
д)Сбор статистических данных.

Т.е. по пункту 3+4 можно сделать диаграмму СВИ, где актер зав.склад будет ассоциироваться к ВИ (д), а актер начальник будет ассоциироваться с ВИ (г) ?

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

Я бы составил табличку: Роль - Возможные ВИ
Из анализа таблички, можно было бы сделать требуемую иерархию

2077

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 31 Января 2011, 00:13:33 »

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

Но - это не все требования к системе. Т.е. одних ВИ недостаточно для проектирования системы. Это нужно учитывать.

Мне кажется последняя диаграмма (на другие я не обращаю внимание) не совсем корректна. Я вообще у вас не улавливаю разницу между БВИ и СВИ.

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

2078

ПО Аналитика / Re: StarUML. Как включать Attachments, Constraints... в template.

« : 30 Января 2011, 23:13:05 »

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

2079

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

« : 30 Января 2011, 23:06:34 »

Minona, уж больно Вы быстры.

Тут читать не перечитать, понять не перепонять. Однако...

1. какова цель проекта? Зачем проектировать бот с искусственным интеллектом?
2. Что такое искусственный интеллект:
3. Что такое сокращение ЕА?
4. Зачем проектировать на Visual Paradigm?

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

2080

Для всех / Re: Юнит тесты и работа аналитика.

« : 30 Января 2011, 22:51:52 »

Отличная тема.

Мой ответ.  Я думаю, что не должен. Хотя если следовать Майерсу. Тестировщик - человек с особым типом мышления, и не должен быть аналитиком или кем-то еще кроме тестировщика

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

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

2081

Sparx / Re: Тренинг по Sparx Enterprise Architect

« : 28 Января 2011, 18:59:49 »

К примеру? уже  есть такой тренинг но в Киеве.

Не есть, а был к сожалению. Будет ли Ирина его развивать?

2082

Sparx / Re: Тренинг по Sparx Enterprise Architect

« : 28 Января 2011, 18:58:49 »

C чего начать?

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

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

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

Насколько можно судить
- составление и настройка отчетности
- организация совместной работы
- использование системы как центра управления

2083

Задачи студентов / Re: Помогите пожалуйста с лабой.

« : 28 Января 2011, 17:04:31 »

http://repository.uml3.ru/doku.php?id=models:helloworld:main
Модель приложения "Hello, World!".

Java реализация: http://repository.uml3.ru/doku.php?id=models:helloworld-java:main

2084

Sparx / Re: Тренинг по Sparx Enterprise Architect

« : 28 Января 2011, 17:03:02 »

А для представления что может EA думаю тренинг не нужен. Здесь нужнее скорее справочное руководство.
И желательно на русском.

Согласен. Кстати мы могли бы попытаться это сделать. Определить участников проекта, определить форму составления справочного пособия, распределить части и начать делать. Ну да еще нужен руководитель-интегратор, в качестве инструмента - наверное можно развернуть авторизуемое вики?

2085

Sparx / Тренинг по Sparx Enterprise Architect

« : 28 Января 2011, 11:05:56 »

А он действительно нужен? А формат? А что конкретно в инструменте? Все или возможно какие-то отдельные темы? Может сначала сформируем план тренинга, определим, что в первую очередь интересует, а что в последнюю?

Как я понимаю начальным условием к слушателям - удовлетворительное знание UML?