WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 33 |

• Цель – подготовка проекта решения для ЛПР. В этом случае для подготовки проекта решения обычно применяются математические методы оценки согласованности мнений экспертов.

Математические методы оценки мнений экспертов следует применять, ясно понимая область их применимости.

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

При этом отсеиваются как неквалифицированные лица, попавшие в состав экспертной комиссии по недоразумению, так и наиболее оригинальные мыслители, глубже проникшие в проблему, чем большинство. Следовало бы выяснить их аргументы, предоставить им возможность для обоснования их точек зрения, вместо этого их мнением пренебрегают. Бывает и так, что эксперты делятся на две или более групп, имеющих единые групповые точки зрения. Иногда заявляют, что в случае обнаружения двух или нескольких групп экспертов (вместо одной согласованной во мнениях) опрос не достиг цели. Это не так! Цель достигнута – установлено, что единого мнения нет. ЛПР должен это учитывать. Стремление обеспечить согласованность мнений экспертов любой ценой может приводить к сознательному одностороннему подбору экспертов, игнорированию всех точек зрения, кроме одной, наиболее полюбившейся ЛПР.

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

С целью искусственно добиться согласованности стараются уменьшить влияние мнений экспертов-диссидентов. Жесткий способ борьбы с диссидентами состоит в их исключении из состава экспертной комиссии. Мягкий способ борьбы с диссидентами состоит в применении робастных (устойчивых) статистических процедур. Простейший пример:

если ответ эксперта – действительное число, то резко выделяющееся мнение диссидента сильно влияет на среднее арифметическое ответов экспертов и не влияет на их медиану. Поэтому разумно в качестве согласованного мнения рассматривать медиану. Однако при этом игнорируются (не достигают ЛПР) аргументы диссидентов.

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

Распространен довольно примитивный подход так называемой «квалиметрии», согласно которому объект всегда можно оценить одним числом. Каждый объект можно оценивать по многим показателям качества. Например, программный продукт можно оценивать по таким показателям:

• требования к минимальным необходимым ресурсам;

• количество известных некритических ошибок;

• максимальное время реакции на событие и т.п.

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

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

Как показывает опыт проведения экспертных исследований, целесообразно выделять следующие стадии экспертного опроса:

1) формулировка ЛПР, цели экспертного опроса;

2) разработка и утверждение у ЛПР технического задания на проведение экспертного опроса;

3) разработка подробного сценария проведения сбора и анализа экспертных мнений (оценок), включая конкретный вид экспертной информации и конкретные методы анализа этой информации;

4) подбор экспертов в соответствии с их компетентностью и формирование экспертной комиссии;

5) проведение сбора экспертной информации;

6) анализ экспертной информации;

7) при применении процедуры из нескольких туров – повторение двух предыдущих этапов;

8) интерпретация полученных результатов и подготовка заключения для ЛПР;

9) официальное окончание деятельности экспертной комиссии.

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

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

Часто предлагают использовать методы взаимной оценки и самооценки компетентности экспертов. С одной стороны, кто лучше может знать возможности эксперта, чем он сам С другой стороны, при самооценке компетентности скорее оценивается степень самоуверенности эксперта, чем его реальная компетентность. Тем более, что само понятие «компетентность» строго не определено. Можно его уточнять, выделяя составляющие, но при этом усложняется предварительная часть деятельности экспертной комиссии.

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

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

Необходимо подчеркнуть, что подбор экспертов, в конечном счете – функция ЛПР, и никакие методики подбора не снимают с ЛПР ответственности за результаты принятых решений.

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

Рассмотрим условный пример.

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

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

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

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

При планировании на 30 лет имеет смысл вложить средства в создание и развитие собственного научно-исследовательского центра, и т.д.

Таким образом, популярное утверждение «фирма работает ради максимизации прибыли» не имеет точного смысла. За какой период максимизировать прибыль – за месяц, год, 10 или 30 лет От горизонта планирования зависят принимаемые решения.

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

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

3.6. «Карта памяти» по теме 3.7. Список использованной и дополнительной литературы 1. Пашкус Ю. В. Мисько О. Н. Введение в бизнес. - Л.:

"Северо-Запад", 1991.

2. Голубков Е.П. Какое принять решение М.: Экономика, 1990.

3. Голубков Е.П. Технология принятия управленческих решений. М.: Издательская группа "Дело и сервис", 2005.

4. М. Эдоус, Р. Стэнсфилд. Методы принятия решения. М.:

Издательство объединения "Юнити", 1997.

5. В. Н. Спицнадель. Теория и практика принятия оптимальных решений. М.: Бизнес-пресса, 2002.

6. Балабанов И.Т. Риск-менеджмент. М.: Финансы и статистика, 1996.

Тема 4. Проектный менеджмент 4.1. Введение В этой теме рассматриваются основные основы проектного менеджмента в отличие от менеджмента вообще (последнее – существенно более широкое понятие, включающее в себя, в частности, и менеджмент компании).

Изучив учебный материал данной темы, Вы:

• узнаете или пополните свои знания о том, что такое проект, и что проектом не является;

• узнаете или пополните свои знания о типах проектов и областях эффективного применения проектного менеджмента;

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

В рамках темы рассматриваются следующие учебные вопросы:

• Области эффективного применения проектного менеджмента.

• Типы проектов.

• Жизненный цикл проекта по созданию программного обеспечения.

• Основные стандарты в области управления проектами разработки программного обеспечения.

4.2. Области эффективного приложения проектного менеджмента Обратимся к понятию «проект» и выделим четыре характеристики, делающих деятельность проектом.

• Направленность на достижение конкретных целей.

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

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

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

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

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

4.3. Типы проектов Проекты в области информационных технологий могут быть классифицированы по различным признакам. Далее мы рассмотрим только проекты, имеющие отношение к программному обеспечению (ПО).

Проекты в области разработки или сопровождения ПО разделяются на категории следующим образом.

По уровню сложности и области применения разрабатываемого или модифицируемого ПО.

Проекты по разработке/модификации ответственного ПО (система управления атомным реактором). Такие проекты не обязательно требуют для выполнения большой команды исполнителей, однако, предъявляют повышенные требования к качеству процесса разработки, квалификации персонала и качеству продукта.

Проекты, связанные со сложными многофункциональными системами (Enterprise Resource Planning (ERP) – Управление ресурсами предприятия).

Сложность состоит, как правило, в управлении требованиями (сбор требований о функциональности) и координации усилий большой команды исполнителей.

Малые проекты (Интернет-магазины, сайты, простые настольные (standalone) приложения). Здесь критической, как правило, является скорость и стоимость разработки.

«Наукоемкие» проекты (численные расчеты, разработка новых специальных алгоритмов). Сложность – в творческом характере процесса разработки.

Проекты по сопровождению или модификации больших унаследованных приложений, систем или баз данных (системы продажи авиабилетов или железнодорожных билетов, существующие с 70х гг., в США – экономические или бухгалтерские системы, написанные на COBOLе для mainframe-систем в 50-60е гг.). Основные сложности: большой объем, как правило, плохо документированного кода, над которым трудилось несколько поколений разработчиков, отсутствие проектной документации, необходимость работы с устаревшими технологиями и недоступность соответствующих специалистов.

По способу применения разрабатываемого или модифицируемого ПО.

Проекты по разработке неотчуждаемого ПО («для себя»).

Разработка для заранее известного (не чрезмерно широкого) круга пользователей без дальнейшего тиражирования («внутреннее ПО»).

Разработка или модификация ПО для конкретного заказчика.

Разработка «коробочного продукта».

Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.