Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: bas от 10 Июня 2008, 08:33:06
-
Столкнулся с проблемой убедить начальство\заказчика\
маму\папу ... в том, что нормально выстроенный Процесс Управления Требованиями (ПУТ) это действительно нужно. Или как говорят небезызвестные нам консультанты -- what is the value of requirements management process?
Попытался сформулировать преимущества и риски, которые дает выстроенный ПУТ, но и они не дали результата. Давайте вместе подумаем, что можно придумать еще и переформулировать что есть.
4. Преимущества внедрения процесса и средства Управления Требованиями.
Ниже описаны все преимущества дающие внедрение процесса и средств Управления Требований.
4.1. Внедрение регламентов по управлению требованиями позволит уменьшить время, требуемое на процесс анализа и всю разработку ПО в целом.
4.2. Применение внедряемых техник сбора, анализа и документирования требований позволит разрабатывать ПО, наиболее полно отвечающее всем требованиям Заказчика. Что в итоге позволит сократить время разработки ПО
4.3. Правильная организация требований позволит использовать требования и разработанные решения вторично, что сильно сократит время разработки .
4.4. Полное описание требований и правильная их организация позволит более точно планировать разработку ПО.
4.5. Полная база знаний (требования) ПО позволит делать более правильные стратегические решения по совершенствованию существующего ПО, разработки нового или интеграции ПО, имеющегося в наличии.
4.6. Организация доступа, сохранности и версионности требований с помощью СУТ позволит уменьшить время разработки ПО и избежать ситуации работы с неактуальными требованиями. Кроме того, будет всегда известно – кто и по какой причине сделал изменения в требованиях, что увеличит контроль над процессом анализа.
4.7. Совершенствование процессов целеполагания позволит разрабатывать ПО, которое будет помогать конечному Заказчику в достижении бизнес цели и автоматизировать наиболее необходимые и трудоемкие задачи.
4.8. Правильное документирование и организация требований позволит легко и быстро ввести нового человека (Аналитика, Архитектора, Разработчика и Тестировщика) в проект.
4.9. Правильное документирование и организация требований позволит улучшить качество требований, чтобы они стали более понятные, однозначные и тестируемые. Что в конечном итоге повысит качество создаваемого ПО.
4.10. Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и конечными Заказчиками. Что в итоге уменьшит время, требуемое на согласование требований.
4.11. Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и всеми членами команды разработки (Архитекторы, Разработчики и Тестировщики). Что в итоге позволит уменьшить время разработки и повысит качество ПО.
4.12. Организация трассировки позволит понять – как одно требование влияет на другие и обнаружить ситуацию, когда требования определены не полностью. Данное преимущество позволит уменьшить время, требуемое на изменение требований, и описывать требования наиболее полно.
4.13. Визуализация требований (моделирование) позволяется облегчить процесс понимания требований в целом и в деталях.
4.14. СУТ позволит оптимально распределить права и обязанности между всеми задействованными лицами в проекте и обеспечит работу множества участников над многими проектами.
5. Риски внедрения процесса Управления Требованиями.
Ниже представлен список возможных рисков при внедрении процесса Управления Требований. Данных рисков можно избежать, если правильно выстроить предлагаемый процесс.
5.1. Требования должны быть известны всем участникам проекта
5.2. В процесс анализа не должно быть вложено слишком много усилий
5.3. Не следует быть через чур формальным с требованиями и спецификациями
5.4. Не следует быть слишком не формальным
5.5. Требования не должны быть слишком длинные и скучные для всех заинтересованных лиц, участвующих в процессе создания ПО
З.Ы. Следующим шагом должен быть описанный регламент УТ.
-
Проблема в том, что мы (я) не можем сказать количественные показатели оптимизации при внедрении ПУТ, т.е. не можем сказать точно, что время разработки снизится на столько, затраты уменьшаться на столько и т.д. Т.е. результат нельзя пощупать. Или можно???
-
Цена ошибки при выявлении некорректных требований на стадии их формализации и анализа в 200 раз ниже чем ошибка, обнаруженая в коде.
-
Эд,
Ну прямо слоган :) Может сделать данную фразу девизом сайта??? :)
По делу - т.е. ты можешь гарантировать, что время разработки уменьшиться в 200 раз или кол-во ошибок уменьшится в 200 раз?? Т.е. после того как мы перейдем от того, что ТЗ писали как хотят и где хотят, в нормальный процесс, то мы в 200 (или меньше - цифра) снизим издержки??
Данный факт не убедит потенциального заказчика. Ну пишут они ща как-то ТЗ, а ты приходишь и говоришь - в 200 раз. А он - за счет чего??
-
Можно еще здесь посмотреть http://cmcons.ru/articles/upravlenie_trebovanijami_instrument_ibm_rational_r/rol_protsessa_upravlenija_trebovanijami_pri_razrabotke_slozhnykh_programmnykh_sistem_praktika_primenenija_metodologii_ibm_rup_i_instrumenta_ibm_rational_requisitepro/
И другие статьи с этого сайта. Новичков правда больше пропагандирует процесс управления конфигурациями, но у него хорошая подборка аргументов, проанализировав их, можно и на требования переложить
-
Вот еще, кстати, нашел:
Achieving ROI with Rational Requirements Management Tools (http://ftp://ftp.software.ibm.com/software/rational/web/reports/roirm.pdf)
или ее перевод:
Эффективность от внедрения в финансовом выражении. Часть 1: Окупаемость инвестиций при использовании инструментов Rational для управления требованиями
(http://www.cmcons.com/roi.htm)
-
Эд,
Ну прямо слоган :) Может сделать данную фразу девизом сайта??? :)
Ну не я автор этого слогана. Спасибо Виталию Григорашу и его магистерской дисертации - сделан отличный обзор, прямо можно публиковать
По делу - т.е. ты можешь гарантировать, что время разработки уменьшиться в 200 раз или кол-во ошибок уменьшится в 200 раз?? Т.е. после того как мы перейдем от того, что ТЗ писали как хотят и где хотят, в нормальный процесс, то мы в 200 (или меньше - цифра) снизим издержки??
Данный факт не убедит потенциального заказчика. Ну пишут они ща как-то ТЗ, а ты приходишь и говоришь - в 200 раз. А он - за счет чего??
Нет я говорил о цене стоимости ошибки
Цена ошибки и затраты на ее выявление и устранения в 200 раз меньше чем на стадии кодирования, т.е. если не управлять и сопровождать требования, то веротяность ошибки крайне высока как и цена ее устранения.
Говорить же о том что количество ошибок уменьшится в 200 раз - совершенно нельзя
-
Эд,
Ну это понятно. Я просто так уж для смеха сказал про 200 раз. Эти 200 надо умножить на вероятность возникновения ошибки и м.б. на что-то еще. В общем математика не для слабых умов и главное не доказуемо и не факт, что достижимо.
Мне нужны количественные показатели уменьшения издержек, увеличения скорости разработки, еще чего-то, чтобы это было осязаемо. Пока что тут осязаемо только одно - затраты на внедрения ПУТ.
-
Саша, для тог чтобы сделать это осязаемым, нужно четко выделить критерии и сопоставить им количественные характеристики.
1 Скажем - время ввода в курс дела нового работника
2 время затрачиваемое на проверку требований рецензентом до и после
3. процент выялвения ошибко при обычном рецензировании и с СУТ
4. время подготовки отчетов по требованиям и т.п.
Для начал нужно выделить все наиболее часто осуществляемые операции. Оценить времязатраты до и после
естествено есть качественные моменты - но они как раз должны идти от качеств самих требований
-
Нужно добавить еще один момент -- требования по сути это scope проекта. Когда scope неясно очерчен, то не понятно где заканчивается проект, что чревато особенно при fixed price ...
А вообще забавная ситуация -- многие ИТ-руководители не могут посчитать бизнес-value от ИТ у себя в компании, но требуют этого от своих поставщиков тулов и услуг :-). А вообще, считать экономический эффект от внедрения процессов можно только если у компании вообще есть статистические данные -- например то же распределение дефектов ПО по их причинам, средняя стоимость одного дефекта ... и вообще как эта компания измеряет качество и какие заданные параметры качества ПО у нее есть. Если компания не задумывается об измерении качества ПО, не задумывается о метриках своей работы как таковых (т.е. говорим что у компании низкий уровень зрелости), то скоре всего ей не нужно улучшать процессы в принципе. А если в компании сидит 5 программистов и нет ни одного аналитика, то разработчикам бесполезно предлагать работу с требованиями. Максимум, что им можно предложить, так это использовать bag tracker.
-
Для начал нужно выделить все наиболее часто осуществляемые операции. Оценить времязатраты до и после
Супер, это как?? Т.е. приходишь к заказчику и говоришь, давай я вам внедрю ПУТ, выделим ключевые показатели, и померим до и после и посмотрим что получится???
А вообще ключевые показатели надо выделить. Этим и займусь на днях.
-
Супер, это как?? Т.е. приходишь к заказчику и говоришь, давай я вам внедрю ПУТ, выделим ключевые показатели, и померим до и после и посмотрим что получится???
А вообще ключевые показатели надо выделить. Этим и займусь на днях.
А причем тут заказчик? Ему то это вообще зачем? Или я чего-то не понял
-
Юра,
Еще бы не плохо если бы ты сказал эти "мерительные" показатели, или сказал бы где почитать ...
-
А причем тут заказчик? Ему то это вообще зачем? Или я чего-то не понял
Заказчик в данном случае - руководство компании (внешней или внутренний), где ты собираешься внедрять ПУТ, т.е. сама компания является разработчиком софта, а ты типа модный консультант.
-
т.е. сама компания является разработчиком софта, а ты типа модный консультант.
ААААА, хм ну тут наверное нужно иметь чутье менеджера по продажам, ну и написать парочку диссертаций :) или может купить какой-нить аналитический обзор на тему. Хотя ясно - что нужно как-то оценить внедрение и подсчитать прибыль, где-то на просторах рунета я видел статью, как раз посвященную именно твоей проблеме. Там писалось о том, как некая компания проводила внедрение СУТа и вообще ставлиа процесс разработки и делилась опытом того как это делать быстро - вернее рекламировала что умеет делать это быстро и четко, там же описывались пробемы, риски и способы их избежать - но не помню :(
-
По-моему, никакой количественной оценки не получится. Потому что на ноль делить нельзя.
На самом деле нуля, конечно, не бывает, потому что люди и без процесса работают в соответствии со здравым смыслом, а формализованный процесс только помогает решить им некоторые часто возникающие проблемы, в том числе пока ещё не осознанные.
IMHO, чтобы убедить заказчика, нужно непрерывно капать ему на мозги, приводя пункты 4.1-4.14 на человеческом языке в разных вариантах, подкрепляя примерами из жизни (причём из ЕГО жизни).
-
Там писалось о том, как некая компания проводила внедрение СУТа и вообще ставлиа процесс разработки и делилась опытом того как это делать быстро - вернее рекламировала что умеет делать это быстро и четко, там же описывались пробемы, риски и способы их избежать - но не помню :(
Эд, а может посмотришь, очень надо. А то я уже все перерыл :(
-
На самом деле нуля, конечно, не бывает, потому что люди и без процесса работают в соответствии со здравым смыслом, а формализованный процесс только помогает решить им некоторые часто возникающие проблемы, в том числе пока ещё не осознанные.
В том то и дело, что люди как-то работают, даже спеки пишут.... И надо именно показать разницу между тем что есть и как будет хорошо.
IMHO, чтобы убедить заказчика, нужно непрерывно капать ему на мозги, приводя пункты 4.1-4.14 на человеческом языке в разных вариантах, подкрепляя примерами из жизни (причём из ЕГО жизни).
Это хорошо делать находясь в компании, а из вне?
-
В том то и дело, что люди как-то работают, даже спеки пишут.... И надо именно показать разницу между тем что есть и как будет хорошо.
Это хорошо делать находясь в компании, а из вне?
Так может, и не надо тогда никакого процесса? ;)
-
ИМХО стоит артикулированно отделить две ситуации:
1. Требования Заказчика ясны как пять копеек, а управление требованиями - возможность организации гибкого, но управляемого процесса разработки. По идее такое может потребоваться если компания пробует внедрять новую технологию разработки, что создает дополнительные риски управления проектом (в части понимания в любой момент что именно зачем делаем).
2. Заказчик сам не знает точно, что хочет (редкий Заказчик готов предъявить более-менее ИСЧЕРПЫВАЮЩИЙ список своих ключевых/целевых показателей). Тогда управление требованиями - способ поворачивать разработку вслед за полетом мысли Заказчика уже в процессе разработки, а также возможность оперативно предъявлять ему требования по пересмотру сроков и оценку увеличения стоимости разработки, буде он такие виражи будет закладывать :). Для Заказчика пропагандируется гибкость разработки ("раз уж Вы сейчас не можете точно сформулировать требования..."). Для начальника - снижение рисков взять на себя невыполнимые обязательства по договору, возможность раннего выявления скрытых противоречий в требованиях Заказчика.
-
А №1 - такое вообще бывает???
-
А №1 - такое вообще бывает???
Я так понял, что у Вас как раз скорее первый, а не второй случай, потому и выделил :).
А решил так потому что ключевые фразы Вашего предложения "...уменьшить время, требуемое на процесс анализа", "полно отвечающее всем требованиям Заказчика...", "...использовать требования и разработанные решения вторично...", "...планировать разработку ПО...", "...стратегические решения по совершенствованию существующего ПО...", "увеличит контроль над процессом анализа", "легко и быстро ввести нового человека (Аналитика, Архитектора, Разработчика и Тестировщика) в проект" и пр. смотрятся соблазнительно для человека, который находится в ситуации 1 (т.е. акцентируют в большей степени решение проблем взаимодействия внутри команды Исполнителя, и в меньшей - проблемы взаимодействия Заказчика и Исполнителя).
-
Эд, а может посмотришь, очень надо. А то я уже все перерыл :(
Саня, врядли - это было как-то случайно и уже не помню что и как яискал, толи курсы, толи статьи, просто наткнулся про это дело почитал в памяти отложилось и все, засечку не поставил :(
А насчет капанья на мозги. Гриша верно говорит. На одном тренинге по бизнесу приводился пример. Сидит старичок в прарке и кидает крошки голубям. Сначал голуби улетали, потом стали ближе и ближе приближаться, наконец в один прекрасный день стали есть с руки старичка. Т.е. нужно постоянно закидывать удочку клиенту, но не говорить ему вот вам нужно, а подкидывать материальчик, чтобы у клиента постепенно созрело решение и он типа сам обратился а ты и никакого мол отношения к этому не имеешь. Т.е. не навязчиво надо гнуть свою линию коли понимаешь ее правоту
-
... а ты приходишь и говоришь - в 200 раз. А он - за счет чего??
Ну например,за счет сокрашения времени на переделку кода в случае обнаружения ошибки в требованиях на поздних этапах.
Сокращаем время - сокращаем деньги, причем в качестве только выигрываем. О том как получить сразу качественные требования это уже другой вопрос 8).
Для убеждения заказчиков можно, имхо, использовать аналитические обзоры, как уже сказал Эдуард.
Например, те же всем известные данные Standish Group. Цифры приведенные Лиффингуэлом, не знаю как других, но меня почему убеждают и я ему верю. :)
Сами посмотрите сколько ресурсов на практике у Вас уходит на то, чтобы передалать какое-то требование, которое не точно сформулировали или реализовать требвание, которое вообще забыли.
-
Юра,
Еще бы не плохо если бы ты сказал эти "мерительные" показатели, или сказал бы где почитать ...
Списка всех показателей на память не помню ... но например тот же PSP\TSP дает много метрик -- можно наковырять. Ряд KPI можно подсмотреть в COBIT.
еще можно посмотреть тут http://satc.gsfc.nasa.gov/support/PNSCQ_OCT98/requirements_testing_and_metrics.html
еще тут http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/11.pdf
Еще можно посмотреть эту книгу - Software Testing Fundamentals: Methods and Metrics
by Marnie L. Hutcheson ISBN:047143020X John Wiley & Sons © 2003 (408 pages)
Там есть раздел по метрикам относящихся к тестированию, но часть из них вполне применима как показатели качества ПО.
Еще можно кое-что выковырять отсюда Software Metrics: A Guide to Planning, Analysis, and Application
by C. Ravindranath Pandian ISBN:0849316618
Auerbach Publications © 2004 (312 pages)
Далее, тут есть интересные моменты: Practical Measurement in the Rational Unified Process by Doug Ishigaki
Sr. Technical Marketing Engineer Rational Software and Cheryl Jones. Это из Rational Edge статья, кажись за 2003 год.
-
Еще, в догонку -- очень интересная вещь http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/12.pdf
-
Всем спасибо.
Попробую как-то сагрегировать высказанную выше ин-ю и напишу что получилось.