И. Соммервилл - Инженерия программного обеспечения (1133538), страница 136
Текст из файла (страница 136)
В основном учиты- ваются непредвиденные обстоятельства, поэтому присутствие этого элемента в модели зависит от изо. бретательности и предвидения менеджеров и разра. ботчиков Связь(изображается направлен- ной стрелкой) Отображает обмен информацией между людьми либо между человеком и компьютернымн системами под- держки. Связи разделяются на формальные и нефор- мальные. К формальным относится утверждение ме.
неджером контрольного проектного элемента, при- мером неформальных связей может быть общение разработчиков по электронной почте для выяснения непонятных мест в документации Риг. 25З. ()угоцггг тггтирооокия лрогрпгмгкогомооуол Модель также должна отображать нерабочие периоды времени в реализации проекта и взаимозависимость между этапами процесса разработки и контрольными проектными элементами, поскольку эти этапы можно выполнять как параллельно, так и последовательно.
Все элементы проекта взаимосвязаны, например олин и тот же специалист может быть задействован на разных этапах создания ПО. Контрольные проектные элементы мо. тут зависеть от других контрольных элементов и даже от взаимоотношений между специалистами, работающими над проектом. Детализированные подели процесса создания ПО отличаются чрезвычайной сложностью. Создание единой модели, отображающей все аспекты производственного процесса, является крайне трудной и ответственной задачей. Чтобы показать, насколько сложными бывают подобные модели, рассмотрим фрагмент процесса тестирования отдельного программного модуля большой системы, где используется процесс управления конфигурацией (см. главу 29).
На рис. 25З показаны взаимоотношения между процессом тестирования, входом н выходом этого процесса, а также между пред- и постусловиями. 2Б. Совершенствование производства ПО 521 На рис. 2ЬА этап тестирования модуля разложен на составляющие действия. Этот фрагмент демонстрирует лишь малую часть общего процесса тестирования программных модулей.
Четыре основных потока действий включают подготовку тестовых данных, написание тестовых процедур, проведение тестирования и создание отчетности о результатах тестирования. Ркс. 25.4. Доосэювя яо эисжиулмонию модуля Я намеренно не включил в эту модель пред- и постусловия и данные о входе и выходе этапа, так как это только усложнит модель и затруднит ее понимание. Не следует пытаться вместить всю информацию в одну единственную модель. Лучше создать несколько моделей разного уровня обобщения и связать их какими-либо общимн элементами, будь то действия нли контрольные проектные элементы. Одни модели могут представлять этапы процесса производства, другие -данные, управляющие выполнением процесса. 25.2.1.
Исключения в процессе создания ПО Сам по себе процесс создания программного обеспечения — поилтие достаточно сложное. Даже если организация разработала модель технологического процесса созда. ння ПО, это еще ие значит, что разработчики не столкнутся с какой. либо проблемой, не предусмотренной заранее. В действительности реагирование на такие непредусмотрен. ные проблемы — часть повседневной работы менеджеров проекта. Поэтому идеальной представляется модель технологического процесса, которую можно легко изменять в ходе решения возникающих проблем.
Ниже приведены примеры непредусмотренной ситуаций, к которым менеджер должен быть готов практически каждый день. 522 Часть '1Ч. Управление 1. Ключевые разработчики могут заболеть и не выйти на работу как раз перед решающей проверкой проекта. 2. Невозможен обмен данными вследствие неисправности линий связи.
3. Вполне вероятно изменение структуры компании, в результате чего менеджеры будуг тратить больше времени на решение организационных вопросов, вместо того чтобы работать пэл проектом. 4. Возможно вовлечение большего количества персонала в разработку нового проек. та, имекнцего болылий приоритет, чем текущий. В основном непредвиденные ситуации влияют на ресурсы, бюджет и график работ. Практически невозможно предусмотреть все экстремальные ситуации и включить их в организационную модель процесса. Поэтому в большинстве случаев менеджерам проектов приходится на ходу справляться с возникающими трудностями и вносить соответствующие изменения в стандартны)! процесс создания ПО. 25.3.
Измерение производственного процесса Измерение процесса создаиил ПО заключается в сборе количественных данных, харэктсризуюгцих этот процесс. В кингс [171[, посвященной совершенствованию процесса создания ПО, утвсрвшается, что сбор количественных показателей производственного процесса — необходимая составляющая его совсргнснствования.
Эти показатели помогают узнать, насколько повысилась эффективность процесса после впсссиия изменений. Например, можно провести измерение времени и средств, потраченных иа тестирование до изменения производства. Если совершенствование было эффективным, это должно сни. вить затраты, время или то и другое. Однако измерения сами по себе ничего нс окажут об улучшении качества конечного продукта. Дополнительно необходимо иметь представление о значении показателей програмьиюго продукта (см. главу 24) и сопоставлении полученных результатов с новым процессом разработки. Среди показателей процесса разработки выделим три вида.
1. В[селга, нанфоненное иа аынагнтше онгделъного замни Угабанг. Это можсг быть только рабочее время выполнения этапа, календарное время выполнения этапа или время работы отлсльного специалиста. 2. Вегу[и;ы, иеобхадгмгъге дал Реаггггойии этила Рнбонг. Ресурсы могут подсчитываться в человеко-днях, затратах иа командировки либо ресурсах вычислительной техники.
3. Квгигепнго наогноэении однао и этго же шбытия. Среди таких событий можно назвать количество ошибок, обнаруженных при проверке программного кода. количество измененийи й в системных требованиях, среднее количество измененных строк кода и тд. Первые лва вида показателей применяются для определения эффективности изменений процесса. Например, процесс разработки содержит несколько фиксированных вреъгеииък точек. орели которых создание системной спецификации, завершение проектирования сисгеъшой архитектуры, завершение формированил тестовых данных.
При этом можно измерить время и средства, потраченные на переход от одной фиксированной точки к другой. Полученные результаты помогут определить те составляющие процесса, которые пуждаютея в совершенствовании. После выполнения изменений следует измерить показатели процесса с тем, чтобы получить данные об эффективности изменений.
25. Совсршеыствоваыие производства ПО 523 Измсрснис количества повторсннй одного сабытин нмсст более нспосрсдствсииас атно. шанин к качсству программного продукта. Например, обнаружение большсга количсства ошибок с помощью новой программы проверки, вероятно, улучшит качества готового продукта. Основная проблсма, снлзаинав с иэмсрснисм процссса создапик ПО,— нсобхолимость знать, по именно слсдуст измерить. Длл рсшсннн этого вопроса в статье (26) прсдлагасгсэ парадигма СЯМ (Соа>О»сзцап-Мсгпс- цсль.нопрос-показатсль), с помощью которой опрсдслэстсн вид измсрснин и способ сто испол ьзонаиин.
Эта парадигма основана "на трех китах". 1. Цель. Что явлнстсл цслью компании по совсршснстаонанию процссса созданнл ПО? Это может быть повьипснис производитсльности труда программистов, сокращсиис времени разработки, повышение надежности готового продукта и т.д. 2. Ввэр>хъ>. Это детализация поставленной цели.
Как правило, кажлэл цель соотносится с рядом вопросов. Привсдсм примеры вопросов к указанным вышс цслвм. ° Как повысить количество строк кода, отлаженных програмл>истом? ° Как сократить врсмн заключительного этапа разработки требований? ° Как повысить эффективность приварки систсмы на иадсжиость> 3. >Уоказннмлл.
Это та информацил, которая поможст ответить иа сформулированные вопросы, в частности опрслслить, дастигнуп.> или цст поставлсшц >с цслп, ! !апримср, можно опрсдслить наказатсль производитсльности программистов, выра>касмый в строках иаиисашюго ими кода, такой показатсль, как уровсш нх профсссионэльного опыта, иоказатсль, равный количеству официальных контактов мсжлу заказчиком и исиолнитслсл> па каждому иэмснсишо снстсмиых трсбованнй, а такжс показатель количества провсдсииых тестов длл вылвлснин аи>пГ>ок в системе.
Главное прсимущсство данного подхода состоит в том, что н исм раздслспы организационная дслтсльиость (цсли) и процесс производства (вопросы). Вцимаипс каицситрируется иа сборе оирсдслсипых данных и прсдусматрнваст разпыс способы анализа рсзультатов измсрсиик в зависимости от поставленного вопроса. Падхол С>ЯМ был объсднисн с описанной в слслующсм раздслс модслыа ацсики >ронин развития, разработанной Институтом ннжсисрии программного обсспсчсинн (США), что нашло свое воилощсннс в методе созсршспстнанаиин працсгга ръзработки ПО [285). Разработчики этого метода предлагают поэтапный подход к совсршснствовапию прсщссса созда.
иия ПО. Этот подход основан иа ввсдсиии измсрсинй только посла тога, кал организация достигнет достаточного уронил раэвитин технологии. Подход предлагает руководство и практичсскнс советы по висдрснию измерений в цслнх сонсршсисгнонаиин производства. 25.4.
Модель оценки уровня развития Институт нижсисрии ираграл>много обсспсчсиил (Яоуичагс Епй!пссппц 1пиишс — 5Е1) ири упнвсрс>ггстс Кэрисги-Моллон, получающий фииапсиронапис от Мииистсрства обороны США, заиимастсл распространсписм тсхиологий саздэиин ПО. Инстнт)т был учрсждси с целью расширить возможности индустрии программного обсспсчспин в США. осоГ>сино длн ор>аниэаций, финансируемых Мишютсрством аГ>арапы. В ссрсдинс 8й.х го. дон ииспггуг начал исслсдоааииэ по оценке возможностей каминный — разработчиков ПО.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
