И. Соммервилл - Инженерия программного обеспечения (1133538), страница 128
Текст из файла (страница 128)
Распределяя прогнозируемые затраты на реализацию проекта, мы асс же не можем точно знать, сколько человек необходимо включить з команду разработчиков. Часто набор программистов происходит по принципу от меньшего к большему с последующим постепеннммуменьшением их численности. Это 'объясняется тем, что на раннем этапе разрабопси требуется относительно небольшое количество специалистов, которые будут запинаться только планированием системы и разработкой спецификации. По мере выполнения проекта уасличиаается и объем выполняемых работ, а количество персонала увеличивается до максимума. После кодиро.
аання и тестирования системы количество специалистов уменьшается, пока не остается один-дза человека. Очень быстрое наращивание количества персонала часто указывает на отставание проекта от графика работ. Менеджерам не следует набирать слишком много специалистов на самом раннем этапе выполнения проекта. Наращивание объема работ можно смоделировать с помощью так называемой кривой Рэлея [223]; оценочная модель Пугмана (Рцинип, [286]) использует модель наращивания персонала, основанную на этих кривых. Модель Путмана учитывает время разработки как ключевой фактор, поскольку с уменьшением времени па разработку экспонснциально узе. личиааются затраты на создание системы.
ггф-".,: 'КЛЮЧЕВЫЕ ПОНЯТИЯ -': —:. " . эу««ч'-"Основйьыы«и'фектоРзмн, вамющими йа пРоизводителыюсть, Явмютса ишвюидтзльные спасобно- «ф" [М; сти Работников (дашширующий фактор], опыт создания' ПО данного типа, технология процесса ц~(йй Разрвбштщ«Размер проекта, наличие'средств поддержки и рабочая обстзнавщ. Йьь , ° ',:"„', 'Существует множество методов оценки стоимости прогрзммйога продукта, которые следует ис- ~„,'г „'йчпользовать параллельно. Если полученные результаты имеют большие отличия, значит, для анали- „ ф.:~"'[',Ъа использована недостаточная или неподхадяшпя информация, ]'зг, Цена программного продукта часто определяется с целью«заключения контракта, что приводит к ,.«,;фз последующей подго]]кафункциональных,возможностей системы для приведения ее в соответствие: : °, Основной трудностью в алгоритмическом моделировании стоимости явлются зависимость оценки „".;],;,,;„, стоимости,от, свойств и параметров готовога продукта.
На ранней стадии правка невозможно „'".(] точное огчждвленне днйгсвойств и параметров г „, „шп,,е ..« .. ° . „;, г-.~". 5«э '. ° 'з".Модель оцв ии'стоимости СОСОМΠ— харашо прощюннмг модель,.в кщорай учитываются проект., нью хщюкшриспии, свойства создаваемагп ПО, ашаршные средства и аоимшпюши персоншю. В з«э« дмшуга модель Ркхв вквючены средшва для определены дмпедьноши работ нзд иранцам ,з,,] двгоритмнческие,юделн определения стоимости использукяся дпя управления программными ,",йт«„"г.'.гпроекшми, поскольку они поддерживают количественный анализ параметров. Эти модели позво- ж,'«'ч «ляют определить вклад щждого отдельного параметра в общую стоимость проекта и провести обмктивнав (хотя н не застрахованное от ошибок] сравнение этих параметров. "з..: Время выполнения работ не зависит прямо пропорциональна от количества нанятых для правки Е„"йз.-, специалистов.'Привлечение большего количества людей к проеюу, который отстает от графика М~:; работ, может еще больше затянуть время его выполнения.
492 класть ~Ч. управление Упражнения 23.10. Некоторые большие программные проекты требуют написания миллионов строк кода. Объясните 23.11. Насколько этично назначить кампанией-разработчикам относительно низкую цену для контракта, зная, что при столь неопределенных требованиях можно со временем повысить цену за дополнительные изменения в них, которые со временем обязательно будут сделаны заказчиком? 23.12. Следует ли менеджерам применвь критерий производительности для определения деловой хщюктеристики специалиста? Какие меры предосторожности необходимы, чтобы этот процесс определения профессиональных возможностей специалиста не влиял на качество его работы? 23.1. 23.2. 23.3.
23,4, 23.5. 23.6. 23.7. 23.6. 23.9. Опишите два подхода к определению производительности программиста. Отметьте преимущества и недостатки каждого подхода. Приведите пять факторов, которые оказывают существенное влияние на производительность ко- манды программистов по разработке больших встроенных систем реального времени. Любой оценке стоимости присущ определенный риск, независимо от метода оценки.
Предложите четыре способа снижения возможного риска при оценке стоимости. Менеджер проекта создания ПО ответственен за разработку системы управления оборудованием по лучевой терапии для лечения людей с онкологичешеми заболеваниями. Эта система встроена в аппа. ратные средстщг и должна работать на специальном процессоре с ограниченным объемом памяти (8 Мбайт).
Машина осуществляет связь с базой данных пацишпа и по окончании лечения автоматиче- ски записывает в нее дозу радиации, которой подвергался пациент, а также другие подробности лече- ния. Для определения затрат, необходимых дгш разработки данной системы, использована модель СОСОМО. В результате получена оценка объема работ в 26 человеко-месяцев. При оценивании все множители, формирующие стоимость, были приравнены к единице.
Объясните, почему эту оценку необходимо уточнить с учетом таких показателей, как проектные ха- рактеристики, возможности персонала, параметры системы и организационный фактор. Выделите четыре показателя, которые окажут существенное влияние на первоначальную оценку стоимости по модели СОСОМО, а также предложите воэможныв значения для этих показателей.
Обоснуйте вы- бор каждого показателя. Назовите три причины, по которым алгоритмические оценки стоимости, проведенные различными компаниями, не будут сопоставимыми. Объясните, каким образом менеджеры проектов мо~ут использоваь алгоритмический подкод к оценке стоимости для анализа проектных характеристик. Опишите ситуацию, когда менеджеры вы- бирают подход, не основанный на принципе наименьшей стоимости проекта. Реализуйте модель СОСОМО с использованием программы электронных таблиц Властовой Ехсеб Детальное описание этой модели можно загрузить с УУеЬ-узла СОСОМО 2.
На УУеЬ-странице дан- ной книги я поместил ссылку на этот УУеб-узел. насколько полезными могут быть модели определения стоимости для таких систем. В каких случаях они могут быть неприменимы к большим системам? еу а~фу с с езч Ф с „,, 4".й Уьгт, „ 1ЙУ."!:1 ~ ф, Ф~ Управление качеством Цель настоящей главы — представить основные принципы управления качеством и мероприятия, выполняемые в этой области. Прочитав эту главу, вы должны: 0 знать основные процессы уцравлепик качеством, а также основные составллюгцие процесса управ.
лепил качеством, а именно: обеспечение качест- ва, планирование качества и контроль качества; понимать важность примененик стандартов в процессе управления качеством; иметь представление о метрических показателях ПО и о различиях между пропюзирусмыми и контролирующими показателлмн; понимать необходимость систем намеренна при оценке показателей качества и знать об ограни. чениях в процессе измерения показателей ПО. 24.1. Обеспечение качества и стандарты 24.2. Планирование качества 24зй Контроль качества 24 4. Измерение показателей ПО 494 заасть |Ч.
Управление Для многих организаций основным критерием деятельности является достижение высокого уровня качества производимой продукции либо предоставляемых услуг. В наше время невозможна поставка продуктов низкого качества, требующих устранения недоработок после доставки закаэчику. К программным продуктам вто относится не в меньшей мере, чем к таким промышленным товарам, как автомобили, телевизоры или вычислительная техника. Однако качество программного продукта является достаточно сложным понятием, трудным для определения.
Традиционно продукт считается качественным в том случае, если полностью соответствует техническим требованиям [82). В идеале такое определение должно быть применимо ко всем продуктам, в том числе и к программным, однако здесь нас подсгерегают некоторые проблемы. 1. Технические требования ориентированы на те свойства продукта, которые необходимы заказчику. Однако организация-разработчик может также иметь свои требования к разрабатываемому программному продукту (например, удобство сопровождения), которые обычно не включаются в технические требования заказчика. 2.
Неизвестно, как точно определить и измерить определенные показатели качества (например, то же удобство сопровождения). Я. Как уже упоминалось в первой части книги, трудно создать полную спецификацию программного продукта. Поэтому, хотя созданный программный продукт будет полностью соответствовать спецификации, заказчик все равно может не получить высококачественного продукта.
Очевидно, необходимо прилагать усилия для совершенствования спецификации, од. пако на данном этапе следует смириться с тем, что она будет не лишена недостатков. Таким образом, следует признать существование проблемы несовершенства спецификаций и привести в действие ряд процедур для улучшения качества ПО в рамках ограничений, возникающих вследствие этой проблемы.
Особенно зто касается таких определяющих качественных характеристик программных продуктов, как удобство сопровождения, пере носимость и эффективность, которые детально не определены в технических требовани. ях, однако оказываются критическими показателями для качества программных систем. В разделе 24.2, раскрывающем вопросы планирования качества, зти показатели рассматриваются более подробно. Достижение необходиьюго уровня качества зависит от менеджеров по качеству компании.разработчика.
Теоретически управление качеством основывается на принципе определения стандартов и процедурных норм, в соответствии с которыми должно разрабатыватьсл программное обеспечение, а также на проверке выполнения этих норм всеми разработчи. юмн. На практике, однако, понятие управления качеством имеет более емкое содержание. Хоро~вне менеджеры по управлению качеством стремятся к созданию в компании атмосферы "культивирования качества", где каждый, кто занимается разработкой продукта, берет на себя обязательство достичь наивысшего уровня качества созлаваемого продукта. Такис менеджеры стимулируют команду к качественному выполнению работы и к постоянному поиску идей повышения качества.
При том что стандарты и процедурные нормы являются основой качества, опытные менеджеры по управлению качеством осознают значение тех неосязаемых аспектов качества программных продуктов, которые не могут быть включены в станларты (например. изящество, читабельность и т.п.). Они поддерживают служащих, заинтересованных именно в таких нематериальных аспектах, а также поощряют профессиональное отношение к работе всех членов команды. Процесс управления качеством состоит из трех основных видов деятельности. 24.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
