2 Mik Prokoshin: \r
Очень здравые мысли о коротких итерациях и рефакторинге. .... Абсолютный минус - "все отвечают за все". "Коллективной ответственности не бывает, бывает только коллективная безответственность" (С) не помню чье... \r
\r
Все верно. С одной стороный у XP есть достоинства, но очень много и недостатков , нек-рые из которых есть другая сторона этих самых достоинств:\r
\r
неполнота процесса (хотя и считается, что XP "покрывает" весь ЖЦ ПО)\r

неполнота артефактов/моделей (как следствие неполноты процесса)\r

безответственность участников \r

постоянное переписывание кода (рефакторинг) \r

высокие требования к участникам (знание предметной проблемы, универсальность)\r

ставка на человеческий фактор (работа в парне, коллективное владение артефактами)\r

активное участие заинтересованных лиц (stakeholders)\r
\r
XP не тянет на то, чтобы быть промышленной методологией. Это набор практик (best practices, practice-based methodology). Даже для маленькой команды или небольших проектов XP имеет явные недостатки по сравнению с тем же RUP/ICONIX (итеративные, инкрементные архитектурноцентрированные ООАП-ориентированные процессы). Недостатки XP уже обсуждалась в топике XP or ^XP?. Там также есть сравнение с RUP, MSF и несколько ссылок на ресурсы и форумы по XP\r
\r
RUP и MSF ориентированы на системы, где объем работы измеряется единицами и десятками человеко-лет, требуют значительных дополнительных затрат на "потенциальную" возможность длительного жизненного цикла, ориентированность на отрыв результатов от личности разработчика продукта, так что в наших условиях отсутствия крупных инвестирований в ИТ эти методологии весьма редко применимы в чистом виде. \r
\r
То, что полный RUP является достаточно насыщенным различными деятельностями, ролями и соответсвенно тяжелым для использования/внедрения - это факт. Но никто не мешает использовать урезанный/редуцированный (reduced) RUP, когда определенные дисциплины(деятельности) или даже фазы не используются. Сама Rational утверждает, что RUP может быть применим даже в очень маленьких проектах и очень маленькими командами (1 человек), и поверьте это действительно так. Использование RUP для маленькой команды уже обсуждалось в топике XP or ^XP?\r
\r
Как мне видится оптимальное ведение проекта : \r
Составление начального каркаса предметной модели аля MSF. \r
\r
Если под составлением "каркаса предметной модели" имеется в виду вообще концептуальная модель (т.е не только модель предметной области), то что из себя представляет эта модель и с помощью какого метода вы ее будете получать? И что значит "аля MSF"? См. мой пост ниже для 1024 - мне до сих пор неясно какой именно метод в MSF хотя бы предпочтительнее для анализа требований . В RUP - это OOA на основе вариантов использования (UC), а также допускается OOAS, т.е и частично структурный анализ\r
\r
Разбиение на подзадачи, составление обобщенного ТЗ. Разбиение подзадач на короткие "истории", составление ТЗ на кадую подзадачу (часто этот этап мы пропускаем, а потом жалеем :-) \r
\r
А что такое в вашем случае "подзадача" и как выделяются подзадачи?\r
\r
Кодирование историй, параллельное тестирование закодированного (аля модульные тесты), возможно с использованием формализованных тестов. \r
Объединение закодированных историй, тесты системных свойств. \r
\r
А где же проектирование? Т.е собираетесь кодировать прямо с ТЗ?\r
\r
На каждом этапе обязательно делается рефакторинг, выделяя общие моменты, упрощая систему и т.д. \r
\r
Т.е прямо на основе уточненных требований сразу изменяется код, т.е делается рефакторинг? ("выделяя общие моменты, упрощая систему" - это из XP?) Как я понимаю постоянный рефакторинг - есть следствие использование XP и отсутствие полноценного проектирования архитектуры\r
\r
Обязательным требованием для проектных решений является компромисс между функциональностью и гибкостью - т.е. вместо того, чтобы делать супер-жесткую логику, необходимо выделить некое количество потребностей, реализация которого не слишком будет мешать возможному изменению этих потребностей. IMHO вот это - самое сложное в проекте, это - искусство, еоторым владеет не каждый, а оценивается это, к сожалению, лишь по истечению некоторого количества времени ! \r
\r
Ну, это не самый сложный компромисс в проекте, если только этому не придавать слишком много значения. А с помощью какого метода собираетесь находить "компромисс между функциональностью и гибкостью"?\r
\r
\r
2 vdimas: \r
Хотя, ему достаточно сделать copy&paste из многих его предыдущих выступлений и оформлять в виде самодостаточных статей. \r
\r
Что это такое! Возмутительно, понмаешь! Возмущению нет предела уже. И не потому что копировать скоро устану, и не потому, что много копировать, а потому что если подумать, то это, понимаешь, работа в оправдание чужой лени! Нет, ладно поиск по сайту не работает, так еще в разделе по словам "RUP", "XP", "MSF" не могут топики найти, предпочитая каждый раз дискуссию по новой начинать. Не, ну вообще "опытные" пользователи форума SQL.RU... :о)\r
\r
Исходя из предметной области, из САМОЙ ОБЩЕЙ требуемой функциональности, способов доступа и производительности, определитесь сначала с САМОЙ ОБЩЕЙ структурой системы. (2, 3 или 4 очень больших блока). Не стесняйтесь вежливо "навязывать" заказчику общую структуру, даже если ему она видится по-другому. Вы - спецы, он (в большинстве случаев) - не очень. \r
\r
Вообще по своему опыту могу сказать, что больше половины заказчиков на архитектуру начхать. Можно, конечно, показывать свой профессионализм в том же ТЗ по ГОСТ 34.602, но все это бессмысленно. Таких волнует только функционал, надежность и удобства . Да, есть заказчики, к-рые не только заказывают платформу (программную, СУБД), просят расписать концептуальну модель, модель данных, подсистемы и т.д, но еще и язык программирования определяют. То есть не плохо бы уточнить, какой именно заказчик, ведь они все разные\r
\r
Еще ниже - тут как будет удобней. Можно начинать и XP, особенно в ситуации, если сам заказчик не в состоянии абсолютно точно сформулировать свои требования, или не имеет опыта ведения дел полностью в электронном виде. Можно, конечно, нанимать сверх-грамотных аналитиков, которые способны заглянуть в дебри сознания заказчика, но можно и XP. Делаем макеты с минимальной функциональностью, показываем заказчику, обсуждаем. Заставляем операторов пользоваться и следим за реакцией. \r
\r
Достаточно и одного аналитика и необязательно сверхграмотного. И потом кому нужно XP просто само по себе - пусть страдает с заказчиком/пользователем на пару, кстати, выполняя работу аналитика , но только не очень профессионально. И где здесь эффективность? Тем более если компания умеет быстро делать прототипы , то их можно отдать заказчику пусть он сам и его ответственные пользователи спокойно разберутся и все запишут. Придет аналитик и все с ними обсудит за один присест. Смысл-то вдвоем задницу просиживать, показывая пальцем. Не каждый заказчик может позволить ему советовать даже если он и сам неуверен . Может воспринять как навязывание ему точки зрения :о(\r
\r
\r
2 aag: \r
Репликант, суда по его выступлениям, совершенно однозначно ориентирован только на RUP. \r
\r
Да, но только я еще ориентирован на SAD/SASD, SADT и может даже ARIS и вообще на то, что объективно наилучшим образом подходит для решения конкретной задачи. Что же касается создания ПО "от и до", а не просто БД, то, конечно, урезанный RUP лучше всех. И дело тут не в каких-то симпатиях (процесс - это не GUI или компутерный гейм в конце концов, к-рых много не бывает), а просто по совокупности важнейших характеристик RUP лучше , чем что-либо. Но если завтра появится что-то лучшее, чем RUP, то что же - рассмотрим и если оно стоит того - примем в эксплуатацию :о)\r
\r
А вопрос-то действительно болезненный. В идеале хочется "скрестить коня и трепетную лань" (XP vs RUP), но, увы, "а вы друзья как ни садитесь..." \r
\r
А зачем это нужно скрещивать супер-экстра-пупер (RUP) с убожеством (XP)? К тому же в основном процессе RUP можно использовать какие-то практики XP, а также практики Agile Modeling (AM) \r
\r
Кстати - огромное значение еще имеет КАКОЙ проект ведется. Есть системы, будучи сделанными, далее относительно постоянны. А есть постоянно меняющиеся и сопровождаемые системы. \r
\r
С точки зрения полноты, согласованности и непротиворечивости полный или частично урезанный RUP именно как итеративный и инкрементный и т.д и т.п процесс вообще идеален. Что касается систем, к-рые потом почти не надо поддерживать, то и здесь без исключений - просто не используются соотвествующие дисциплины(деятельности)/средства для SCM/DCT\r
\r
\r
2 AISOFT: \r
По этапам: \r
1) Выявление требований; \r
2) Разработка ТЗ и согласование с заказчиком; \r
3) теперь можно выбирать ХР, RUP, MSF и т. д. Если коллектив имеет опыт работы и знание предметной области, то в большинстве случаев, это будет некий аналог XP. \r
\r
Как интересно у вас - для софтового проекта методология выбирается в зависимости от ТЗ/требований. Даже не от типа задачи (БД, ПО, КИС и т.д), а от требований. Т.е ваши заказчики обычно настаивают какую методологию должен применять исполнитель? А почему в большинстве случаев у вас выбирается некий аналог XP, т.е вы специализируетесь на только на каких-то определенных задачах, чтобы был опыт/знание предметной области?\r
\r
2 1024: \r
Практика показывает что MSF круче всех. \r
\r
А чья практика хоть? Очень интересно послушать. Я сейчас выступаю даже не с позиции разработчика, ежедневно использующего редуцированный RUP, а именно с позиции объективного исследователя и здравого смысла. Просто ради истины и чтобы гадкий утенок не стал вдруг эдаким белым лебедем. Вообще в мире MSF используется как правило компаниями, являющимися MSP/MSC, да и то не всеми . В мире всего порядка 200 сертифицированных специалистов по MSF, в СНГ - всего 6, в отличие от того же сложившегося сообщества разработчиков, использующих RUP ( RDN ). К сожалению какой-то публичной статистики насчет использования тех или иных софтовых методологий нет, а есть она на закрытом сайте IDC. Ссылку на единственную обзорную статью по методологиям производства ПО со статистикой, которую я помню на Interface.ru я посеял, но обязательно найду, а также выложу списки серьезных проектов, выполненных с помощью MSF и RUP.\r
Пока же попробуем хотя бы поверхностно сравнить MSF и RUP:\r
\r

У MSF в "фундаменте" не такая основательная ИТ-наука как у того же RUP,\r
к-рый благодаря присутствию таковой и является очень мощным ,\r
полноценным и в то же время гибким и настраиваемым \r
процессом, вобравшим в себя почти все самые последние достижения\r
как инженерного подхода, так и достоинства самых разных\r
OOА, OOП, SCM, QA и др. методов и моделей ЖЦ ПО.\r
MSF также использует последние достижения инженерии ПО, подходов\r
и моделей ЖЦ, но в ее основе совокупность лучших практик и общих \r
рассуждений типа "typically the better approach is to ..." .\r
MSF - это высокоуровневое описание процесса ("a high-level sequence\r
of activities") в виде инструкций типа "делай 1, делай 2, делай 3-а,\r
если X или делай 3-б, если Y", но вот почему надо именно ТАК не объясняется\r
и также не всегда объясняется когда можно делать сразу не 1, а 2 и что\r
при этом потеряется.\r
В той же официальной документации по MSF прямо не указываются какие-либо\r
авторитетные научные работы или ИТ-стандарты (де-факто, де-юре),\r
на к-рых базируется или к-рым соответствует MSF ((кроме британских\r
ITIL стандартов-рекомендаций (UK CCTA), традиционно славящихся своим\r
вечным отставанием от ИТ-прогресса. Не понятно почему Майкрософт\r
ориентировалась на какие-то импортные и не актуальные стандарты)).\r
Для использования именно MSF не достаточно только одной\r
документации по MSF, но также требуются общие/базовые знания\r
в области инженерии, ЖЦ ПО, а также конкретных методов/методологий\r
(например, ООАП/структурные), к-рые будут использоваться "внутри" MSF.\r
\r

Хотя MSF и позиционируется как "business value oriented/driven",\r
но в целом она является методологией создания ПО и не более \r
(если судить по тем деятельностям/дисциплинам, к-рые упоминаются\r
и обсуждаются в документации по MSF), в отличие от того же RUP,\r
к-рый уже является не только методологией создания ПО, но и давно\r
включает дисциплину (подпроцесс) бизнес-анализа , к-рый сам с его\r
артефактами/ролями достаточно подробно описан.\r
В XP or ^XP? я уже писал, что у MSF\r
нет нек-рых вспомогательных, но важных деятельностей в отличие\r
от RUP, у к-рого есть те же BA и SCM. То есть тот же SCM упоминается\r
рассказывается как работать с изменениями, но как именно его использовать\r
в тех или иных случаях (по шагам) не рассказывается, т.е, очевидно,\r
опять напрашивается решение типа внедрять чужие SCM процесс и средства\r
для него (например, от от Rational) в основной MSF-процесс компании.\r
\r

Ни Майкрософт, ни другая компания до сих пор не поставляет на рынок\r
программного фреймворка ( интегрированного набора средств)\r
для автоматизации MSF. Таким образом процесс MSF автоматизируется\r
разрозненными средствами и несвязанными документами в отличие от RUP.\r
Т.о разработчикам приходится использовать либо опять частичный фреймворк\r
от Rational (Rational Suite), либо друге фреймворки, например, с теми же\r
MS Visio, MS Project и т.д. Где смысл?\r
\r

Это, конечно, не достоинство само по себе, но RUP создавался монстрами\r
и признаными евангелистами ОО-подхода (Три амигос) на основе работ тех же\r
Йо(р)дана, Констайна и др., и он как революционный , так и отчасти\r
эволюционный "венец" творения методов разработки, что уже само\r
по себе доказывает некую зрелость RUP. А кто создавал MSF? Отдел MSF Майкрософт.\r
\r
Теперь выдержки из официального Microsoft Solutions Framework (Модель процессов MSF), вер. 3.1 (White Paper):\r
\r
Аннотация \r
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral) . Представляемая в данном документе последняя версия модели процессов MSF дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения , начиная с его отправной точки и заканчивая непосредственно внедрением . Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.\r
\r
Краткий обзор методологии \r
Стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустил в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт , разрабатывавших проекты на предприятиях заказчиков, и лучшем из того, что накопила на данный момент IT индустрия. Все это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).\r
\r
Далее идет описание принципов, фаз, деятельностей, моделей - "ядро" методологии, умещающиеся на 41 странице\r
\r
\r
\r
Все предельно ясно и на первый взгляд как бы даже здорово, но я предлагаю обсудить MSF (а также и MOF) более подробно, чтобы все еще больше разъяснилось. Итак? :о)

2 AISOFT:
После выяснения требований и определение ТЗ (не кидайте в меня эту штуку, речь идет о базовом функционале проекта) используя знания в предметной области (бухгалтерский, финансовый, складской учет) и опыт выполнения предыдущих проектов, я могу примерно определить необходимые ресурсы и сроки. ...

Возможно, но как именно это (знание требований, необходимых ресурсов и сроков) влияет на выбор методологии/процесса создания?

... После определения ресурсов и сроков я выберу и способ выполнения проекта, в большинстве случаев это некий аналог 'бригады главного программиста'. ...

Как я понимаю вы все-таки используете XP или его аналоги/вариации. Вопрос же был именно о выборе между XP, RUP и MSF

... Заказчики не имею отношения к этому. Насчет типа задачи, я специализируюсь на типе 'клиент-сервер' и стараюсь выбирать проекты связанные с предметной областью, которую я знаю.

Тогда понятно и в вашем случае, действительно, возможно использовать XP


2 Varan:
1. Тут дело, я думаю, не в лени. Одно дело - живое общение, совсем другое "поиск информации".

Да я просто возмутился, тем более что есть причина. Ни на что не претендую. И живое общение тут ни при чем. Можно общаться и при этом пользоваться поиском как с пользой для себя, так из уважения к другим, чтобы самому и другим не повторять то, что уже было написано и обсуждено

2. Не приходила ли Вам в голову мысль издать книжку по мотивам Ваших выступлений здесь? Во первых, вы правильно расставите акценты, во вторых - если сервер вдруг (не дай бог) накроется - самое важное будет на бумаге. Я бы такую книгу с удовольствием купил.

Я так понимаю, что это щютка? Если нет, то сообщаю, что многое из того, что я здесь высказываю можно прочитать в документации, книгах или статьях. Так что если кому-то очень хочется подарить миру такую книжку, то пусть набирает и издает ее сам. Я готов написать предисловие (короткое). Задаром :о)

2 Павел Воронцов:
... В результате был выработан свой собственный процесс со своим набором артефактов - облегченный вариант всё того же RUPа. Однако даже это работало плохо - мелкий заказчик с трудом переваривает, что ему надо сперва заплатить за взаимное понимание и написание множества документов.

Во-первых, какая разница мелкий заказчик или крупный? По идее не должно быть даже важно есть ли у него своя ИТ-служба/отдел со своей методологией (ее отсутствием).
Во-вторых, почему заказчик должен платить за, то что у вас, например, RUP или PMI? Вообще-то он платит за конечный (продукт, качество, сроки исполения) или промежуточный результат (документы типа ТЭО, ТЗ, отчеты и т.д) вашего процесса. Заказчик должен иметь и понимать необходимые ему документы независимо от процесса, к-рый вы используете. Причем здесь какие-то характерные для процесса внутренние артефакты, если вы это имели в виду?


2 AISOFT:
Так что при организации выполнения проекта я использую аналог бригады главного программиста, а не ХР.

Теперь понятно, что подход "бригада главного программиста" - это вообще не XP, а набор практик как из XP, так и не из XP

Вполне возможно, что если мне придется разрабатывать большой проект, в котором объем кода, будет под 1000000 строк, я использую RUP или MSF, но на малых и средних проектах мне это не надо.

А почему у вас выбор методологии зависит от определенного кол-ва строк кода?

2 Mik Prokoshin:
Что касается того, "как" делать анализ требований: IMHO все, что дает хоть MSF, хоть RUP есть лишь некие шаблоны, заполняет которые каждый аналитик сообразно своим возможностям, т.е. сам вид процесса - не панацея (особенно в данном случае, т.к. реально это "как" слабо формализуемо и в любом случае зависит от человека. Примерно, как дедуктивный метод Холмса в отрыве от его личности рассматривать :-).

У вас какое-то странное понимание сути методологий, в частности, тех же MSF/RUP. И дедуктивный метод Холмса тут ни причём. Холмс свой дедуктивный метод использовал для изобличения преступника через определение типа личности , наблюдая за поведением и выделяя существенные ее характеристики. В методе Холмса, действительно, есть сильная зависимость от особенностей конкретной личности, что закономерно, т.к предметом его метода является именно личность .
Цель же методологии создания ПО - это, в частности, повышение эффективности создания ПО через формализацию и исключение кустарного элемента, т.е зависимости от неординарных и творческих способностей человека.
Если в документации к RUP или MSF вы встретили термины "общий процесс", "каркас процесса", "набор шаблонов", то это еще не значит, что методология - это "лишь некие шаблоны" для заполнения или "вид процесса". Даже несмотря на то, что MSF гораздо более общая , чем RUP, но там есть определенная последовательность(и) определенных фаз/деятельностей для достижения вполне определеного результата(ов). Это и определяет MSF и RUP как методологии/процессы. Далее: вы говорите, что "заполняет которые каждый аналитик сообразно своим возможностям" - возможно это верно для MSF, но не для RUP, если под результатом "возможностей" понимать содержание артефактов . Не могут быть в RUP из-за возможностей аналитика, например, только функциональные требования без UC или модель информационных потоков вместо модели анализа потому что RUP предполагает ООАП, к-рый предполагает определенное содержание моделей.
Да, RUP и MSF не определяют абсолютно все "от и до", а особенно на стадии получения требований/UC, где благодаря тесной работе с людьми (заинтересованными лицами) элемент искусства проявляется больше, чем на любой другой стадии

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

Теперь ферштейн! Почему сплошной рефакторинг

Дело в том, что стандартная методология подразумевает жесткость требований к проекту. А я за десять лет практики такие "жесткие" проекты видел, только когда результат заказчику был "до фени".

А что значит "жесткость требований к проекту"?

XP (в нашей интерпретации :) просто подразумевает быструю обратную связь, т.е. много версий чуть-чуть измененных ТЗ на одну итерацию. Ускоряет в определенной степени процесс (никто не откладывает дела "до выяснения подробностей"). Что касается декларируемого в XP "постоянного наличия заказчика" - это перебор IMHO.

Согласен!

А что такое "сертифицированный специалист по MSF" ? Мне казалось, это лишь экзамен в рамках MCSD.

Что касается сертификации MSF Practitioner и ее экзамена 74-100 (информации очень мало!!) для нее, то они отличаются от сертификаций/экзаменов MCSD и MCAD по языкам/технологиями, к-рые посвящены именно языкам/технологиями и ориентированны именно на разработчиков (developers), а не на партнеров MS (partners) по решениям

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

Пожалуйста. Только я вообще говорил не про книжку, а именно про общность самой методологии MSF . Есть смысл ее хотя бы в руки брать? Т.е там есть какая-то полезная или "рзжеванная" информация, к-рой нет в оригинальных источниках на сайте MS? :о)

2 AISOFT:
1) Понятие 'бригада главного программиста' появилось намного раньше, чем понятие ХР.

А я и не говорил, что позже. Прародителю 'бригады главного программиста' - понятию "бригада главного мастера" уже, наверное, 2000 лет, если не больше :о)

2) У меня выбор способа организации выполнения проекта зависит от размера проекта, а кол-во строк кода, просто, является косвенным показателем размера проекта.

У вас есть реальный опыт использования RUP (урезанного) или MSF?

3) В программировании, как и во всем другом, результат всегда будет зависеть от 'кустарного элемента, т. е зависимости от неординарных и творческих способностей человека.'

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

У меня складывается впечатление, что у Вас, много теоретических знаний, но опыт выполнения реальных проектов достаточно мал.

А почему у вас складывается такое впечатление? И что значит "достаточно мал"? Год, два, три или 5, 10, 50 проектов? У меня опыт разработки коммерческих проектов в частности по созданию софта - с 1996 г., с использованием структурных методов SASD (приложение, а не только БД) - примерно c 1998 г., с реальным и повседневным использованием RUP (урезанного) - с 2000 г. Это просто стаж, а сделанные проекты надо считать и рассказывать про их сложность


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

Ну, а смысл-то тогда создавать эти документы для заказчика и еще раздражать его, показывая ему их? Мы, например, вообще для заказчика создаем только те документы, к-рые ему самому нужны и указаны в договоре с ним. Если в порядке развития проекта, то, как правило, это - ТЭО, требования/UC, модель пользовательского интерфейса, ТЗ и ТП по ГОСТу, отчеты. Характерная ориентированность на ГОСТ, а не на RUP сразу видна

... Дело не в наличии IT отделов у заказчика, а в непонимании им процесса как такового.

А где вы прочитали или почему вы считаете, что он должен или обязан понимать ваш процесс? Он имеет право поинтересоваться, что за процесс/методологию вы используете или потребовать, чтобы артефакты (модели, документы и т.д) удовлетворяли определенным требованиям (вот это, возможно, за плату!)

.. Он приходит часто и говорит - я хочу щастья и готов выложить за него (допустим) 3 штуки баксов. Пока выясняется в чём щастье (пишется SDP, SAD и ещё кучка документов) заказчик говорит - не, ребята, чо-то это долго всё, идите на ххх .....

Обычный и вполне нормальный заказчик :о)

.. И получается что нас кинули. А какой-нибудь фрилансер или XP команда это самое щастье в каком-то виде за эти самые 3 штуки с удовольствием сделает.

Извините, Павел, но похоже, что вы сами себя "кинули" или вас кинул тот, кто "внедрял и настраивал" RUP в вашей компании. Может он считал, что RUP существует не для того, чтобы приносить пользу участникам проекта, делая работу эффективнее, а для того, чтобы "выпендриваться" перед заказчиком? Действительно, loose story о применении неправильного понимания RUP на коротких и мелких проектах...

По мотивам топика Стоит ли убеждать заказчика? ...\r
\r
2 vdimas: \r
Нет, это деятельность, возникающая как "побочный эффект" на этапе анализа. Именно, в процессе вникания в сущность предметной области (в нашем случае - в пресловутые бизнес-процессы), и упорядочивания, классификации, обощения и т.д., т.е., по мере накопления знаний о предметной области, неизбежно возникают уточняющие вопросы. Т.е. должно происходить пополнение и уточнение требований. \r
\r
То есть самого анализа либо нет, либо ты его целиком упомянул под "2. анализ,", но вот что именно под этим имеется в виду?\r
\r
Процесс сбора требований. А ты что подумал? :) \r
\r
Я имел в виду процесс, к-рый у тебя описан в пп.1-5, а также 7 и 8, а не только п.1 :о)\r
\r
В советской методологии разработки автоматизированных систем, этот этап называется постановка задачи. Именно на этом этапе большинство вопросов преходят из состояния "ЧТО" в состояние "КАК". В те счастливые времена ТЗ были именно тем, чем они должны быть, а именно ТЗ. ... \r
\r
Следует ли из твоего исторического экскурса в счастливые времена, что на практике ты используешь деятельности и "артефакты" (пункты) из ГОСТ 34.601 и 34.602 или ГОСТ 19.ххх как некий "каркас" процесса для ОО-разработки? Просто в к слову: в RUP подобная деятельность также называется "Requirements" или в переводе "Требования" ("Получение требований")\r
\r
т.е. Автор топика не располагает бесконечным множеством технологий, он располагает некоторыми, из которых ему придется выбирать наиболее подходящие. \r
\r
Согласен в случае автора топика. Это ты своим постом меня "сбаломутил" насчет выбора технологий :о)\r
\r
Ну, не знаю насчет RUP, но я не приступлю к 3 и 4 ни-за-что, пока не разберусь окончательно с 1 и 2. Ибо это означет только одно - бардак в голове, нет четкого представления задачи. Неумение выбрать оптимальный путь. Перед началом работы работы над 3 и 4 я должен полностью "разложить по полочкам" свои знания о предметной области. Я крайне не люблю ситуаций, когда на этапе проектирования обнаруживается нехватка информации/требований \r
\r
Ясно, т.е ты используешь последовательный подход на протяжении пп.1-4\r
\r
Как по RUP - это все еще часть анализа, или уже проектирование??? :) \r
Или допустимо полуграмотное (с т.з. предметной области) проектирование? \r
\r
Во-первых, что значит полуграмотное? Ты знаешь, что RUP - итеративный процесс, т.е проектирование там ведется, когда получено примерно 10% ВИ и существенные требования причем без подробной детализации. Во-вторых, деятельность анализа является необязательной , но желательной , т.к она по сути дает концептуальную модель системы без привязки к каким-либо технологиям (в RUP основные понятия это объекты BCE: сущность (entity), пограничный (boundary) и управляющий (control) классы), т.е позволяет "представить" работу системы, используя такие понятия как пользовательский интерфейс, хранилище данных и т.д. Ты прав насчет проектирования и в RUP, а также и в UP (см. того же Лармана) эта деятельность относится больше к проектированию - Analysis & design , к-рая выполняется проектировщиком (System designer). Кстати, часто возникает путаница, связанная с тем, что одни под результатом анализа понимают модель предметной области (как в твоем случае?), а другие - модель анализа \r
\r
Ты не обратил внимание на то, что я применяю слово КАК. И могу в очередной раз подписаться под тем, что сказал, так же как в равной степени и под твоим ЧТО, т.к. ни возражений ни противоречий не вижу. \r
\r
Ты прямо манъяк ответственности. Я не говорил, что то, что ты делаешь в корне неправильно. Я лишь сказал, что БА и нужен как раз для того, чтобы лучше понять ЧТО будет делать система, т.е это исследование БП "не в глубь, а вширь" (с)Г.Буч\r
\r
А что, заказчик только вчера родился? И он ни дня не проработал? У него уже наверняка есть некая учетная система, может быть даже ручная. Весь его учет именно так и работает - получает одни данные, обрабатывает их, и выдает другие. \r
Это не моя система - "черный ящик". Это его система для меня должна быть "черный ящик". ... \r
\r
Ясно, т.е ты воздействуешь именно через данные. И по идее неважно какая у твоего заказчика система (БП его компании, неавтоматизированные или авторматизированные какой-то уже существующей ИС) - это для тебя ЧЯ и ты не перестраиваешь его БП напрямую\r
\r
из минусов: \r
- неудачно спроектированная система "лечению" не подлежит, только на помойку; \r
\r
Позволь немного уточнить: вообще зависит от того насколько ("вширь") она неудачно спроектирована, т.е если почти все неудачно, то - да, проще спроектировать заново. Если же только какие-то подсистемы/компоненты, у к-рых были правильно описано внешнее поведение и определены интерфейсы, но оказались неудачные "внутренности", то можно переделать и "внутренности"

По мотивам топика Похоже что без совета профессионалов мне не обойтись ! ...

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

"процесс целиком" - имеется в виду как функционирует ваша ИС или БП (бизнес-процессы) вашего предприятия?

Судя по всему необходим переход на CASE средства, да еще неплохо бы разбить всю систему на модули, ..

Т.к ваша ИС уже существует, то тут возникают 3 задачи/вопроса: 1) выбор подхода в проектировании, например, ООАП внутри методологии типа XP, RUP или другой (как внедрять см.ниже); 2) выбор шаблонов проектирования, к-рые помогут грамотно сделать разбиение, в контексте подхода; 3) вносить ли изменения в архитектуру или описать как есть? - т.к разбиение, к-рое есть (на бумаге или в головах), например, на основе пользовательских или системных функций верхнего уровня может оказаться неправильным с т.з, например, шаблонов

.. Вот с самого начала надо было проектировать с помощью CASE.

Да, лучше было бы с самого начала использовать средства автоматизации процесса разработки, т.е не только CASE, но и RM (управление требованиями), DCT/CM (управление изменениями/конфигурацией), средства тестирования, планирования и т.п, но лучше поздно, чем никогда :о)

Так что мне нужен совет по использованию Case, точнее не самих стредств (у меня есть компашка с PowerDesigner, и по пользованию продуктом там помощи хватит на месяц чтения) а по методологиям. Я перечитал, десятки страниц на этом форуме и совсем запутался в методологиях анализа и проектирования. Их такое количество. С чего посоветуете начать ?

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

1. создание списка проблем (лучше с конкретными примерами и действующими лицами);
2. знакомство руководства с этим списком, обсуждение его с руководством и получения
  от него согласия на принятие мер как следствие признания наличия этих проблем;
3. собственными силами и/или с помощью сторонних специалистов:
  3.1. обзор возможностей методологий/средств для решения ваших проблем, создание отчета
    для руководства;
  3.2. оценка затрат (финансовых, временных и т.д) внедрения перспективных вариантов
    методологий/средств;
  3.3. обсуждение с руководством и выбор наилучшего для вас варианта;
  3.4. составление плана внедрения для выбранного варианта;
  3.5. внедрение методологии/средств, включая обучение ваших разработчиков.....

.. 1. Вообще-то я уже читаю про SADT ("Методология структурного анализа и проектирования", Дэвид А. Марка и Клемент МакГоуэн),

Это замечательная книга не только для знакомства с ФСП (функционально-структурный подход), т.е must read не только для тех, кто занимается бизнес-анализом, но и ИТ, т.к там есть то, что используется всеми аналитиками, не зависимо от их специализации, т.е работа аналитика с предметным экспертом/источниками информации, цикл опрос-моделирование-верификация. Другой вопрос - использовать ли IDEF0/3 для моделей автоматизируемых БП вашего предприятия? (Если у вас возникнет желание обсудить SADT, IDEF0/3, то предлагаю это делать в топике моделирование бизнес процессов. Кто что использует ?)

.. насколько я понял одна из ветвей этой технологии idef0/3 (есть и 1 и 4), столь
часто вспоминаемые здесь;

IDEF0/3 - это методы и нотации (т.е если в масштабе SADT - это лишь diagramming/modeling method & modeling language), предназначенные для "рисования", чтения и сопровождения моделей, а SADT - это именно методология (согласно ее автору - Д.Россу), использующая IDEF0 (см.книгу Марки-МакГоуэна), т.е процесс "ОТ" (обследование системы) и "ДО" (утверждение модели системы). Де-факто с ней используются IDEF3 + DFD, например, в популярном для БА средстве Bpwin

IDEF0 Method Report (p.7)
IDEF0 (Integration DEFinition language 0) is based on SADT (Structured Analysis and
Design Technique), developed by Douglas T. Ross and SofTech, Inc. In its original form,
IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a
description of a comprehensive methodology for developing models.
IDEF0 may be used to model a wide variety of automated and non-automated systems. For new
systems, IDEF0 may be used first to define the requirements and specify the functions, and then
to design an implementation that meets the requirements and performs the functions. For
existing systems, IDEF0 can be used to analyze the functions the system performs and to record
the mechanisms (means) by which these are done.
The result of applying IDEF0 to a system is a model that consists of a hierarchical series of
diagrams, text, and glossary cross-referenced to each other. The two primary modeling
components are functions (represented on a diagram by boxes) and the data and objects that
inter-relate those functions (represented by arrows).
.........
In addition to definition of the IDEF0 language, the IDEF0 methodology also prescribes
procedures and techniques for developing and interpreting models, including ones for data
gathering, diagram construction, review cycles and documentation. Materials related solely to
modeling procedures are presented in the informative annexes of this document.

Однако в этой спецификации то, что есть в SADT не относящегося к моделированию, т.е суть работы аналитика, парадигма ФСП, работа с экспертом/источником данных, организация репозитория моделей и т.п затронуты очень поверхностно (буквально по одной странице): "B.2 Author\'s Guide to Creating IDEF0 Diagrams" "B.3 Data Collection for IDEF Modeling", "C.1 IDEF Teamwork Discipline", "C.2.2 Guidelines for Authors and Readers and Commenters"

IDEF3 Method Report (p.15)
The IDEF3 Process Description Capture Method was created specifically to capture
descriptions of sequences of activities. The primary goal of IDEF3 is to provide a
structured method by which a domain expert can express knowledge about the operation
of a particular system or organization. Knowledge acquisition is enabled by direct
capture of assertions about real-world processes and events in a form that is most natural
for capture. This includes the capture of assertions about the objects that participate in
the process, assertions about supporting objects, and the precedence and causality
relations between processes and events in the environment.

Вообще если отбросить все что относится именно к нотации IDEF0, то ничто не мешает использовать с SADT другие функционально-структурные/процессные нотации, например, FH/EPC (ARIS) или BPMN (PowerDesigner), в к-рых "поддерживаются" иерархия функций, потоки и т.д

2. DFD - диаграммы потоков данных - документации пока нет (если можно советуйте
документацию и книги опубликованные в сети, книги покупать нет возможности);

Вопрос - нужна ли вам DFD?

3. UML - это униф. язык моделирования, если не ошибаюсь используется при проектировании
ООП. Видел много ссылок в сети.

UML используется не только при создании ИС/ПО, но также и для моделирования самых разнообразных систем, например, от технических до абстрактных

4. ERD - диаграмма "сущность-обьект" - пока документации видел немного на citforum
(если можете помогите ссылками)

Хотя ERD исторически возникла и использовалась в конктексте структурных методологий вроде SDLC/SASD(SAD), но она по прежнему очень популярна в силу своих достоинств и исправно служит (часто вместе с UML), не смотря на все нарастающую популярность UML и его расширений (profile) для моделирования данных

5. и дальше больше: RUP (насколько понял только для Rose, изобрели свой диалект схем ?),
и в POwerDesiner-e - BPM (bisness), CDM (conceptual), OOM (object oriented, это что UML ?), PDM (physical).

RUP - это методология/процесс разработки (см.ссылки выше), использующий UML для моделирования. Авторами RUP не запрещается, а многими командами и используется ER нотации (IE, IDEF1X). BPM,..,PDM - это виды моделей/нотаций в PD, к-рые можно создавать в контексте вашей методологии вроде XP, RUP, ICONIX и т.п.

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

Посоветовать можно, но я бы на вашем месте определился с пп.1-3, к-рые выше, т.к тогда, возможно, придется тратить меньше драгоценных сил, изучая что-то уже конкретное, а не все методологии, нотации и т.д :о)

З.Ы. На всякий случай ниже нек-рые топики, где также обсуждались затронутые вами темы. Удачи! :о)

----------------------------------------------------------------------------

-- методологии/процессы и подходы:

Структура ПО
  - простой процесс проектирования (GUI, OO, RDB) ;ссылки на лит-ру (!!) и примеры

Раздвоение личности или "а сейчас-то что делать?"
  - подходы: OOAD vs SASD, OO vs R; что такое бизнес-логика; OOAD лит-ра (!!)

Стоит ли убеждать заказчика?
  - RUP, структурный подход, фазы и деятельности; список лит-ры

Практический план проектирования БД
  - структурные подходы SASD/SDLC при создании БД; SASD/ERD лит-ра (!!)

Как не сделать "вонючий" проект?
  - проекты без методологий, подходы в проектировании, компоненты, модели/диаграммы, RUP, системные возможности "про запас"

Обсуждение и Вопросы по ОБЪЕКТНО-ОРИЕНТИРОВАННЫМ МЕТОДАМ (ООАП / OOAD) и UML
  - модели вариантов использования (UC), функциональные (IDEF0), GUI; затраты на стадии (анализ, проектирование,..)

-- нотации, модели, CASE средства:


моделирование бизнес процессов. Кто что использует ?
  - модели БП, нотации IDEF0, BPMN; CASE-средства и их возможности ;ссылки на спецификации IDEF и BPMN

Помогите выбрать CASE
  - сравнение возможнсотей: ErWin, PowerDesigner, Visio, ER/Studio; UML и ERD

КАК??? блок-схема алгоритма работы событийно-управляемой программы, причем с MDI интерфейсом?
  - UML, SAD, SADT; IDEF, DFD, ERD ;ссылки

Есть ли стандарты на описание предметной области?
  - IDEF0/3, DFD; UML vs ER нотации для моделирования данных

physical design и logical design
  - CDM, LDM, PDM модели данных

-- документация, правила именования:


Этапы проекта: ТЗ
  - ТЗ на создание БД/ПО; пример ТЗ на создание ИС "Учет движения товаров"

Нужна помощь по документированию проекта!
  - ТЗ на создание БД/ПО, ГОСТ 34.602, артефакты RUP, SASD

Как лучше организовать?
  - ТЗ на создание БД/ПО, ГОСТ 34.602

ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ (ТЭО,ТЗ,ТП,..): содержание, методы и средства
  - модели, программные комментарии, документация, ее объем ;ссылки на примеры

Обмен информацией между 2 людьми при совместной работе над проектом БД
  - документирование проекта, модели; CASE-средства и их возможности

Кимбл
  - правила именования

Всем привет! А топик-то снова ожил. Та-а-ак... :о)

2 Recmaster:
1. В данном контексте MSF нельзя сравнивать ни с чем из выше приведенных.
Это методология разработки, ведения и поддержки ПРОЕКТА.

Вы не путаете проект и ЖЦ системы? RUP и XP являются методологиями разработки системы (важнейшая часть ЖЦ системы), а также содержат деятельности по управлению проектом: "Project Management" в RUP и "Planning game/scheduling" в XP, если вы это имели в виду

.. Его можно сравнивать например с PMI(Project Management Institute). ..

Если вы имеете в виду методологию управления проектами (УП) как, например, PMBOK, то в MSF нет никакой методологии УП, т.к она использует "сторонние" знания и методы УП (например, структуру разбиения работ (WBS) и т.п). В MSF есть принципы, назначение и общее описание управленческих ролей и деятельностей по УП, также кратко описаны другие методы, относящиеся к анализу и управлению стоимостью и т.д, а также шаблоны - Дисциплина управления проектами MSF, версия 1.1


Если сравнивать, например, с RUP, то в его документации есть не только это, но также более детальное описание деятельностей по УП, описание артефактов УП (включая шаблоны и примеры), статьи со ссылками на стандарты и источники по УП

.. Это НЕ программирование, это ближе к абстракции ведения проекта, что ближе к управленческой части проекта, чем к программной составляющей. Это ведение проекта со спецификой и рисками IT разработок.

Любая другая методология разработки ИС/ПО как, например, RUP, где есть учет и принятие решений на основе рисков - это тоже не программирование :о)

2. Все остальное по большому делится на ДВЕ части:
2.1 ФУНКЦИОНАЛЬНАЯ модель программирования. Она базируется на принципе манипуляции функциями и безликими данными. Все делится на две части: функции и данные. К ним относятся: SADT(тоже IDEFx), ER моделирование.
2.2 Модель ООП(Объектно ориентированное программирование).Это по большому тоже 2.1, только в ней наблюдаются связь между функцией и данными на некоемом уровне абстрагирования. (RUP и прочее)

ФСП в анализе/моделировании (например, методы IDEF0/3), концептуальные или физические модели данных, функциональное программирование (например, UDF/SP в СУБД) могут быть использованы в XP, RUP, MSF, DSDM и т.п. ОО модели и ООП также используются в этих методологиях. В этом топике обсуждались именно методологии/процессы разработки и их различия, а не подходы в программировании - это лишь одна из деятельностей в процессе разработки

XP(экстремальное программирование, если я правильно понимаю) - это в данном разделении нечто среднее. Не рыба-не мясо.

XP неплохая agile-методология, доказавшая свою жизнеспособность в серьезных проектах по созданию КИС на таких предприятиях как Crysler, BMW и др. Следует сказать, что практики из XP (например, ПП, коллективное владение кодом) могут с успехом использованы в других методологиях

.. По классификации MSF это относится к спиральным проектам.Т.е. они изначально рассчитаны для быстрых решений, которые не будут развиваться.

Системы, созданные с помощью XP, точно также развиваются постоянно (US, рефакторинг, тестирование, релизы) и ЖЦ системы заканчивается только с ее смертью. Текущий проект и его методология относятся не ко всему ЖЦ системы (например, для ИС предприятия - это 1-5 лет обычно), а к отдельным этапам ЖЦ, например, создание системы (с внедрением или без), сопровождение/поддержка и т.д

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

Если имеются в виду отсутствие "постоянного" дизайна системы или требований в XP, то это затрагивалось выше, но здесь есть решение, например, для разработчика в проекте с жестким бюджетом/сроками - "билль о правах", т.е определенная договоренность с заказчиком, когда и на каких требованиях остановиться. "использовать только свой опыт разработчика" - вы читали документацию или какую-нибудь книгу по XP? а) в XP точно также могут быть использованы и используются шаблоны проектирования/программирования и компонентный подход как и в любой другой методологии; б) наврядли компании часто меняют методологию разработки в целом (XP -> MSF и т.п) - это требует немалых затрат даже для 1 проекта. Разработчики, по-настоящему использовавшие XP (ПП, TDD, рефакторинг) довольно легко "интегрируются" в команды, по-настоящему использующие XP; в) если случится замена одной XP-команды на другую, то есть условия для передачи проекта, вытекающие из грамотного применения XP: проектная документация (метафоры, US, карты, UML/ER диаграммы и т.п), комментированный код, документация пользователя системы и т.п


2 Mik Prokoshin:
Насчет XP - как раз ситуация с точностью до наоборот ! Он ориентирован именно на динамически развивающиеся проекты. Его можно использовать и при полностью определенном ТЗ, применяя только к кодированию, но более ощутима выгода именно тогда, когда начиная проект, можешь только догадываться - что тебя ждет впереди.

Откуда такая информация/мнение? XP в отличие от формального RUP работает без всяких спецификаций требований (видение, UCS, SRS и т.п) или в условиях когда требования не определены, т.к в XP: а) постоянно присутствующий заказчик-пользователь (on-site customer), б) быстрое прототипирование и дизайн (если использовать терминологию RUP)