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

×


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

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


Сообщения - bas

2911
Sparx / Re: Контекстная диаграмма в ЕА
« : 21 Июля 2008, 16:18:39 »
Эд, пошли мне я вложу

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

2913
Sparx / Re: Контекстная диаграмма в ЕА
« : 21 Июля 2008, 15:34:17 »
Просто мало кто ходит через главный вход.
А очень зря, я новости интересные там публикую :)

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

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

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

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

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

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

2917
Sparx / Re: Контекстная диаграмма в ЕА
« : 20 Июля 2008, 23:58:19 »
Эд, м.б. выложить тогда в файловый архив эту книгу.

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

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

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

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

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


2921
Sparx / Re: Контекстная диаграмма в ЕА
« : 18 Июля 2008, 12:37:22 »
По Д1 - Вы смешиваете бизнес и ИС, а  этого нельзя делать. Либо показываем бизнес (и пофиг как данные передаются, хоть 1000 негров бегают), либо показывает компоненты ИС.
По Д2 - Вообще не понял что за штуки Вы нарисовали. Нотации ка раз и придуманы для того, чтобы общаться а одном языке всем и не надо ничего своего привносить в них (либо по минимуму), а то Вам каждый раз придется заново всем объяснять что же данной закорючкой Вы имели ввиду.

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

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

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

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

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

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

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

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