2 Репликант

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

автор писал:
выбор технологий (а я чем располагаю-то? ).
Всё это по кругу вплоть до "сходимости процесса".
По идее следует уточнить какой процесс имеется в виду
Процесс сбора требований. А ты что подумал? :)
В советской методологии разработки автоматизированных систем, этот этап называется постановка задачи . Именно на этом этапе большинство вопросов преходят из состояния "ЧТО" в состояние "КАК". В те счастливые времена ТЗ были именно тем, чем они должны быть, а именно ТЗ. Если в ТЗ не уточнены некоторые моменты, то именно потому что само это уточнение требует знания технологий (а это уже моя сторона). Вполне нормальной ситуацией было оправить ТЗ на доработку, приложив ворох технических замечаний. Автор топика будет отправлять это все самому себе, пока не утрясуться все детали и не будет четко представлено, КАК именно разрабатываемая система будет выполнять то, ЧТО от нее хотят.

Берем именно описанную ситуацию - есть конкретный человек (один) которому все это делать. И мы ему подсказываем, общий план его действий. У этого человека есть вполне конечный круг технологий которыми он располагает. В результате анализа предметной области, классификации требований он выбирает из тех технологий такие, которые помогут решить заданную задачу с максимальной эффективностью, (или, вообще, помогут решить как таковую :) )
Каждая технология имеет свои сильные и слабые стороны. Сопоставляя возможности выбранных технологий и требования (как явные, так и не явные) мы отчетливо видим, что некоторые вещи "как 2 пальца об асфальт", а некоторые явно займут приличное время. Более того, технологиям свойственно обладать ограничениями , которые вполне объективно могут противоречить входным требованиям (напр. заказчик хочет задействовать в системе имеющийся парк машин и сетевого оборудования и совершенно не собирается покупать именно под эту задачу сервак за $10 000, хотя под заявленное требуемое количество клиентских мест более уместен MS SQL Enterprise, но под него нет машины, а он работает похуже на однопроцессорных машинах, чем Standart Edition, но последний хуже переносит нагрузку одновременно большого числа подключенных клиентов, а выбрать придется именно ее. В этом случае стоит согласовать время отклика в системе. Или выбрать распределенную схему, но тогда убрать из требований пункт "сделать все в одном ящике, который я спрячу" и т.д.). Или наоборот, технологии могут иметь некоторые особенности-преимущества, рассказав о которых заказчику, мы можем напроситься на дополнительные требования/функциональность и дополнительный бюджет.

автор писал:То есть если брать те же UP/RUP, то технология выбирается к концу Начальной фазы, а не к концу 1-й, 2-й или NN-й деятельности анализа
кажется я сказал так: (а я чем располагаю-то? ).
т.е. Автор топика не располагает бесконечным множеством технологий, он располагает некоторыми, из которых ему придется выбирать наиболее подходящие. Вполне возможно пересечение требований и ограничений. см. предыдущий абзац.
В идеале - ты прав. Если есть возможность выбрать из ПРОИЗВОЛЬНОЙ технологии, то да. Но здесь - нет. Я же не советую ему как разрабатывать приложения в общем случае в условиях сильной и "разношерстной" команды. Мы советуем ОДНОМУ человеку, как ему вообще справиться со всем этим... Если не ошибаюсь, то вопрос стоит именно так, хоть автор этого и не озвучил.

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

Если брать процессы UP/RUP, то "рекурсивно", а точнее циклически или итеративно повторяются пп.1-6 и 8
Ну, не знаю насчет RUP, но я не приступлю к 3 и 4 ни-за-что , пока не разберусь окончательно с 1 и 2. Ибо это означет только одно - бардак в голове, нет четкого представления задачи. Неумение выбрать оптимальный путь. Перед началом работы работы над 3 и 4 я должен полностью "разложить по полочкам" свои знания о предметной области. Я крайне не люблю ситуаций, когда на этапе проектирования обнаруживается нехватка информации/требований.

Как по RUP - это все еще часть анализа, или уже проектирование??? :)
Или допустимо полуграмотное (с т.з. предметной области) проектирование?

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

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

автор писал:Конечно, если это все можно получить без БА, то насаждение БА "грубой силой" - это обычная медвежья услуга, например, с целью обычной наживы
Ну, это немного не то, на чем мне хотелось бы зарабатывать, просто жаль на это времени. Был бы счастлив всю жизнь получать очень внятные ТЗ. В крайнем случае изредка показывать, как его надо составлять, чтобы исполнитель был доволен.

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

автор писал:Т.е tygra высказал как бы для структурно-функционального подхода, а vdimas - как бы для ООАП, т.е все зависит от подходаМне довелось немало попроектировать с применением обоих подходов.
"Инкапсулированный" ООАП всегда дает много бонусов при разработке, и, чем сложнее система, тем больше бонусов:
(не из учебников, а только лишь из собственного опыта, сплошное IMHO)
- более разумная конечная архитектура и протоколы взаимодействия;
- сильная "системная" часть, сводящая имплементацию даже сложных вещей к тривиальнейшему занятию;
- независимость модулей, возможность безболезненного развития/масштабирования;
- более мелкое дробление сущностей (побочный эффект наследования при правильном проектировании), как следствие - управляемость кода;
- повышенние надежности, естественное изолирование и локализация источников "опасности".

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

tygra пишет клиент-серверные системы на Дельфи. ООП у него - только в GUI.
Большая часть остального приложения оперирует непосредственно рекордсетами. Так что неудивителен различный взгляд на эти вещи.

2 ЦК

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

Если у меня и есть толстые книги (600 и более стр), то это только объективно толстые справочники, (типа справочник администратора MS SQL, справочник по сетевым протоколам, и т.д.).

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

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