ГОСТ и RUP. Что доблестнее для души?

Если бы... Такой бред приносят. Создается впечатление, что предпроектное обследование проводится заочно.

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

Дык значит не выдали тетеньки военну тайну перед увольненьем. Вот она сила ползучего саботажа: разработчики то поди и все инструкции просморели и все формы собрали и даже за спиной у тетеньки пару дней посидели... А каменный цветок таки не вышел.

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

Никогда. Вспомните историю. Луддитов, к примеру.
Внедрение систем чаще всего грозит пользователем сокращением штатов. В сокращении штатов (внедрению систем) заинтересован работодатель, с целью снижения издержек, а конечному пользователю не хочется терять работу. Посмотрите, что в Европе творится - автогиганты, работая по RUP и СМК, десятками тысяч сокращают работников.

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

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

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

Никогда. Вспомните историю. Луддитов, к примеру.
Внедрение систем чаще всего грозит пользователем сокращением штатов. В сокращении штатов (внедрению систем) заинтересован работодатель, с целью снижения издержек, а конечному пользователю не хочется терять работу. Посмотрите, что в Европе творится - автогиганты, работая по RUP и СМК, десятками тысяч сокращают работников.

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

В ходе дискуссии не стоит "пылить" См. ГОСТ 34.003 - http://ergd.ru/node/85

Сорри, ссылки потерял в пылу дискусии ... можно повторить link написать еще разок? Напомню, интересует определения функций и процедур, и если можно еще и определения "цель" и "задача" по ГОСТ ...
премного благодарен.

Никогда. Вспомните историю. Луддитов, к примеру.
Внедрение систем чаще всего грозит пользователем сокращением штатов. В сокращении штатов (внедрению систем) заинтересован работодатель, с целью снижения издержек, а конечному пользователю не хочется терять работу. Посмотрите, что в Европе творится - автогиганты, работая по RUP и СМК, десятками тысяч сокращают работников.

Это показатель, характеризующий степень завершенности системы по составу функций. Если СУБД, к примеру, не дает возможность удалять записи из БД, СУБД можно считать функционально неполной.

Смотрите ГОСТ, там все есть. Ну че я перевирать формулировки буду? Ссылки на ГОСТы вам дал.

Тоже не встречал. Раз нет, значит, скорее всего, это излишество.

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

Что такое функциональная полнота?

Никакой разницы. Просто требования к функциям звучит прозрачнее.
Ссылки на ГОСТ лежат в разделе Ресурсы форума.

А все-таки определения можно?

Тоже не встречал. Раз нет, значит, скорее всего, это излишество.

А кто запрещает? Глоссарий не предусмотрен, предусмотрен список теримнов и определений. Ради бога, вставляйте глоссарий.
А ссылка интересная, ЧТЗ писали как раз по ГОСТ 34.602-89, видно сразу. Надо подробнее изучить.

Вы не поняли. Речь шла о применении общероссийских классификаторов типа ОКП, ОКПО, ОКАТО, ИНН в конце концов.
Каждое требование по ГОСТ может также быть идентифицировано по степени автоматизации, функциональной полноте, надежности, защищенности и т.д. Например, Па1 соответствует функции синхронизации времени - некий показатель степени автоматизации.

Никакой разницы. Просто требования к функциям звучит прозрачнее.
Ссылки на ГОСТ лежат в разделе Ресурсы форума.

Я уже говорил, что в ГОСТ я не увидел взгляда со тороны пользователя и его целей (возможно это в ГОСТ называется задачами???, почему и прошу определения) на систему. Не увидил требований к системе в контексте использования пользователем системы. Чего хочет достичь пользователь при работе с системой .. каковы его цели, и что он делает, чтобы их достичь? Допускаю, что аналогом буржуйского "goal" может быть ГОСТовское "задачи" ... очень хочу это прояснить для себя.

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

Документация как раз должна содержать список сообщений, названий контролов и т.п. Это имеется ввиду под "Лингвистическое обеспечение" или что-то другое? Я нашел вот такое определние: "Лингвистическое обеспечение автоматизированной системы - совокупность языковых средств, используемых в автоматизированных системах, а также правил формализации естественного языка в целях повышения эффективности машинной обработки информации". И что это такое, как ни в т.ч. названия контролов и т.п. (например см. http://www.mineconom.ru/Section_dep/Dep_7/Page_Dep_7_3_21.htm#A4_3_3) ... а это может и должно быть отражено в документации пользователя. А в требованиях мы фиксируем этот факт -- наличия соответствующей доки ? И почему это Глоссарий тут не поможет нам?

Ух ты! А в ваших банковских софтинах разве не используется, к примеру, Общероссийский классификатор предприятий? Или вы сами присваиваете ID каждой российской конторе

Опять 25 ... я не про ID в таблице БД или в классификаторе ... а про ID требования -- ограничения проектирования, которое например может быть DC1, DC2, ...DC11!!!! Просто каждое требование должно иметь свой уникальный ID по буржуйским правилам ....

Я сам вообщето в банке работаю ...

Именно для этого я и попросил вас привести определения функций изадач!!!!! Я тоже хочу это понять ....

просто какой-то разговор глухого со слепым получается .

Сами просили, чтобы без ГОСТ. Ну, раз не устраивает, просвещаю. ГОСТ 34.003-90, пп. 1.3 и 1.4, но где-то уже писал, что формулировку п. 1.3 считаю в корне неверной.

Вот я же вам не разу не предложил залезть в РУП и посмотреть ... а тут прямо в форуме и пояснял ... не могли бы вы потрудиться и тоже привести эти определения тут, или на худой конц link дать на то где это можно быстро открыть и почитать, без необходимости искать ГОСТы ... ?

Чувствую. Просто хочу понять, что толкового есть в RUP и это толковое применять совместно с ГОСТ.

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

Ух ты! А в ваших банковских софтинах разве не используется, к примеру, Общероссийский классификатор предприятий? Или вы сами присваиваете ID каждой российской конторе

А в чем разница между требованиями к функциям (задачам), выполняемым системой, и функциональными требованиями?

Сами просили, чтобы без ГОСТ. Ну, раз не устраивает, просвещаю. ГОСТ 34.003-90, пп. 1.3 и 1.4, но где-то уже писал, что формулировку п. 1.3 считаю в корне неверной.

Если заказчик из США или Европы, то он конечно же не заставит ... ибо там ГОСТ не действует, а есть свои стандарты .
Второй момент, вы либо умышленно, либо по незнанию смешиваете МЕТОДОЛОГИЮ RUP и СТАНДАРТ ГОСТ. Чуствуете разницу м/у методологией и стандартом ... или нет?

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

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

Бог с вами ... где вы там увидили ТРЕБОВАНИЯ к ФУНКЦИЯМ!!!! Нет их там в помине .... там есть ФУНКЦИОНАЛЬНЫЕ требования ...
Просвятите, зачем мне требования к задачам ... и в чем отличие задач и функций (определение функции вы уже не очень удачное привели ... ...)

А что с широты то .. логичнее сопостовлять не RUP и ГОСТ, а уж тогда IEEE и ГОСТ ... заодно оценить трудемкость создания документов и их поддержки с получаемым эффектом. Как то вы не прокомментировали позицию про отношение effort to value ... я думал это вам интересно будет прокомментировать ....

А заставит ли RUP девелопера ввести конкретные требования по безопасности, отвечающие ГОСТам и техническим регламентам? Сомневаюсь, поскольку выяснилось, что девелопер даже не знает, как пользоваться API с функциями применения буфера обмена Какие уж тут дополнительные требования...

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

А ГОСТ обязывает разработчика формулировать указанные и многие иные требования.

Более того, не вижу требований к задачам. К функциям вижу, а к задачам нет. Безобразие!

Короче, надо бы составить табличку для сопоставления RUP'овских шаблонов (родных, "фабричных") и требований наших стандартов. И, после сравнительного анализа, выяснить, что шире - ГОСТ или RUP охватывает требования к программе или системе.

Ситуация. Многим известно, что без II квалификационной группы по электробезопасности на производстве даже к факсу подходить нельзя, не то что к компьютеру. А RUP об этом знает? Как RUP учитывает требования безопасности, требования к видам обеспечения и т.д.?

В Греции все есть . Открываем один из шаблонов на спецификацию требований к ПО, который лежит в папке OUTLINES (для RequisitePro) -- и о чудо, видим:

1. PURPOSE
1.1. SCOPE
1.2. DEFINITIONS, ACRONYMS, ABBREVIATIONS
1.2.1. Definitions
1.2.2. Acronyms
1.3. REFERENCES
1.4. OVERVIEW
2. OVERALL DESCRIPTION
2.1. PRODUCT PERSPECTIVE
2.2. PRODUCT ARCHITECTURE
2.3. PRODUCT FUNCTIONALITY/FEATURES
2.4. USER CHARACTERISTICS
2.5. CONSTRAINTS
2.6. ASSUMPTIONS AND DEPENDENCIES
3. SPECIFIC REQUIREMENTS
3.1. FUNCTIONAL REQUIREMENTS
3.2. EXTERNAL INTERFACE REQUIREMENTS
3.3. INTERNAL INTERFACE REQUIREMENTS
3.4. INTERNAL DATA REQUIREMENTS
3.5. DESIGN AND IMPLEMENTATION CONSTRAINTS
3.6. OTHER REQUIREMENTS
4. NON-FUNCTIONAL REQUIREMENTS
4.1. SAFETY REQUIREMENTS
4.2. SECURITY AND PRIVACY REQUIREMENTS
4.3. ENVIRONMENTAL REQUIREMENTS
4.4. COMPUTER RESOURCE REQUIREMENTS
4.4.1. Computer Hardware Requirements
4.4.2. Computer Hardware Resource Utilization Requirements
4.4.3. Computer Software Requirements
4.4.4. Computer Communication Requirements
4.5. SOFTWARE QUALITY FACTORS
4.6. PACKAGING REQUIREMENTS
4.7. PRECEDENCE AND CRITICALITY OF REQUIREMENTS
5. QUALIFICATION PROVISIONS
6. REQUIREMENTS TRACEABILITY
6.1. UPWARD TRACEABILITY
6.2. DOWNWARD TRACEABILITY

И никто не запрещает вводить дополнительные типы требований .

Ну хорошо, пусть RUP есть методология, интегрированная с некой огромной базой знаний. Положим, RUP способен задокументировать и показать, как реализовать все функциональные требования. Настоящий оракул. Но как быть, если, условно говоря, нет прототипов, нет базы знаний, программа или система настолько новая, что нет наработанных методологий? Ждать появления RUP-2?

Еще ситуация. Многим известно, что без II квалификационной группы по электробезопасности на производстве даже к факсу подходить нельзя, не то что к компьютеру. А RUP об этом знает? Как RUP учитывает требования безопасности, требования к видам обеспечения и т.д.?

Нет доступа, вижу только их бумажную документацию.

Да! Причем самое интересное, что в RUP в отличии от ГОСТ, имеются достаточно подробные guidelines, которые описывают имеено как делать ту или иную вещь. Кроме этого RUP оперирует понятиями Дисциплина (бизес-моделирование, разработка требований, анализ и проектирование, разработка, тестирование, deployment + ряд вспомогательных дисциплин -- конфигуправление, менеджмент, поддержка инструментария и процееса), фаза (Inseption, elaboration, Construction, Transition) и итерация. Определны роли (бизнес-аналитик, системный аналитик, архитектор, разработчик, тестировщик, ....) В рамках дисциплин определны activities в привязке к ролям, и порождаемые артефакты (документы, модели, исходные коды, ...). По каждой acivity даны пояснения и для многих -- guidelines.
Приводятся шаблоны (например *.dot файлы) и даются пояснения по каждому артефакту. Приводится БОЛЬШОЙ глоссарий терминов, по процессу (куда больший чем даже в ГОСТ Р ИСО/МЭК 12207).
Кроме этого РУП рекомендует использовать т.н. use case approach (кстати, я спрашивал о возможности посмотреть на пару юзкейсов, которые ваши смежники, "работающие по РУП" делают, как насчет этого???). Юзкейсы инкапсулируют основные функциональные требования и показывают их в контексте их использования. Далее, РУП предлагает достаточно формализованный переход, от юзкейсов к ДИЗАЙНУ системы (с использованием языка UML) -- например через модели анализа (или domain model в простом случае) к модели дизайна и имплементации. Т.е вычитывая юзкейсы строим модели реализации юзкейсов используя collaboration или seqence диаграммы UML, параллельно, дополняя модель классов (бизнес-сущностей). Понимание о том, какие их объектов должны быть долговоременно сохранены служит источником проектирования БД ...
Опускаясь на уровень дизайна уточняем поля и методы классов, вводим логическое разделение на слои -- презентационный (GUI), бизнес-логики и персистентный (для сериализации в БД) и дополняем нашу модель ... уровень имплементации уже platform dependent ... J2EE или .NET вводит свои механизмы например сериализации и т.д.
Таким образом достаточно четко и формализованно проектируем систему, в точности по требованиям, юзкейсы имют свою рализацию в дизайне.

Говоря о требованиях как таковых -- то они могут быть выражены и в традиционном, иерархическом стиле "Система должна ...". RUP предоставляет свободу в выборе шаблона документа-спецификации требований. в зависимости от требований проекта -- хоть SRS по IEEE 830, хоть modern SRS with use cases ... хоть сам лепи свой шаблон (можно и ГОСТоское ТЗ прикрутить -- какая разница какой конейнер у требований! Главное что требования классифицированы (много разных видов есть требований) и удовлетворяют критериям -- целостности, непротиворечивости, однозначности, проверяемости -- для этого существует анализ и rewiew требований). Инструментарий IBM Rational позволяет автоматизировать многое из вышесказанного. Основным инструментом для разработки требований как раз является RequisitePro а не Rose/XDE/RSA.

И это еще не все! Я только часть описал. Ничего не сказав про конфигурационное управление (можно почитать про это тут http://www.cmcons.com/library.htm)

Ладно, пойду спать ....

Ответы по ТЗ перенес в Технические задания. Вопросы по РУПу обсуждаем здесь, иначе форумы, как функции, станут взаимозависимы и получится полная каша.

А РУП гарантирует, что сформулированные требования не будут допускать возможностей множественного их толкования?

А РУП дает детальные разъяснения, как спроектировать такую фичу?

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

Начнем с того, что не понятно, что же пользователь должен делать, как он будет использовать этот софт? Непонятно какие функции с какими связаны ...
Вот и я про то ... что наличие тех или иных разделов не гарантирует что ТРЕБОВАНИЯ будут сформулированы внятно и однозначно.
Например, что означает "функции редактирования текущего файла с применением буфера обмена операционной системы." Непонятно ... как это спроектировать? Сама "функция" сформулирована некорректно?

Так просветите нас, кто же тогда охватывает вопросы взаимоотношений с заказчиком, управления ожиданиями. Вот ГОСТ 34 охватывает, к примеру, документальную (да и процессуальную) сторону взаимоотношений с заказчиком.

А еще лучше - опишите РУП вкратце, подготовьте статью - буду рад разместить ее на сайте. А чтобы публика поняла, насколько РУП крут, опишите историю, предпосылки к появлению РУП, современное состояние, перспективы развития, дайте краткий сравнительный анализ с теми же ГОСТ.

А на этот вопрос пусть РУПовцы и СМКшники отвечают. Только они способны оценить риски на разных эпапах проектирования

А РУП тут причем??? Это вопрос взаимоотношений с заказчиком. Это вопрос управления проектами в частности вообще -- отсится в т.ч. к управлению ожиданиями.

Согласитесь, несколько иные масштабы по сравнению с 1С.

Не всем дано, не все из них в те времена непосредственно занимались разработкой ТЗ. Разработка ТЗ проводилась специалистами не ниже ведущего инженера. Чаще всего этими вещами занимались нач. секторов или лабораторий.
Если учесть, что в любом советском (и постсоветском) коллективе 70% балласта, то ничего удивительного.
А вот это Техническое задание на программу по ГОСТ 19.201-78 Вы тоже читали с ужасом?

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

"И в нашем полку был аналогичный случай ..." ... РКК Энергия, по всем ГОСТАм сделанный модель-симулятор заправки топливом ракеты-носителя. Результат -- с полными баками стартовый вес ракеты не увеличился! Вот смеху-то было на комиссии .
То что вы приводите и я привожу -- это не результат использования или НЕиспользования ГОСТ или чего другого ... это элементарный дефект. Который должен был быть выявлен при тестировании ... .

Где они описанные эти технологии ... у нас на работе сейчас с ужасом читаю ТЗ, написанные 60-летними "бывшими оборонщиками" ... по ним нельзя ни толком понять, что должна таки делать система (вместо этого они начинают схемы БД малевать ... и еще и макеты GUI рисовать). Где ж, блин, этот всеобъемлющий опыт, общеизвестный на всю оборонку ... не видать (в моем конкретном случае, с конкретными представителями).

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

Строг ты батюшка нынче :? однако

Всегда подозревал, что экстремал=идиот. Так, похоже, и есть

Мда, страшно далеки Вы от народа, батюшка, surgeon. Я понимаю, есть такие конторы и такие рынки для девелоперов, где Ваши комментарии будут вполне адекватны. Подозреваю что в столицах так и есть, а на перефирии SOHO-рынок, про который говорил byur, определяющий.

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

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

Спору нет, там где стороны знают что хотят и могут - дык Договор им в зубы и вперед, но то что это далеко не так, я не знаю, почему Вы этого по жизни не видали.

А пацанов амовских Вы зря забижаете.

Великолепный обазчик западного идиотизма

Заказчики боятся, что:
• не получат того, о чем просили - подготовь юридически грамотный Договор!
• попросят не то, что им нужно - просто бред какой-то;
• заплатят много, а получат мало - ребята, грамотно составляйте Договор!
• отдадут свою судьбу и карьеру в руки технарей, которым на них наплевать - кто не рискует, тот не пьет
• им даже не предоставят никакого разумного плана работ - надо быть полным идиотом, чтобы не затребовать детальный план-график у исполнителя;
• тот план, который им предоставят, не будет иметь ничего общего с действительностью - на то есть процедура согласования и утверждения;
• их заставят придерживаться изначальных соглашений, и поэтому они не смогут своевременно отреагировать на возможные изменения в бизнесе - по ГОСТ вносить изменения в ТЗ нельзя только на стадии ввода системы в действие;
• никто и никогда не скажет им правду - язык создан для того, чтобы скрывать свои мысли.

Разработчики тоже боятся. Прежде всего, они опасаются, что:
• им придется делать то, что они не умеют - не умеешь, не берись;
• им придется делать совершенно бессмысленные вещи - все в твоих руках;
• они вконец отупеют - без работы точно отупеют;
• они не поспеют за последними техническими разработками - для этого должен быть директор по развитию;
• их наделят только обязанностями, а о правах забудут - грамотно составляйте Договор!
• им не объяснят четко и ясно, что именно нужно делать - это они должны перевести требования Заказчика на технический язык;
• им придется пожертвовать качеством работы из-за сжатых сроков - ничего страшного, сроки всегда можно продлить;
• им придется решать трудные вопросы самостоятельно, без помощи со стороны - ребята, но вы же не в детском садике!
• на успешное завершение проекта просто не хватит времени - продляй сроки или пошевеливайся.

Всегда подозревал, что экстремал=идиот. Так, похоже, и есть

А на этот вопрос пусть РУПовцы и СМКшники отвечают. Только они способны оценить риски на разных эпапах проектирования

Мне сдается, что лучше всего проблему обсказали экстремалы Мартин Фаулер и Кент Бек в книге про планирование в XP. Из главы "Страхи"

Разработчики тоже боятся. Прежде всего, они опасаются, что:
• им придется делать то, что они не умеют;
• им придется делать совершенно бессмысленные вещи;
• они вконец отупеют;
• они не поспеют за последними техническими разработками;
• их наделят только обязанностями, а о правах забудут;
• им не объяснят четко и ясно, что именно нужно делать;
• им придется пожертвовать качеством работы из-за сжатых сроков;
• им придется решать трудные вопросы самостоятельно, без помощи со стороны;
• на успешное завершение проекта просто не хватит времени.

И что-то в их подходе, согласитесь, есть - уровнять риск как для заказчика, так и для разработчика, а далее дружить домами или проще говоря итерациционная совместная разработка. Вопрос только как это облечь в форму внятного контракта?

А на этот вопрос пусть РУПовцы и СМКшники отвечают. Только они способны оценить риски на разных эпапах проектирования

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

С кабелем-то как раз, если разработчик добросовестен, проблем быть не должно. А как быть с эфирными вещами: всякие ОСи, СУБДы, серверы приложений, ПО промежуточного уровня...

С НИРами, ОКРами и НИОКРами лучше даже не заморачиваться Сейчас серьезные конторы, работающие на военных, сначала ставят им системы, а потом уж под готовые и рабочие системы подкладывают бумагу.

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

Касательно ГОСТов, то меня по мере углубления в тему все время мучает вопрос, а НИРы и прочие ОКРы, они за какие деньги производились в старину? Чем обуславливались и какова была процедура их принятия? Ведь это вполне себе может быть весьма затратный процесс и за какие шиши, а вернее за чьи, их делать? Вроде как контракта еще нет и заказчик ничем не обязан, а с другой стороны забуриться в незнаемое, даже просто потратившись на зарплату, чтобы только узнать - неа, не могем - да нафиг? Хотя вопрос остается и со всякими РУПами: за чьи деньги узнать, как будет выглядеть система?

А вот тоже любопытно, а заказчик он типа должен эту ведомость скушать в том виде как ее ему поднесут или будет всеми руками иногами биться по всем пунктам, дабы не впарили чего лишнего? А как он может знать, где его раздаивают, а где стараются уберечь его денюжки?

Многие говорят - "обжегшись на 1С, дуешь и на воду". Типичная софтина для малого и среднего бузинеса, сделанная тяп-ляп, не по ГОСТ. Народ, помнится, сильно удивлялся, как это товар (монитор Samsung) может иметь отрицательную цену

Да ну! Опыт показывает иное. Правда, соглашусь с тем, что ГОСТ 19 несколько слабоват. Поэтому и попытался в свое время расписать обобщенную структуру руководства пользователя.

Согласен. Меня, по крайней мере, никто не учил. Алгоритмам и всяким прибамбасам учили, а ГОСТ 19 - нет.

Контора занимается автоматизированными системами, а подрядчики пишут софтину для систем по РУП. И все орут - у нас управление требованиями! А документация их бредовая через меня проходит

Надо, пожалуй, создавать отдельную тему форума, посвященную РУП, а то скоро от ТЗ здесь ничего и не останется.

1. цена проекта устраивает? - ответ Да;
2. что тебе надо, процесс или результат? - ответ Результат.

После этого о процессах речь более не шла

Ага, как и о ТЗ по ГОСТ ... точно так же спрашиваю у заказчика, который пальцы гнул про "мы работаем по ГОСТ", даже не зная по какому из ГОСТ -- "тебе шашечки чтобы по ГОСТ или софт готовый"? На что очень быстро отказываются от "ТЗ по ГОСТ", лишь бы софт был готов. И "хавают" описанные требования в том виде, в котором быстро могут понять о чем речь .
Для SOHO проектов -- писать по ГОСТ даже вредно.

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

Сорри, что есть СМК?
"Иллюзия знания -- хуже незнания". Не исключаю, что ваша контора, как многие у нас, только говорила, что "работала по RUP", в реальности, думаю это было далеко не так. И подтверждением тому -- Вы -- работая в этой конторе так и не поняли что есть RUP -- значит вам не поясняли, либо поясняли бестолково (типа это и так всем известно). Значит процессы не были описаны, и тем более не было инженеров по процессу ... Вы приводите классический пример, когда не разобравшись с RUP, начали БЕЗДУМНО применять отрывками (думаю, что просто стали что-то рисовать в Rose и кричать что это и есть RUP!!!). Интересно, что у вас за контора ... что-то связанное с электроэнергетикой (?)... не на PowerBuilder часом софт пишет контора?

Полистайте ГОСТ 34 серии. Все четко: стадии и этапы создания системы, работы, выполняемые на стадиях и этапах, документы, разработкой которых завершаются конкретные стадии и этапы. Один сплошной процесс. Причем итерационный, а не водопад какой-то. А риски исключаются предварительной проработкой, НИРами, а не так, как в рупах - а вот тут мы сильно рискуем, не пора ли прекратить проект? ГОСТы требуют сначала думать, а потом уж хвататься за работу, а не наоборот - схватили, деньги проели, и что дальше? Ищем крайнего.

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

В данном случае все равно, что и как делать. Здесь важен процесс обналички

Сегодня ровно 26 лет моего общего стажа. За все время деятельности встретил только одного Заказчика, который затребовал процесс Заказчику было задано два вопроса:

1. цена проекта устраивает? - ответ Да;
2. что тебе надо, процесс или результат? - ответ Результат.

После этого о процессах речь более не шла

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

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

Вот хоть кол на голове у людей теши, а они все равно будут ставить знак равенства м/у RUP и "продукты от IBM Rational". Это не одно и то же ... RUP -- это процесс (который оформлен как продукт ), его можно реализовать и без "продуктов от IBM Rational". Наличие продуктов просто дополнительный benefit.

Это работает только при условии, когда мы как разработчик имеем у себя процессы на основе адаптированного RUP, а заказчик просит ТЗ и прочию доку по ГОСТ ... но не прокатывает, когда заказчик требует ПРОЦЕССОВ по ГОСТ (хотя таких наверное у нас нет ). А это то, о чем я говорил -- когда можно создавать требования к ПО, которые могут быть размещены как в ТЗ по ГОСТ, так и в документах по др. стандартам.

Это не главное Главное - чтобы Заказчик работу принял, закрыл Актом сдачи-приемки. Если Акт подписан, никаких формальных претензий Заказчик предъявить уже не сможет. Главное для Исполнителя - сдать работу

В случае, если я делаю проекты "по отмыванию денег" и ради откатов конкретных чиновников -- то, это конечно самое главное ... а если я пытаюсь выжить на рынке например SOHO, то пардон ТОЛЬКО такая стратегия быстро выкинет меня из бизнеса ... Ибо я еще должен иметь реальные references -- когда клиенты будут меня рекоммендовать своим партнерам. В этом случае, я ДОЛЖЕН делать софт, который будет УДОВЛЕТВОРЯТЬ потребности заказчика -- если я его сделаю таким, то акты таки будут подписаны.

Хм ... вообщето очень не хочется для каждой новой задачи начинать все с нуля, т.е. решать заново ... С т.з. процессов -- например тот же RUP должен быть tailored под конкреный проект , но есть в нем нечто, чего не рекоммендуется выбрасывать. Т.о. есть ОБОЩЕННЫЙ процесс, и в нем очень много всего (на все случаи жизни), из которого можно взять то, что подходит именно для конкретного проекта. А если ваш проект настолько уникален, то есть возможность дополнить сам RUP ... для учета этих случаев.

yuzh-батюшка, звиняйте, не было такого умыслу. Вечером вывалила весь накопившийся за день негатив. Утром ужаснулась - погорячилась с некоторыми определениями. Куда смотрит модератор?

Surgeon, звучит угрожающе

в смысле играю с огнем Бить будете? больно, но аккуратно

И ваще, во всем виноват модератор! Проспал? А мне тут теперь отдуваться

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

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

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

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

Смысл такой скрутки ГОСТ и РУП вижу в том, чтобы разработчик или developer - кому как нравится, был вынужден, работая со всякими рациональными продуктами, при компиляции документации укладываться в рамки требований ГОСТ. Иными словами, к РУП надо прикрутить ГОСТированный шаблон, с помощью которого могли бы генерироваться ГОСТированные документы, чтобы разработчик не сам сочинял состав и содержание документов, а чтобы шаблон ему все это навязывал.

Уважаемая Незнакомка, Вы ходите по лезвию ножа. Смотрите, не обожгитесь
Из анекдота про поручика Ржевского:
- Поручик, Вы любите детей?
- Никак нет-с, но сам процесс...

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

Есть несколько разных подходов к разработке и управлению требованиями. Несомненно Вигерс -- "классик жанра" (Конечно же есть еще и Соммервиль, Есть еще и Иен Александр, но это "вариации на тему"). Есть RUP approach (базируется на юзкейсах в частности), есть развитие юзкейсов в работе Коберна ... так что учиться есть у кого (из буржуев). У нас -- к сожалению не у кого ... разве что Позин Б. А. может сочетать RUP и ГОСТы ...

Карл И. Вигерс? :? Я угадал?