31
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
35
Термины и Определения / Создание подраздела Термины
« : 26 Июня 2008, 19:00:02 »
Друзья, у нас появляется много топиков с переводом англоязычных терминов на русский язык.
Предлогаю сделать отдельный раздел "Темины и определения". Возможно вести общий глоссарий терминов и их перевода. Для терминов можно ввести понятие статуса, например предложен, утвержден. Причем пока термин не обсудится на форуме и не утвердится большинством участников не менять его статус. Если не будет желающих могу курировать раздел. Общий глоссарий треминов думаю пригодится многим, особенно в ситуациях, когда "буржуинские" технологии применяются в проектах для отечественного заказчика, который не позволяет использовать в документации английскую терминологию. Создание общего глобального словаря может перерости в то, что русские айтишники начнут общаться на одном языке
.
Предлогаю сделать отдельный раздел "Темины и определения". Возможно вести общий глоссарий терминов и их перевода. Для терминов можно ввести понятие статуса, например предложен, утвержден. Причем пока термин не обсудится на форуме и не утвердится большинством участников не менять его статус. Если не будет желающих могу курировать раздел. Общий глоссарий треминов думаю пригодится многим, особенно в ситуациях, когда "буржуинские" технологии применяются в проектах для отечественного заказчика, который не позволяет использовать в документации английскую терминологию. Создание общего глобального словаря может перерости в то, что русские айтишники начнут общаться на одном языке
.
36
Sparx / Анализ влияния в EA и Raquest
« : 26 Июня 2008, 12:51:03 »
Друзья! Всем привет
Подскажите пожалуйста, как в Sparx EA + Raquest отслеживать влияние изменения одного требования на другие?
Например, имеется набор ВИ и связанных с ними функциональных требований. Связь между требованиями можно проставить с помощью трассировки в матрице трассировки. Один ВИ может быть трассировн на несколько требований.
Если я изменил вариант использования (наименование, описание и тд.) изменения могут повлиять на связанные с ним требования. В Raquest я не нашел подобной фичи.
Для сравнения в RequisitePro при изменении требования связь трассировки помечается как suspect и я сразу вижу, что необходимо проверить остальные требования на непротиворечивость. Хотелось бы иметь такую фичу в Raquest.
Подскажите пожалуйста, как в Sparx EA + Raquest отслеживать влияние изменения одного требования на другие?
Например, имеется набор ВИ и связанных с ними функциональных требований. Связь между требованиями можно проставить с помощью трассировки в матрице трассировки. Один ВИ может быть трассировн на несколько требований.
Если я изменил вариант использования (наименование, описание и тд.) изменения могут повлиять на связанные с ним требования. В Raquest я не нашел подобной фичи.
Для сравнения в RequisitePro при изменении требования связь трассировки помечается как suspect и я сразу вижу, что необходимо проверить остальные требования на непротиворечивость. Хотелось бы иметь такую фичу в Raquest.
37
Варианты Использования (Use Case) / Варианты использования для средств графического проектирования
« : 06 Июня 2008, 10:28:43 »
Привет всем!
Коллеги, может быть кто-нибудь сталкивался с написанием сценариев вариантов использования для средств графического проектирования. Имеется ввиду средства, в которых есть бланк и панель виджетов. Виджеты выбираются из панели и размешаются на бланке.
Все мы с вами работает с CASE средствами и рисуем диаграммы подобным образом, также создаются формы отчетов, например, в Crystal Reports.
Мой вопрос заключается в том, что по вашему мнению в данном случае является целью пользователя и как дробить и описывать варианты использования?
На мой взгляд, цель пользователя - создать конечный графический объект (набор виджетов), например шаблон отчета, а не разместить на бланке элементарный виджет.
Т.е. я создаю ВИ "Создать шаблон отчета", в сценарии которого описываю последовательность действий пользователя. Все вроде бы нормально, но возникает проблема в том, что пользователь может размещать элементы на бланке в различной последовательности.
Может быть написать просто, пользователь выбирает элемент и добавляет его на бланк? Тогда необходимо описывать правила добавления и размещения для каждого типа элемента, например, в разделе связанные с ВИ бизнес-правила. Так?
Может кто-нибудь подскажет книжку, где описываются подобные случаи. В паттернах для ВИ я такого не нашел
Заранее спасибо.
Коллеги, может быть кто-нибудь сталкивался с написанием сценариев вариантов использования для средств графического проектирования. Имеется ввиду средства, в которых есть бланк и панель виджетов. Виджеты выбираются из панели и размешаются на бланке.
Все мы с вами работает с CASE средствами и рисуем диаграммы подобным образом, также создаются формы отчетов, например, в Crystal Reports.
Мой вопрос заключается в том, что по вашему мнению в данном случае является целью пользователя и как дробить и описывать варианты использования?
На мой взгляд, цель пользователя - создать конечный графический объект (набор виджетов), например шаблон отчета, а не разместить на бланке элементарный виджет.
Т.е. я создаю ВИ "Создать шаблон отчета", в сценарии которого описываю последовательность действий пользователя. Все вроде бы нормально, но возникает проблема в том, что пользователь может размещать элементы на бланке в различной последовательности.
Может быть написать просто, пользователь выбирает элемент и добавляет его на бланк? Тогда необходимо описывать правила добавления и размещения для каждого типа элемента, например, в разделе связанные с ВИ бизнес-правила. Так?
Может кто-нибудь подскажет книжку, где описываются подобные случаи. В паттернах для ВИ я такого не нашел
Заранее спасибо.
38
Примеры / План управления требованиями
« : 03 Апреля 2008, 13:48:21 »
Привет!
Коллеги, мог бы кто-нибудь поделиться примером плана управления требованиями.
Мне нужен пример плана заточенного под ГОСТ, где описывались бы основные типы требований с трассировкой, их атрибуты и документы, применяемые при разработке требований.
Коллеги, мог бы кто-нибудь поделиться примером плана управления требованиями.
Мне нужен пример плана заточенного под ГОСТ, где описывались бы основные типы требований с трассировкой, их атрибуты и документы, применяемые при разработке требований.
39
Термины и Определения / Термин: Business case
« : 28 Января 2008, 23:50:19 »
Всем привет!
Читая BABOK, столкнулся с термином Business Case.
Хотелось бы узнать перевод этого словосочетания на русский язык.
В инете нарыл только объяснения термина на английском. Вот одно из них:
http://en.wikipedia.org/wiki/Business_case
Подскажите, что это за документ такой и его аналоги в отечественном бизнесе.
Читая BABOK, столкнулся с термином Business Case.
Хотелось бы узнать перевод этого словосочетания на русский язык.
В инете нарыл только объяснения термина на английском. Вот одно из них:
http://en.wikipedia.org/wiki/Business_case
Подскажите, что это за документ такой и его аналоги в отечественном бизнесе.
40
Проектирование / Layer vs. Tier
« : 22 Января 2008, 02:26:31 »
Привет Всем!
Коллеги, помогите разобраться!
Я немного запутался в понятиях layer (слой) и tier (уровень) в представлении системной архитектуры.
Расскажу свое понимание этих терминов, а вы меня исправьте или дополните.
Оба подхода, как "расслоение" (layering) так и разделение по уровням (tiers) используется для декомпозиции системной архитектуры, но, как я понял, с разных точек зрения.
Слои применяются для группировки компонентов по некоторой функциональности (представление, бизнес-логика, доступ к данным).
Уровни используются при физической реализации (клиент - сервер - хранилище).
Получается, что часть слоя представления, например, может располагаться как на клиенте, так и на сервере.
1. Если мы реализуем "толстого" клиента, то представление на клиенте, если "тонкого", то на сервере.
2. Если это desktop приложение, то все слои реализованы на клиенте.
3. Часть логики слоя "доступ к данным" может быть реализована на сервере (например, Hibernate) или в хранилище (СУБД).
В дополнении ко всему, хочется заметить, что каждый уровень (tier) - это не обязательно один компьютер. Например, уровень сервер может быть развернут на одном и более компьютерах, хранилище тоже на нескольких.
+ Хотелось бы услышать какие диаграммы UML используются для представления данных концепций. Мне кажется, что это Component Diagram, Composite Structure Diagram, Deployment Diagram.
Коллеги, помогите разобраться!
Я немного запутался в понятиях layer (слой) и tier (уровень) в представлении системной архитектуры.
Расскажу свое понимание этих терминов, а вы меня исправьте или дополните.
Оба подхода, как "расслоение" (layering) так и разделение по уровням (tiers) используется для декомпозиции системной архитектуры, но, как я понял, с разных точек зрения.
Слои применяются для группировки компонентов по некоторой функциональности (представление, бизнес-логика, доступ к данным).
Уровни используются при физической реализации (клиент - сервер - хранилище).
Получается, что часть слоя представления, например, может располагаться как на клиенте, так и на сервере.
1. Если мы реализуем "толстого" клиента, то представление на клиенте, если "тонкого", то на сервере.
2. Если это desktop приложение, то все слои реализованы на клиенте.
3. Часть логики слоя "доступ к данным" может быть реализована на сервере (например, Hibernate) или в хранилище (СУБД).
В дополнении ко всему, хочется заметить, что каждый уровень (tier) - это не обязательно один компьютер. Например, уровень сервер может быть развернут на одном и более компьютерах, хранилище тоже на нескольких.
+ Хотелось бы услышать какие диаграммы UML используются для представления данных концепций. Мне кажется, что это Component Diagram, Composite Structure Diagram, Deployment Diagram.
41
ПО Аналитика / Выбор CASE средства
« : 15 Ноября 2007, 16:39:23 »
Добрый день, коллеги!
Хочу посоветоваться с Вами по поводу выбора инстументального средства (набора средств).
Сначала о проблеме:
Встала проблема выбора инструментальных средств разработки и поддержки ПО.
Коллеги по работе никак не могут определиться в чем они хотят работать. Одни следуют новациям и выбирают новые (и не знакомые) средства, другие хотят работать в том, что используют на протяжении уже десятка лет (средства без сквозного процесса разработки, например Oracle Designer).
Предлагается следующий набор (RSA+WBM+requisitePro). У данного набора есть свои преимущества и недостатки.
Недостатки, имхо:
1) С отчетами у IBM большая проблема, т.к пока создашь шаблон с помощью СОДы потратишь кучу времени и в итоге можешь остаться ни с чем.
2) Встала проблема командной работы в RSA, работа по фрагментам модели глючит.
3) Модель бизнес-процессов из WBM переносится в RSA отлично. Используем элементы модели (сущности и др.) для создания ОО модели, но если после переноса изменился бизнес-процесс и его элементы, то эти изменения никак не отображаются в RSA. Следовательно, для того чтобы начать проектировать ОО модель необходимо иметь законченную модель бизнес-процессов.
Преимущества:
1) Какая-никакая а возможность переноса моделей все таки есть
2) Удобная работа с требованиями
3) Поддержка всего жизненного цикла разработки в одной среде и др.
Необходимо выбрать:
1. Средство моделирования UML моделей с поддержкой UML 2.0
1.1. Возможность генерации отчетов
1.2. Возможность командной работы над одной моделью
1.2. Возможность импорта моделей бизнес-процессов
2. Средство моделирования бизнес-процессов (с поддержкой WSDL, BPEL)
3. Средство управления требованиями.
Желательно, чтобы все средства интегрировались друг с другом.
Так как кроме продуктов IBM я ничего не знаю Прошу помочь выбрать, или хотя бы предложить варианты.
Средств много и все на первый взгляд отличные. Читал немного об Sparx EA и Sybase PD. Немного слышал об Visual Paradigm.
Хотелось бы знать как обстаят дела у PD с управлением требованиями и бизнес-моделированием. И что вы можете сказать о VP. Имхо, неплохое средство.
Заранее спасибо
Хочу посоветоваться с Вами по поводу выбора инстументального средства (набора средств).
Сначала о проблеме:
Встала проблема выбора инструментальных средств разработки и поддержки ПО.
Коллеги по работе никак не могут определиться в чем они хотят работать. Одни следуют новациям и выбирают новые (и не знакомые) средства, другие хотят работать в том, что используют на протяжении уже десятка лет (средства без сквозного процесса разработки, например Oracle Designer).
Предлагается следующий набор (RSA+WBM+requisitePro). У данного набора есть свои преимущества и недостатки.
Недостатки, имхо:
1) С отчетами у IBM большая проблема, т.к пока создашь шаблон с помощью СОДы потратишь кучу времени и в итоге можешь остаться ни с чем.
2) Встала проблема командной работы в RSA, работа по фрагментам модели глючит.
3) Модель бизнес-процессов из WBM переносится в RSA отлично. Используем элементы модели (сущности и др.) для создания ОО модели, но если после переноса изменился бизнес-процесс и его элементы, то эти изменения никак не отображаются в RSA. Следовательно, для того чтобы начать проектировать ОО модель необходимо иметь законченную модель бизнес-процессов.
Преимущества:
1) Какая-никакая а возможность переноса моделей все таки есть
2) Удобная работа с требованиями
3) Поддержка всего жизненного цикла разработки в одной среде и др.
Необходимо выбрать:
1. Средство моделирования UML моделей с поддержкой UML 2.0
1.1. Возможность генерации отчетов
1.2. Возможность командной работы над одной моделью
1.2. Возможность импорта моделей бизнес-процессов
2. Средство моделирования бизнес-процессов (с поддержкой WSDL, BPEL)
3. Средство управления требованиями.
Желательно, чтобы все средства интегрировались друг с другом.
Так как кроме продуктов IBM я ничего не знаю
Прошу помочь выбрать, или хотя бы предложить варианты. Средств много и все на первый взгляд отличные
. Читал немного об Sparx EA и Sybase PD. Немного слышал об Visual Paradigm.Хотелось бы знать как обстаят дела у PD с управлением требованиями и бизнес-моделированием. И что вы можете сказать о VP. Имхо, неплохое средство.
Заранее спасибо
42
Тестирование / Test Case & Test Analyst
« : 19 Июля 2007, 22:53:35 »
Привет!
Мой вопрос может быть будет не совсем в тему, но я все же надеюсь, что есть люди, которые смогут мне помочь.
Проблема в том, что мне сейчас поставлена задача написания сценариев тестирования (test cases) по имеющимся вариантам использования (use cases). Я никогда такой работой не занимался и не совсем представляю с чего начать. В RUP есть роль Test Analyst, который отвечает за написание этих самых test cases по ВИ, но к сожалению нет шаблона документа с описанием этих самых ТС и очень мало информации по их написанию.
Если кто-то занимался подобной работой подскажите как лучше оформить данный документ. А может у кого то есть уже готовый шаблон? Буду очень признателен.
Пока описываю по следующей схеме:
1. Test Case ID Название
2. Краткое описание
3. Предусловие
4. Шаги тестирования (что должен делать тестер)
4.1 Шаг 1
4.1.1 Описание
4.1.2 Входные значения (Например, ввести значение и нажать кнопку)
4.1.3 Выходные значения (что-то вроде ожидаемых результатов - например, окно с сообщением ошибки)
5. Постусловие
ЗЫ Обратился сюда так как считаю, что данную роль могут выполнять аналитики. Я сам писал когда-то ВИ, теперь вот надо написать по ним test cases.
Мой вопрос может быть будет не совсем в тему, но я все же надеюсь, что есть люди, которые смогут мне помочь.
Проблема в том, что мне сейчас поставлена задача написания сценариев тестирования (test cases) по имеющимся вариантам использования (use cases). Я никогда такой работой не занимался и не совсем представляю с чего начать. В RUP есть роль Test Analyst, который отвечает за написание этих самых test cases по ВИ, но к сожалению нет шаблона документа с описанием этих самых ТС и очень мало информации по их написанию.
Если кто-то занимался подобной работой подскажите как лучше оформить данный документ. А может у кого то есть уже готовый шаблон?
Буду очень признателен.Пока описываю по следующей схеме:
1. Test Case ID Название
2. Краткое описание
3. Предусловие
4. Шаги тестирования (что должен делать тестер)
4.1 Шаг 1
4.1.1 Описание
4.1.2 Входные значения (Например, ввести значение и нажать кнопку)
4.1.3 Выходные значения (что-то вроде ожидаемых результатов - например, окно с сообщением ошибки)
5. Постусловие
ЗЫ Обратился сюда так как считаю, что данную роль могут выполнять аналитики. Я сам писал когда-то ВИ, теперь вот надо написать по ним test cases.
43
Обучение / Электронная библиотека
« : 10 Июля 2007, 14:07:44 »
Привет!
Решил поделиться книжками
В аттаче находится архив со списками электронных книжек, которые я собрал за пару лет.
Может быть кто-нибудь найдет для себя полезную книгу.
Книжки могу выслать по мылу.
Пишите
email: faland@inbox.ru
grigorash@ici.spb.ru
icq: 229351127 (после 20:00)
С уважением, Григораш Виталий
ЗЫ Кстати часть книг скачана мной с natahaus.ru. Всем советую, имхо, одна из лучших электронных библиотек
Решил поделиться книжками
В аттаче находится архив со списками электронных книжек, которые я собрал за пару лет.
Может быть кто-нибудь найдет для себя полезную книгу.
Книжки могу выслать по мылу.
Пишите
email: faland@inbox.ru
grigorash@ici.spb.ru
icq: 229351127 (после 20:00)
С уважением, Григораш Виталий
ЗЫ Кстати часть книг скачана мной с natahaus.ru. Всем советую, имхо, одна из лучших электронных библиотек
44
ПО Аналитика / IBM Rational Software
« : 05 Июля 2007, 00:37:02 »
Приветствую, коллеги !!
В первую очередь хочу сказать спасибо создателям ресурса. Много интересного и полезного.
Почитал немного форум и понял, что почти никто не пользуется программным обеспечением фирмы Rational (RSM, RSA, SoDA, RequesitePro).
Интересно почему? Ведь именно IBM'овцы стоят у истоков UML и многие гуру (Booch, Jacobson и др) участвуют при разработке этих программных продуктов. И если вы работаете по RUP, то продукты IBM, имхо, идеальный вариант.
С уважением, фанат IBM
В первую очередь хочу сказать спасибо создателям ресурса. Много интересного и полезного.
Почитал немного форум и понял, что почти никто не пользуется программным обеспечением фирмы Rational (RSM, RSA, SoDA, RequesitePro).
Интересно почему? Ведь именно IBM'овцы стоят у истоков UML и многие гуру (Booch, Jacobson и др) участвуют при разработке этих программных продуктов. И если вы работаете по RUP, то продукты IBM, имхо, идеальный вариант.
С уважением, фанат IBM