Доля рисков при разработки ПО и механизмы защиты от рисков.

[zuze]

Описание рисков есть сдесь

http://www.pti.by/index.php?porisks

Но к сожалению там не написана их доля не миханизмы защиты.

На другому адресу советуют 4-ри статьи прочитать и дают в конце ссылки которые уже не работают

http://www.pmprofy.ru/content/rus/58/589-article.asp

Статьи:

1. Risk Management For Software Projects (Управление рисками в проектах разработки программного обеспечения);
2. Элани Холл (Elanie Hall) Risk Management Map (План управления рисками);
3. Riskit: Increasing Confidence in Risk Management (Riskit: Повышение надежности управления рисками);
4. Кеннета Уолша (Ken Walsh), Software Development Risk and Agency Theory (Риски в проектах разработки программного обеспечения и "теория агентов")

Может у кого есть эти статьи на русском языке или может сам объяснить про доли рисков и механизмы защиты?

Помогите пожалуйста разобраться.

[zuze]

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

http://works.tarefer.ru/68/100078/index.html#

В прошлый раз когда я искал в http://www.google.ru он не выдавал ссылку на эту страницу, сегодня я сделал запрос по другому и нашёл нужную информацию.

Всё вопрос закрыт.

[Dimka]

zuze, может для бизнес-плана оно и сгодится, но в технических аспектах там ничего нет. Чтобы делать количественные оценки рисков, нужно иметь проработанную методологию ведения проекта, в которой предусмотрен систематический учёт различных данных, определены параметры, разработана методика оценки риска на основе этих параметров. Вообще, это серьёзное дело, пригодное для крупной компании. Все, кто помельче и попроще, используют перечни качественных рисков и экспертные оценки их значимости - т.е. пользуются здравым смыслом. Правда, для адекватной экспертной оценки нужен опыт. Если нет ничего, всё только начинается, всё совершенно непредсказуемо, и ориентироваться придётся по ходу дела, при этом ответственно обещать что-то невозможно, можно лишь безответственно вешать лапшу на уши своим заказчикам/инвесторам.

Я, честно говоря, не представляю, что ты там в бизнес-плане написал. Лично меня одни красивые формулы не впечатлили бы

P.S. И в последнее время лично меня раздражали менеджеры, которые к разработке ПО подходили сугубо с финансовой точки зрения. Для таких менеджеров нет никакой разницы между разработкой ПО и розничной продажей бубликов. На каком-то высоком уровне оно так и должно быть, но при этом менеджер должен понимать ценность имеющихся у него активов, их структуру и те возможности, которые он получает от владения этими активами. Но даже этого нет: ведущий разработчик с уникальным набором знаний и уборщица для такого менеджера - нечто одинаковое, называемое "ресурс", а то и ещё интереснее "статья затрат" . Весь бизнес сводится к "минимизации затрат" и "максимизации доходов" любой ценой. Как всё это сказывается на рабочем процессе - это их не интересует, работают с производством, как с чёрным ящиком с одним входом (затраты) и одним выходом (доход).

[zuze]

Спасибо, за пояснение.

[zuze]

Значит мне более правельно использовать риски которые описаны по адресу http://www.pti.by/index.php?porisks?

Но как тогда долю каждого риска из списка находить?

[Dimka]

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

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

Однако, судя по тому, ЧТО ты тут написал (какие материалы выбрал), и КАК задаёшь вопросы, опыта у тебя нет, проект сравнительно небольшой и неорганизованный .

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

[zuze]

Так как это для дипломного проекта, то завтра постораюсь прояснить этот вопрос у консультанта.

Но конешно хотел свой проект внедрить. Пытался свой проект внедрить в архив один, но там как всегда нет денег, да ещё с выше навязывают определённых разработчиков, так что я пока с проектом пролитаю.

К стати мой проект "Програмное обеспечение пооиска, просмотра и заказа электронных копий в диссертационном архиве" сделанный в виде сайта.

[Dimka]

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

Озвучь специальность, уровень учебного заведения: колледж/техникум или вуз, а также присваиваемую квалификацию (для вуза): бакалавр, специалист или магистр.

P.S. Из твоих вопросов и ответов у меня сложилось впечатление, что ты не только не знаешь тему (и хочешь её узнать), но даже не знаешь, где и зачем всё это применяется. И вот мы тут в кулуарах гадали, что за странное явление. Теперь всё объяснилось

[Dimka]

Пытался свой проект внедрить в архив один, но там как всегда нет денег, да ещё с выше навязывают определённых разработчиков, так что я пока с проектом пролитаю.

Ну вот ты и познакомился на практике с двумя рискам, которые сразу сработали

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

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

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

Уже получаются 9 комбинаций для оценки одного риска:
Уровень-Значимость
зелёный-зелёный
зелёный-жёлтый
зелёный-красный
жёлтый-зелёный
жёлтый-жёлтый
жёлтый-красный
красный-зелёный
красный-жёлтый
красный-красный

Им можно прописать весовые коэффициенты. Допустим, зелёный - это 1, жёлтый - 2, красный - 3 (а можно, допустим, 5 или 10, если красным помечались очень высокие уровни).

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

Но это всё не "академические" способы с глубокой теорией

[zuze]

Специальность: "Програмное обеспечение вычислительной техники автоматизированных систем".
Уровень учебного заведения: ВУЗ
Присваиваемая квалификация для вуза: в вузе который я заканчиваю нет разделения на бакалавра, специалиста или магистра.

[Dimka]

zuze, значит коллега с 230105 (220400). Приваемая квалификация: "инженер по специальности ПОВТ и АС" или, попроще, "инженер-программист".

Раз ты инженер-программист, а не менеджер, то:

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

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

[zuze]

Риски нужны для экономической части.

[Dimka]

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

[zuze]

Сегодня был у консультанта. Я у него спросил что писать в этот пункт, а он сказал вычиркни его и всё. Но пока он не поставил подпись на титульном листе до конца быть уверенным нельзя что он не перидумает и не скажет что этот пункт нужно сделать.

[Dimka]

zuze, и правильно консультант сделал Иначе то, что ему туда студенты-программисты напишут, без слёз читать будет невозможно.