2911

Sparx / Re: Контекстная диаграмма в ЕА

« : 21 Июля 2008, 16:18:39 »

Эд, пошли мне я вложу

2912

Системный Анализ и Требования / Re: РД 50-34.698-90. Стадия "Формирование требований к АС". Отчет.

« : 21 Июля 2008, 15:45:50 »

ИМХО Юра Булуй дал ответы на Ваши вопросы куда какие требования писать.
План и содержание работ можно засунуть в п. 2.1.5. и 2.3.5. ГОСТа 34.602-89 Техническое задание
А стоимость уже в договор засовываете.

2913

Sparx / Re: Контекстная диаграмма в ЕА

« : 21 Июля 2008, 15:34:17 »

Просто мало кто ходит через главный вход.

А очень зря, я новости интересные там публикую

2914

Системный Анализ и Требования / Re: Хорошие требования vs Сырые требования

« : 21 Июля 2008, 00:22:50 »

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

Ну это как обычно, выбирай 2 из 3ех: быстро, качественно, дешево.
Но представим, что Вы выполняете проект сами и Вам выбирать процесс, что бы Вы выбрали??

2915

Системный Анализ и Требования / Re: Хорошие требования vs Сырые требования

« : 21 Июля 2008, 00:13:16 »

На сколько я понимаю - это принцип напрямую используется в alige методах разработки (Scrum, XP, UP (упомянутый Galogen) )

В принципе да, но там еще хуже, как я писал выше.

2916

Системный Анализ и Требования / Re: Хорошие требования vs Сырые требования

« : 21 Июля 2008, 00:12:39 »

Итерационная разработка предполагает циклический подход. Однако во всех таких подходах, требования итерационно не уточняются, а итерационно вовлекаются.

Это кто тебе такое сказал?? Т.е. если была ошибка в требованиях, то ее не исправляют, а вовлекают новые требования??

Если же требование разрабатывать итерационно в стиле, который ты описал - то у программистов просто крыша съедит.

Вон у Agile программистов не слетают, а там еще хуже, зачастую требования вообще не прорабатывают, а кодят прям по тому что юзер написал (user story) или сказал

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

А если таких требований много?? Не лучше ли написать, реализовать, показать, уточнить, реализовать. Не будет ли это быстрее, чем долго думать, написать, реализовать, показать, понять что не то, опять уточнить и реализовать. М.б. в итерационном подходе стремиться к неболее 2-3 уточнений?

Если же проект инновационный, то мне думается тут следует действительно формировать промежуточнные прототипы, моделировать требования - но это будет скорее уже исследовательская часть, чем промышленное написание кода.

В какой-то мере все проекты инновационны. А то бы  стояли станки по производству ПО.

2917

Sparx / Re: Контекстная диаграмма в ЕА

« : 20 Июля 2008, 23:58:19 »

Эд, м.б. выложить тогда в файловый архив эту книгу.

2918

Системный Анализ и Требования / Хорошие требования vs Сырые требования

« : 20 Июля 2008, 14:53:31 »

Как известно, ошибка полученная на стадии разработки требований обходится в 200 раз дороже на стадии тестирования и сдачи. Т.о. естественно нужно прорабатывать требования хорошо и они должны отвечать следующим критериям:
• Correct - описаны верно
• Complete - полные, отражать в себе все требования заказчика
• Clear - понятные всем участникам проекта и непротиворечивые сами по себе
• Consistent - не вступать в конфликт с другими требованиями
• Verifiable - требования можно проверить
• Traceable - уникальные и взаимосвязаны между собой
• Feasible - могут быть выполнены в соответствии с планом и бюджетом
• Modular - могут быть изменены без огромных усилий
• Design-independent - в требования не должны быть включены элементы дизайна

Но с другой стороны, даже если мы честно проработаем требования, то они все равно изменяться от:
• Изменения бизнеса
• Нечеткой формулировки Заказчиком и неумышленного умалчиванием чего-то
• Политических причин
• Квалификации аналитика

Так не лучше работать с требованиями по итерациям? Т.е. описали что-то - реализовали, дальше изменили требования, дописали новые требования - опять реализовали и т.д. Тем самым время разработки получаем немного больше, но зато удовлетворенность заказчика на много выше.

Кто что по этому поводу думает?

2919

Системный Анализ и Требования / Re: РД 50-34.698-90. Стадия "Формирование требований к АС". Отчет.

« : 20 Июля 2008, 14:31:41 »

Я сам не писал РД 50-34.698-90, но можно посмотреть здесь:
* Образцы ТЗ по ГОСТу
* Документ "Массив входных данных" ГОСТ 34
* Классификация требований к ПО и ее представление в стандартах

2920

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

« : 20 Июля 2008, 14:28:47 »

Образцы ТЗ по ГОСТу
Министерство Экономического Развития и Торговли РФ создало на своём сайте раздел и выложило в нём проектную документацию по множеству проектов разработки информационных систем, создаваемых по программе "Электронная Россия".
Данный ресурс обсуждался у нас на Форуме.

2921

Sparx / Re: Контекстная диаграмма в ЕА

« : 18 Июля 2008, 12:37:22 »

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

2922

Сообщество Аналитиков / Re: [Конференция] ИТ анализ и требования (подготовка)

« : 17 Июля 2008, 17:07:20 »

Хорошо, Юра, выскажи тогда свои идеи, как можно заинтересовать гурей?

2923

Системный Анализ и Требования / Re: Выбор ПО для управления требованиями (PLM)

« : 17 Июля 2008, 15:29:19 »

Это вызвано существующим процессом, который отлажен и оптимизирован по Word документ.

Если менять на ПО без Word то нужен очень usabilyti интерфейс для stake holders.
Как я понимаю Rastional позволяет вести документ в word, а рулить требованиями в базе. Интересен аналогичный фукнционал но в другом ПО.

Ничего не понял. Опишите процесс полностью ... Confluence имеет очень юзабильный интерфейс.

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

Это не только на Ваш взгляд, но нет таких инструментов, кроме большой тройки (уже двойки). Или пытаться использовать несколько разнородных систем и скрещивать их как-то, либо использовать подход Wiki.

2924

Сообщество Аналитиков / Re: [Конференция] ИТ анализ и требования (подготовка)

« : 17 Июля 2008, 12:16:07 »

... а "общение" и все такое это только красивые слова, ибо при желании я могу сам пообщаться с тем же Хлебниковым и др. уважаемыми в сообществе людьми, кроме этого для общения есть и этот сайт ...
Альтернативный вариант, как раз связан с тем чтобы делать community, в частности аналитиков. Но для этого можно использовать и другой формат -- устраивать тематические встречи, как это было у нас. И когда какая-нибудь компания (тот же Люксофт) предоставляет помещение для этого. Правда лучше конечно иметь помещение где-нить ближе к центру :-). Бенефиты для "компании-спонсора помещения" очевидны -- возможность приобщить нахаляву своих аналитиков, чтобы они впитывали идеи, общались, росли, предлагали темы для обсуждения -- т.е. без необходимости вкладывать деньги в обучение своих сотрудников дать им возможность получать информацию. Тут уже коммерции несомненно меньше, и участие в таких ивентах я лично мог бы рассматривать просто как контрибуцию в развитие сообщества. Вот тут то более справедливы слова об "общении с коллегами" т т.п. ...

Мы все можем пообщаться с кем угодно и когда угодно, но можно ли это сделать в одном месте и в одно время - собрать профессионалов и уважаемых людей и устроить круглый стол или просто пообщаться в кулуарах?
Проведение встречь и семинаров - это неотъемлемая часть и бум это делать раз в месяц, но опять же на один семинар собрать 10 гуру, я думаю, не реально.
Конференция имеет совсем другой статус и проходит как правило 1 раз в год, будем стараться двигаться к идеалу, чтобы заинтересовать МНОГО интересных людей, но без Вашей поддержки это не получится.
Опять же в Америке конференция рассматривается просто как большая тусовка гуру по обмену опытом и зачастую бывает с фуршетом и многодневная.

... а организаторы хотят заработать. Платят за это участники :-). Отсюда явный интерЭс у докладчиков -- участвовать в тех ивенах которые принесут им больше дивидентов за счет целевой аудитории на которую он будет вещать. Т.о. докладчику лучше всего прилагать усилия чтобы попадать на c-level events, на котором будут присутствовать CIO, пусть даже небольших компаний, но люди которые принимают решения о том чтобы "купить услуги докладчика".

Но не могут на первую конференцию прийти сразу толпа CIO и это понятно. Вторая-третья конференция - вот это уже более реально. Будем работать с CIO целенаправлено.

Р.S. Интересно, сможете ли вы конкурировать с ТЕКАМА и CareerLab ...?

А мы пока с ними и не конкурируем, они свои ивенты проводят, а мы свои. В след. году нам уже будет легче.

2925

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 16 Июля 2008, 21:05:03 »

БТ - это некая общая формулировка. Под ней можно понимать Цели, БВИ, БП и т.д. или их комбинацию. Вигерс предлагает понимать под БТ - иерархию целей, что по моему наиболее правильно. RUP предлагает понимать под БТ - БВИ. И т.д.