Для того, чтобы люди находили счастье в своей работе, необходимы три условия:\r
работа должна быть им по силам, она не должна быть изнуряющей и ей обязательно\r
должен сопутствовать успех.\r
\r
/* (с) Дж. Рескин */\r
\r
\r
2 Varan: \r
Тов Р.К. Мартин в одной из своих книг определил несколько признаков плохого проекта.\r
...\r
Не даст ли кто оригинальных рекомендаций, как не сделать вонючий проект, а сделать нечто красивое? \r
\r
Позвольте внести терминологическую ясность, что следует различать и отделять такие понятия (объекты) как проект и система (ИС/ПО/сайт/БД, создаваемая или поддерживаемая). Если этого не делать, называя все "проектом", то это будет не обсуждение, а "каша". Например, ваши пп.1-6 (и, наверное, п.7) и все, что тут говорилось выше имеет отношение в основном к системе \r
\r
Ну ентот RUP в расчете на крупные которы. А меня в основном интересуют как маленький проектик (в котором 2-3 человека задействованы, не больше) красиво и качественно сделать, чтоб перед людями не стыдно было. \r
\r
А какой именно RUP имеется в виду? Если "урезанный"/редуцированный RUP, то он может быть использван в маленьком проекте с 1 человеком. Это уже обсуждалось в топике Подходы к проектированию системы.... Еще топики по теме:\r
\r
Раздвоение личности или "а сейчас-то что делать?\r
(бизнес-логика, объектный & реляционный подходы, методологии, ООП & ООАП лит-ра)\r

Есть ли у кого статистика скоко уходит времени на разработку "больших&q (стр.1-4)\r
(проекты, характеристики, затраты, sloc; роль аналитика, проектировщика, программиста)\r

Стоит ли убеждать заказчика?\r
(структурный и ООАП подходы, фазы, деятельности; лит-ра)\r
\r
\r
2 bas & All: \r
.. нет достаточной квалификации, нет возможности что-то приобрести(например всю линейку ALM Rational или др. фирм) \r
\r
Что-то все на IBM-Rational/Borland-Together зациклились... Других средств что ли нет? Например, начнем с того, что есть бесплатные + open source средства для AMDC (анализ, моделирование, проектирование, кодогенерация), т.е большая часть. Есть средства для AMDC (+NET/J2EE) + TM + PM недороже 200EUR, а также учитывая, что есть бесплатные или недорогие CVS средства, то это уже весь ALM. Причем упомянутые средства имеют открытый и хорошо документированный API (COM, VBScript, Java), т.е любой программист, знающий эти языки сможет написать плагин-аддон, если что-то не устраивает. Ну и какой теперь смысл в Rational или в Borland? Не вижу никакого смысла особенно для небольших компаний, к-рые не могут покупать XDE или Together за 10,000+EUR. Если есть вопросы и желание обсуждать эти альтернативные средства, то это лучше делать в топике Помогите выбрать CASE. Добро пожаловать :о)\r
\r
\r
2 gardenman: \r
На вскидку вопрос: у кого сколько времени занимает собственно проектирование (процентная доля) от всего процесса разработки? \r
\r
В топике Обсуждение и Вопросы по ОБЪЕКТНО-ОРИЕНТИРОВАННЫМ МЕТОДАМ (ООАП / OOAD) и UML я приводил типичные значения, к-рые уже пару лет, наверное, выдерживаются, т.е анализ-проектирование + вспомогательные деятельности точно:\r
\r

получение требований/ВИ и анализ с построением модели ВИ/анализа/GUI - 15-20% ¹⁾ \r

проектирование архитектуры с созданием модели проектирования/реализации - 15-20% ¹⁾ \r

реализация (программирование, создание контента и т.д) - 20-40% ¹⁾ \r

создание модели тестирования и тестирование - 1-5% ²⁾ \r

развертывание ("внедрение") - 5-10% ¹⁾ \r

DCT/CM, планирование и др.вспомогательные деятельности - 2-5% \r
\r
¹⁾ изменяется в зависимости от наличия опыта создания таких приложения,\r
разработки под платформу, уже имеющихся шаблонов и т.п,\r
²⁾ 1% - большую часть тестирования выполняет заказчик.\r
\r
Признаюсь честно: у меня на то, чтобы нарисовать структуру \r
таблиц+индексы+триггеры+процедуры - это примерно 70% времени \r
и трудностей от проекта. Остальные 30 -написание клиентского приложения \r
+ доводка/отладка. \r
\r
Вообще это зависит от используемого процесса, т.е нет смысла сравнивать временные затраты при некорректном, безсистемном или неавтоматизированном подходе с системным и автоматизированным подходом. Эти значения, например, для UP (ООАП) приведены в книге Крэга Лармана "Применение UML и шаблонов проектирования. (Введение в объектно-ориентированный анализ и проектирование)" – М.: «Вильямс», 2002. – 624 с. (ISBN 5-845-90250-9) или еще в Фатрелле, Шафере и др. Управление программными проектами. Достижение оптимального качества при минимуме затрат – М.: «Вильямс», 2003. – 1136 с. (ISBN 5-845-90413-7) Анализ показателей, поиск неэффективных или даже ненужных деятельностей, повышение эффективности своей работы - отдельная тема, относящаяся к управлению проектами и качеством процесса разработки

2 vdimas:
применение RUP ничего не гарантирует, это методология, а не готовое техническое решение.

Привет, vdimas! Конечно, не гарантирует, т.к я уже не первый раз цитирую это: "успех складывается из 3-х "П"-составляющих? Процесс (включает также средства), персонал (читай профессионализм) и проект (цели, внешняя среда). ..."

ну ка, знатоки RUP, давайте-ка попробуйте ответить на пункты автора топика:

Ответим, ответим. Только скоро уже будем справлять 30-летие ООАП, 40-летие ВИ и 50-летие ООП. Да, не зря в Америке программистам семинары по основам ООАП, шаблонам и УП(PM) читают, а потом они еще зачет сдают. В серьезных американских компаниях вроде ATT, Локхид или индийских компаниях уже давно обязательна сертификация по UML и ISO-IT. Россия c Украиной как всегда в заду тащятся, несмотря на то, что их закрома полны талантливыми программистами...

>1. Закрепощенность: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект ""Снежного комма"", затрагивающие другие компоненты системы.
проектирование только сверху вниз приводит к подобному эффекту быстрее всего

RUP не дает никаких рекомендаций относительно наиболее предпочтильного подхода к анализу-проектированию, т.е "снизу-вверх", "сверху-вниз", "из-середины". Одно из Правил: использовать инкрементный подход - ИС/БД не должна создаваться сразу и целиком, а частями или приращениями. Предпочтительнее всего, когда сначала реализуется т.н "ядро" - важнейшие ВИ/данные, а затем к ним приделывается все остальное.
Что же касается изменений, то в RUP нет такого понятия как "окончательные требования", а отсюда сам процесс, направляемый ВИ, а также его программные средства направлены и позволяют:

получать и централизованно управлять изменениями требований, т.е
  с минимумом затрат поддерживать ЖЦ требований "от рождения до смерти";


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


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

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

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

>3. Неподвижность:достаточно трудно разделить систему на компоненты, которые могли бы повторно использоваться в других системах
Для того, чтобы компоненты можно было использовать повторно, они должны быть заранее спроектированы с учетом последующего повторного использования. Обычно это означает дополнительные трудозатраты по реализации дополнительной функциональности сверх предписанной в рамках конкретной системы (иногда плюс 50%-100% работы, что окупается только в случае заведомого нацеливания на повторное применение).
Кстати, мне очень импонирует компонентный подход в разработке. К изолированному компоненту можно применять самостоятельно стоящий RUP, компонент необходимо разрабатывать вне рамок какой-то системы, а именно как самодостаточный имеющий простой интерфейс модуль .

Мне тоже импонирует компонентный подход, но затраты в "50%-100% сверху" - ведь не всю функциональность, к-рая может неожиданно или внезапно потребоваться в будущем можно предугадать, например, возможны изменения в бизнесе, при к-рых ГУИ может сильно измениться или вообще могут не понадобиться целые подсистемы (это, кстати, нормально и к этому надо быть готовым - тем более, что заказчик платит), т.е получается, что твоя функциональсть "сверху" - это потенциально работа впустую

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

Пример, к-рый ты привел funikovyuri добавлением функций/объектов в диалог - это можно сделать и по требованию заказчика-пользователя. При чем не ясно почему потребуется "время, сравнимое со временем первоначального написания оного". IMHO такие временные затраты - результат отсутствия или плохого управления изменениями и документирования проекта, т.е "влез в свою же программу спустя год, а там - черт ногу сломит"

>4. Вязкость:сделать что-то правильно намного сложнее, чем выполнить некорректные действия
В принципе, это последствия необходимости что-то постоянно менять после завершения разработки системы, постепенно можно прийти и к такому. Компонентный подход выручает и здесь.

Менять что-то после "создания системы" - это довольно естественно и не так затратно, если изменения требований автоматически отображаются во все артефакты, т.е после изменения требований разработчикам сразу ясно, ЧТО и ГДЕ нужно изменить. Так что компонентный подход никогда не заменит автоматизированный процесс, если ты это имел в виду :о)

>5. Неоправденная сложность: проект включает инфраструктуру, применение которой не влечет непостредственной выгоды
Можно поспорить, особенно если система заведомо спроектирована с учетом расширений и масштабирования. В какой-то момент эта сложность будет неправдана, но ситуация может поменяться и эта сложность всех спасет.

Согласен, т.к непонятно, что именно имеется в виду под "применение которой не влечет непостредственной выгоды"

>6. Неоправданные повторения: проект включает повторяющиеся структуры, которые могут унифицироваться с применение простой абстракции
Опять же, речь о том, чтобы не проектировать тупо сверху вниз, а создавать и нарабатывать библиотеки, типовые интерфейсы объектов и реализовать типовые операции в них. Далее при проектировании необходимо не столько разрабатывать каждую сущность с 0-ля и смотреть что получится, сколько смотреть - а что уже есть, и пытаться "подгонять" целевую систему под некоторые наработки. (почти всегда это идет на пользу любой прикладной системе)

Тут vdimas вне конкуренции как проектировщик. Теперь буду его цитировать... :о)

>7. Неопределенность : проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта."
Это зависит от организации и артефактов. Тут может помочь применение хоть какой-нибудь методологии или же просто здравого смысла.

Согласен, просто в дополнение: методология желательна, т.к ее достоинство не в том, что "она позволяет строить диаграммы", а в том, что это некий обоснованный, оптимальный и обкатанный "шаблон" процесса, применяемого для решения проблемы, т.е "вот для ЭТОГО - делай раз, делай два, делай... как положено, без вопросов и получишь хороший результат"

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

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

Стремиться к максимальной простоте на самом верхнем уровне (т.е. если по смыслу надо сделать A=B+C, то желательно, чтобы в коде именно так и было, а не нечто типа:
- заблокировать А, обработать ошибки
- заблокировать B, опять обработать ошибки

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

Кто-нибудь видел учетную систему, которую не пришлось бы ни разу
дополнить чем-нить? Или у всех их программы работают по 5-10 лет без единого исправления-дополнения?

Я видел. Не веришь? Представь, сделали и забыли! Правда, мужики, к-рые ее нам заказывали были из другого региона, т.е они ее забрали и мы больше в ней ничего не меняли... :о))


OFFTOPIC:
2 акуз-поклонник Репликанта:
а где Репликант?
я уже было приготовился этот топик до обеда читать, а после - осмысливать...

Привет, я заменяю Настоящего Репликанта. Кстати, он передает привет своим поклонникам и сообщает, что он в конец (или до конца) обленился и на работе его хватает только на то, чтобы делать необходимый минимум, лениво таскать Ж. в столовую и громить ламеров в Web-чатах, пугая их заумными словами типа "анализ", "проектирование", "компонент" ...