496

Управление Проектом / Пятый ежегодный форум Oracle для компаний-разработчиков из стран СНГ

« : 17 Мая 2008, 18:13:18 »

21 мая, в Москве пройдет Пятый ежегодный форум Oracle для компаний-разработчиков из стран СНГ (http://www.oracle.com/global/ru/events/isv2008/index.html). Невзирая на название, доклады будут посвящены в основном вопросам программной инженерии. Среди докладчиков - Стас Калаканов (будет про CMMI рассказывать), Асхат Уразбаев, Илья Корнепаев -- будет рассказывать о требованиях (он автор перевода книги Джереми Дика и Ко (Телеложик) по требованиям и DOORS), а так же небезызвестный человек, скрывающийся под ником gaperton на форумах RSDN.ru (Владислав Балин (?)).

Я думаю посетить это мероприятие.

497

Системный Анализ и Требования / Re: Уровни требований по Вигерсу (пользователя и функциональные)

« : 17 Мая 2008, 00:37:23 »

Нет, я не трассирую предусловие к ФТ ... я просто трассирую весь (точнее все) UC на ФТ о логине ... Интересно, как в данном случае рациональнее поступать ;-) .. хорошая тема для обсуждения в качестве кейса.
Насчет описания функциональности доступной пользователю то в ФТ можно просто завести таблицу, где перечислить пересечения функции и ролей. Если функции оттрасированы с юзкейсами будем иметь целостную картину.

498

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

« : 17 Мая 2008, 00:27:28 »

Первые три пункта понял
Юра,
Под EA ты видимо имел в виду - Enterprise Аrchitecture
В общем, в данном случае относительно требований надо продумать политику (регламент) их изменения + построить первоначальный репозиторий требований, так?
Ну тут как раз и очень вероятна рассинхронизация, если не давать доступ к тулзе подрядчикам. Или при изменении требований подрядчики должны оповестить что и где поменялось??

Да, соори забыл что под EA еще можно понимать тул от Sparx :-), я имел ввиду именно Enterprise Architecture.
Худшим для организации, с т.з. затрат будет случай, когда подрядчики просто приносят новую версию ТЗ в виде файла Word, и нужно сажать аналитика (можно конечно стажера), который скурпулезно будет изучать документ, выяснять что изменилось и делать правки руками в репозитории требований. Это просто получается трудоемко. Но за все приходится платить, удешевить можно, только работой стажеров :-).
Вобщем идеальный вариант -- навязать подрядчикам использование процесса, формата и правил документирования требований и использование репозитория с тулом. Типа условие контракта. Иначе -- самим придется все отслеживать.
По середине вариант -- формальный процесс управления изменениями (в отношении требований в данном случае), тогда все изменения будут очевидны и не потребуют скурпулезного изучения каждый раз новой версии документа.

499

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

« : 16 Мая 2008, 02:13:12 »

...Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.
Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??

1. Компании нужно для начала создать корпоративный стандарт на документацию требований и форму их представления и заставить подрядчиков следовать ему.
2. Компании нужно заставить подрядчиков вносить изменения в ТЗ при их наличии, чтобы требования были актуальны. Т.е. имеем поставленный в компании процесс работы с требованиями вообще.
3. Создать единый репозиторий требований на базе некого тула и загонять все туда. При необходимости давать доступ туда подрядчикам, чтобы сами вколачивали требования.

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

500

Обучение / Re: К вопросу о диаграммах

« : 12 Мая 2008, 14:07:07 »

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

501

Системный Анализ и Требования / Re: Уровни требований по Вигерсу (пользователя и функциональные)

« : 12 Мая 2008, 13:57:57 »

1. По большому счету, логин в систему сложно считать целью пользователя. Логин - это некое решение, процедура,  ... цель которой по сути конфиденциальность, защита от НСД и т.п. Я обычно не пишу такого юзкейса, но в предусловиях отмечаю, что пользователь должен быть идентифицирован в системе. А собственно логин представляю уже как некую возможность системы -- т.е. по сути на уровне функциональных требований.
2. Совершенно согласен, что UC "Использовать банкомат" бестолковый, так же как и "выполнить транзакцию". Думаю, что в оригинале он введен исключительно для того, чтобы показать как красиво на ДИАГРАММЕ все декомпозируется. Т.е. больше для того, чтобы показать что юзкейсы не столько техника, сколько целостная модель.

502

О Сайте и Форуме / Re: [ИДЕЯ] БУКВАРЬ - база элементарных знаний

« : 28 Апреля 2008, 12:14:17 »

Gents ...
Вопрос -- а какие цели и задачи у данного БУКВАРЯ? Для кого он будет создаваться и чем он будет принципиально лучше имеющихся учебников по UML, в т.ч. на INTUIT (если мне не изменяет память там есть учебник по UML)? Какие бенефиты он даст а) сообществу б)сайту ...? Думаю именно с формулировки этого нужно начать, а потом обсуждать средства реализации.

503

Sparx / Re: Может ли кто делать консалтинг по использованию Sparx?

« : 18 Апреля 2008, 11:51:12 »

1. Есть ПОТЕНЦИАЛЬНЫЙ заказчик. Для него сечас проводится отдельным контрактом assesment, по результатам которого нужно будет ему предложить решение его проблем. Учитывая, что заказчик не потятнет софт от больших вендоров, то подумалось про Sparx. Если ему предложение понравится -- тогда другой контракт -- на консалтинг, там и нужно будет проводить такой тренинг. Отсюда мне и нужно понимание ситуации с компетенциями в этой области.
2. Наименее рискованным будет проведение тренинга ТОЛЬКО по инструменту. По мотивам Users Guide :-) + примеры и упражнения. Специфика, и прочее -- выносим за рамки обсуждения. Т.е. чисто туловый тренинг на русском языке.

504

Sparx / Re: Может ли кто делать консалтинг по использованию Sparx?

« : 17 Апреля 2008, 18:01:21 »

Понятно. Тут нужен "out-of-the-box service", ... но как вариант -- просто тренинг по продукту реально провести? Чтобы с упражнениями и все такое?

505

Sparx / Может ли кто делать консалтинг по использованию Sparx?

« : 17 Апреля 2008, 14:16:42 »

Добрый день!
Как я понял, сложилось некое community использующее инструментарий от Sparx. А может ли кто-нибудь провести консалтинг и обучение по EA и Раквест? Под консалтингом понимается разработка процесса и методики проектирования на UML под специфику проектов заказчиков, разработка шаблонов документов, проведение тренингов по этой методике (включая собственно тренинги по UML), и обучение использованию инструментария?

506

Нововведения / Re: РИТ 2008

« : 14 Апреля 2008, 13:56:26 »

Саша, а презентации или записи докладов посмотреть можно будет?

507

Нововведения / Re: IBM купил Telelogic

« : 10 Апреля 2008, 13:05:52 »

Ну факт того что IBM собирается купить Telelogic давно был известен ... вопрос был только в формальностях.
У себя в блоге я опубликовал мысли на этот счет ... так что посмотрим что будет дальше :-).

508

Идеи и мозговой штурм / Re: Тематические анекдоты

« : 08 Апреля 2008, 13:53:17 »

Хуже всего, было, что эта дама генерила кучу инициатив 99% из которых просто отметались, т.к. оказывалось что это уже реализовано или не может быть реализовано за разумные сроки и бюджет. Потом к ней отправляли провинившихся -- кто опаздывал на работу и т.п. ... :-).
А на счет аналитика, который "должен был догадаться", то я бы не стал тут употреблять термин "должен" (он же "should" в соответствии с RFC2119), а использовал бы "may" :-)

509

Идеи и мозговой штурм / Re: Тематические анекдоты

« : 07 Апреля 2008, 16:30:33 »

Пользователи, они разные бывают ... вот на моей памяти, на заре своей карьеры довелось мне пообщаться с одной пожилой дамой -- пользователем софта конторы, на которую я тогда работал. Она писала от руки на листиках что она хочет чтобы было сделано и передавала с оказией нам, или звонила -- и долго пыталась по телефону пояснить написанное. Мы устраивали консилиум, чтобы понять чего ей нужно, звонили ей, даже разговоры записывали и прокручивали  ... в результате отправили меня узнать что же она хочет. Когда я приехал и встретился воочию -- она сделала одно движение мышкой, после которого мне стало понятно что ей нужно -- drag-and-drop для возможности раскидывания документов по получателям! Но пояснить это письменно и по телефону она была просто НЕ В СОСТОЯНИИ!!! А вы говорите разговор может быть и письменный :-).

510

Конференции Семинары и Тренинги / Re: Семинар Скота Амблера

« : 07 Апреля 2008, 16:21:56 »

А кто будет устраивать его встречу/размещение и бронирование аудитории?