Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Доля рисков при разработки ПО и механизмы защиты от рисков.  (Прочитано 14462 раз)
0 Пользователей и 1 Гость смотрят эту тему.
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« : 07-03-2009 17:22 » 

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

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
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #1 : 11-03-2009 01:17 » 

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

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

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

Всё вопрос закрыт.
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 11-03-2009 12:38 » 

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #3 : 11-03-2009 15:58 » 

Спасибо, за пояснение.
Записан
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #4 : 12-03-2009 08:32 » 

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

Но как тогда долю каждого риска из списка находить?
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 12-03-2009 14:53 » 

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

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #6 : 12-03-2009 16:24 » 

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 12-03-2009 21:13 » 

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

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

P.S. Из твоих вопросов и ответов у меня сложилось впечатление, что ты не только не знаешь тему (и хочешь её узнать), но даже не знаешь, где и зачем всё это применяется. И вот мы тут в кулуарах гадали, что за странное явление. Теперь всё объяснилось Улыбаюсь
« Последнее редактирование: 12-03-2009 21:16 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 12-03-2009 21:45 » 

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

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

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

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

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

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #9 : 12-03-2009 21:47 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 12-03-2009 23:02 » 

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

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

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

2) в какую часть пояснительной записки ты намерен поместить риски? В основную (описание программного решения) или экономическую? (Если речь про консультанта, то похоже на экономическую, поскольку основную часть курирует руководитель дипломного проекта.) Для основной части тебе будут нужны инженерные (аналитические, проектирования, технологические, технические) риски, для экономической - маркетинговые и, возможно, организационно-управленческие.
« Последнее редактирование: 13-03-2009 09:32 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #11 : 12-03-2009 23:16 » 

Риски нужны для экономической части.
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 13-03-2009 09:36 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zuze
Опытный

ru
Offline Offline
Пол: Мужской
Россия, Москва


« Ответ #13 : 13-03-2009 16:00 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #14 : 13-03-2009 16:14 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines