Анализ чувствительности программного проекта

СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.

Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.

Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.

В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.

Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

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

Таблица 2.27.Оценка постархитектурных факторов затрат

Рассчитаем затраты и стоимость проекта:

ЗАТРАТЫ = AхРАЗМЕР^BхМ_р=2,5(10)^1,16х1,088=36x1,088= 39[чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $234 000.

Таковы стартовые условия программного проекта. А теперь обсудим несколько сценариев возможного развития событий.

Сценарий понижения зарплаты

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

EM_ACAP=EM_PCAP=1.

Следствием такого решения является возрастание множителя поправки М_р= 1,507, а также затрат и стоимости:

ЗАТРАТЫ = З6х 1,507 = 54 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х$5000 = $270 000,

Проигрыш_ в_стоимости = $36 000.

Сценарий наращивания памяти

Положим, что разработчик предложил нарастить память — купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не 70%, а 47%), после чего фактор STOR снижается до номинального:

EM_STOR=1-> М_р =1,026,

ЗАТРАТЫ = 36x1,026 = 37 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000,

Выигрыш_ в_стоимости = $ 12 000.

Сценарий использования нового микропроцессора

Положим, что заказчик предложил использовать новый, более дешевый МП (дешевле на $1000). К чему это приведет? Опыт работы с его языком и утилитами понижается от номинального до очень низкого и EM_LTEX ⁼ 1,22, а разработанные для него утилиты (компиляторы, ассемблеры и отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого и EM_ТООL= 1,24):

М_р = (1,088 / 0,86) х 1,22 x 1,24 = 1,914,

ЗАТРАТЫ = 36х1,914 = 69[чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $414000,

Проигрыш_в_стоимости = $180000.

Сценарий уменьшения средств на завершение проекта

Положим, что к разработке принят сценарий с наращиванием памяти:

ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.

Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета). После этого на завершение проекта осталось $200 000.

Допустим, что в этот момент «коварный» заказчик сообщает об отсутствии у него достаточных денежных средств и о предоставлении на завершение разработки только $170 000 (15%-ное уменьшение оплаты).

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

Первое решение:уменьшение размера продукта (за счет исключения некоторых функций). Нам надо определить размер минимизированного продукта. Будем исходить из того, что затраты должны уменьшиться с 37 до 31,45 чел.-мес. Решим уравнение:

2,5 (НовыйРазмер)^1,16= 31,45 [чел.-мес].

Очевидно, что

(НовыйРазмер)^1,16 = 12,58,

(НовыйРазмер)^1,16 = 12,58^1/1,16 = 8,872 [KLOC].

Другие решения:

q уменьшить требуемую надежность с номинальной до низкой. Это сокращает стоимость проекта на 12% (EM_RELY изменяется с 1 до 0,88). Такое решение приведет к увеличению затрат и трудностей при применении и сопровождении;

q повысить требования к квалификации аналитиков и программистов (с высоких до очень высоких). При этом стоимость проекта уменьшается на 15-19%. Благодаря программисту стоимость может уменьшиться на (1 - 0,74/0,87) х 100% = 15%. Благодаря аналитику стоимость может понизиться на (1 - 0,67/0,83) х 100% = 19%. Основная трудность — поиск специалистов такого класса (готовых работать за те же деньги);

q повысить требования к опыту работы с приложением (с номинальных до очень высоких) или требования к опыту работы с платформой (с низких до высоких). Повышение опыта работы с приложением сокращает стоимость проекта на (1- 0,81) х 100% = 19%; повышение опыта работы с платформой сокращает стоимость проекта на (1 - 0,88/1,12) х 100% = 21,4%. Основная трудность — поиск экспертов (специалистов такого класса);

q повысить уровень мультисетевой разработки с низкого до высокого. При этом стоимость проекта уменьшается на (1 - 0,92/1,1) х 100% = 16,4%;

q ослабить требования к режиму работы в реальном времени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс) х 70% = 47%, в результате чего фактор TIME уменьшится с высокого до номинального, что приведет к экономии затрат на (1- 1/1,11) х 100%= 10%;

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

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

Старший преподаватель кафедры №23

подполковник

А. Попов

Начальник учебного отдела

полковник

О. Усатенко

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

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

Качество — это целостная совокупность характеристик объекта, относящихся к его способности удовлетворять установленные или предполагаемые потребности.

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

Принято различать четыре ключевых аспекта качества:

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

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

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

4. Качество материально-технического обеспечения проекта на протяжении всего его жизненного цикла.

Современная концепция менеджмента качества имеет в своей основе следующие основополагающие принципы:

качество — неотъемлемый элемент проекта в целом (а не некая самостоятельная функция управления);

качество— это то, что говорит потребитель, а не изготовитель;

ответственность за качество должна быть адресной;

для реального повышения качества нужны новые технологии;

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

контролировать процесс всегда эффективнее, чем результат (продукцию);

политика в области качества должна быть частью общей политики предприятия.

Эти принципы лежат в основе наиболее популярного и методологически сильного направления в управлении качеством — Всеобщего управления качеством Total Quality Management (далее - TQM).

Основные положения концепции TQM можно выразить следующими тезисами:

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

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

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

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

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

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

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

8. Управление процессом. Основополагающим принципом TQM является концентрация усилий на конкретных процессах, в особенности на процессах, непосредственно влияющих на качество конечной продукции проекта.

9. Качество поставщиков. Требования к качеству продукции поставщиков аналогичны требованиям к своей собственной. Соответственно необходимо организовать действенный контроль за работой и своевременно отказываться от услуг ненадежных (если это возможно).

10.Информационная система. Для нормального функционирования системы TQM необходимо разработать и внедрить информационную систему, позволяющую эффективно собирать, хранить и использовать данные, информацию и знания. Для этого следует четко определить, какие данные собирать и как их обрабатывать и распространять.

11.Лучший опыт. Одним из действенных инструментов повышения качества и улучшения системы управления является определение и использование лучшего опыта других компаний (так называемый benchmarking). Обычно эта деятельность состоит из определения процессов, которые предполагается улучшать, моделирования собственных процессов, изучения лучшего опыта других компаний, анализа выводов и использования полученных результатов.

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: