Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Липаев В.В. Программная инженерия

.pdf
Скачиваний:
724
Добавлен:
02.05.2014
Размер:
10.14 Mб
Скачать

Лекция 9. Управление ресурсами в жизненном цикле программных средств

затрат на разработку программных компонентов за счет автоматизации нетворческого труда все более определяющей для технико-экономических показателей (ТЭП) создания ПС становится доля затрат на творческий труд и возрастают требования к творческим способностям специали­

стов.

Необходимость всегда выполнять значительную долю творческих ра­ бот, которые даже для высококвалифицированных коллективов требуют определенных затрат, приводит к пониманию наличия потенциальных пре­ дельных значений ТЭП для новых разработок По мере повышения квали­ фикации коллектива и автоматизации творческой части труда следует ожи­ дать асимптотического приближения к предельным значениям ТЭП. Эти предельные значения определяются интеллектуальными возмолсностями человека по интенсивности принятия творческих решений. Они позволили выявить предельные значения производительности труда и дли­ тельности разработки сложных комплексов программ (см. лекцию 5). Ре­ альным путем их оценки является изучение и экстраполяция прецедентов

иэкспериментальных данных реальных разработок ПС с наилучшими ТЭП,

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

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

230

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

сохраняется творческий труд при системном анализе, при комплексировании компонентов и их комплексной отладке, а также во время испытания ПС в целом (см. лекцию 14).

Для реализации сложных проектов ПС наиболее часто применяются

две схемы организации коллективов специалистов:

формирование для выполнения каждого проекта жесткой органи­ зационной структуры целостного коллектива с полным составом необхо­ димых специалистов под единым, централизованным руководством лиде­ ра проекта;

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

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

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

231

Лекция 9. Управление ресурсами в жизненном цикле программных средств

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

Практически в каждом успешном проекте должен быть или был лидер. Лидером продукта может быть: менеджер продукта, менеджер про­ ектирования, руководитель проекта. Лидер должен:

руководить процессом выявления и формирования требований за­ казчика;

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

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

осуществлять проверку спецификаций программного средства, что­ бы удостовериться, что они соответствуют реальной концепции, представ­ ленной детальными функциями;

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

История развития разработок программных продуктов — это история роста их масштабов. Крупные проекты, как правило, требуют координи­ рованной работы больших коллективов и многих команд. Возрастание сложности снижает способность человека решать задачи интуитивно по мере их возникновения. Чтобы добиться успеха в большом проекте, необ­ ходима четкая координация действий «команды», которая должна ра­ ботать по общей методологии, чтобы решить проблему комплекса требова­ ний и качества. Успешное управление требованиями заказчика может осу­ ществляться только эффективно организованной командой разработчиков.

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

232

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

Тем не менее определенные общие элементы присутствуют во многих успешных командах. Поэтому важно рассмотреть некую гипотетическую структуру команды.

Руководство крупным проектом ПС должны осуществлять один или два лидера — менеджера (см. рис. 9.2):

менеджер проекта — это специалист, обеспечивающий комму­ никацию между заказчиком и проектной командой, его задача — опреде­ лить и обеспечить удовлетворение требований заказчика;

менед:н€ер'архитектор комплекса программ — управляет ком­ муникациями и взаимоотношениями в проектной команде, является коор­ динатором создания компонентов, разрабатывает базовые, функциональные спецификации и управляет ими, ведет график проекта и отчитывается за его состояние, инициирует принятие критичных для хода проекта решений.

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

Специалисты первой категории непосредственно создают компо­ ненты и ПС в целом с заданными показателями качества. В процессе разработки их функции заключаются в тщательном соблюдении принятой в фирме технологии и в формировании всех предписанных руководствами исходных и отчетных документов. При этом предполагается, что выбран­ ная технология способна обеспечить необходимые значения конструктив­ ных показателей качества, а достижение заданных функциональных ха­ рактеристик гарантируется тематической квалификацией соответствую­ щих специалистов и регулярным контролем этих характеристик в процессе разработки. Система стандартизированного документирования частных работ должна обеспечить объективное отражение качества компонентов и процессов их создания на всех этапах ЖЦ ПС (см. лекцию 17).

Разделение труда специалистов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалифи­ кации и областям деятельности:

233

Лекция 9. Управление ресурсами в жизненном цикле программных средств

спецификаторы подготавливают описания функций соответству­ ющих компонентов с уровнем детализации, достаточным для корректной разработки текстов программ программистами и их интерфейсов;

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

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

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

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

документаторы процессов и объектов ЖЦ ПС обеспечивают под­ готовку и издание сводных технологических и эксплуатационных доку­ ментов в соответствии с требованиями стандартов.

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

234

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

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

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

В детальной модели СОСОМО (см. лекцию 5) значительное внима­ ние уделено влиянию организации и взаимодействия коллектива разра­ ботчиков на трудоемкость создания сложных программных средств — таблица 9.1. В составе организационных характеристик коллектива реко­ мендуется учитывать согласованность целей специалистов, участвующих в проекте, их психологическую совместимость и способность к дружной коллективной работе, наличие опыта работы в данном коллективе и дру­ гие объективные и субъективные свойства участников проекта. При этом большое значение могут иметь личная мотивация и психологические осо­ бенности поведения разных специалистов при комплексной работе над сложным проектом. Эти характеристики могут быть обобщены в качест­ венный показатель влияния сложности взаимодействия специалистов в

235

Лекция 9. Управление ресурсами в жизненном цикле программных средств

коллективе, которому сопоставлены коэффициенты изменения трудоем­ кости разработки ПС (последняя строка в таблице 9.1). Наилучшим счита­ ется непрерывное корректное взаимодействие организованных специали­ стов с большим опытом работы в данном коллективе при полной согласо­ ванности их целей, планов и методов работы. В остальных случаях в той или иной степени (даже в 3—5 раз) может возрастать трудоемкость разра­ ботки ПС, что нельзя не учитывать при прогнозировании ТЭП и обоснова­ нии разработки крупных проектов.

 

 

 

 

 

Таблица 9.1

Характеристики и влияние коллективизма разработчиков

программных средств на трудоемкость

 

Коллективизм

 

Значение характеристики

 

Очень

Низкий

Номи­

Высокий

Очень

 

низкий

нальный

высокий

 

 

 

Согласованность це­

Минималь­

Незначи­

Относи­

Значи­

Полная

лей коллектива

ная

тельная

тельная

тельная

 

1 Способность членов

Малая

Незначи­

Относи­

Значи­

Полная

коллектива адаптиро­

 

тельная

тельная

тельная

 

ваться к целям других

Нет

Малый

Незначи­

Значи­

Большой

Опыт работы в соста­

ве данного коллекти­

 

 

тельный

тельный

 

ва

 

В малой

 

 

 

Степень доверия и

Нет

В некото-

Значи­

Большая

взаимодействия в

 

степени

рои степени

тельная

 

коллективе

 

 

 

 

 

Обобщенная коллек­

Некоторое

Сложное

Зачастую

Высокая

Непре­

тивность работ

взаимодей­

взаимодей­

коллектив­

степень

рывное

 

ствие в кол­

ствие

ная работа

взаимо­

взаимо­

 

лективе

 

3,29

действия

действие

Обобщенный коэф­

5,48

4,38

1,10

0,00

фициент влияния коллективности работ на трудоемкость

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

236

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

тов ДОЛЖНЫ быть сосредоточены на контроле процессов и результатов выполнения работ и на принятии организационных и технологических мер для достижения их необходимого качества, обеспечивающего выпол­ нение всех требований технического задания на ПС.

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

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

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

237

Лекция 9. Управление ресурсами в жизненном цикле программных средств

получать и справедливо оценивать объективные данные испыта­ ний характеристик продуктов и систем качества при незаинтересованном проведении проверок;

относиться к персоналу системы качества, подвергающемуся про­ верке, таким образом, чтобы получить наилучшие результаты;

приходить к приемлемым для разработчиков и заказчика выводам, основанным на реальных наблюдениях в процессе испытаний характерис­ тик качества ПС.

Перечисленные выше специализации и квалификации персонала, уча­ ствующего в крупных проектах ПС, требуют соответствующей их под­ готовки, отбора и непрерывного обучения, которые являются самостоя­ тельной, важной проблемой проектирования и всего ЖЦ комплексов про­ грамм. Обучение представляет собой процесс и требует организации и сопровождения обучаемого персонала. Должны быть разработаны и доку­ ментированы планы, требования и цели обучения, а также разработаны руководства, включая материалы, используемые для обучения (см. шес­ тую часть стандарта ISO 15504). Персонал, ответственный за выполнение конкретных задач, если это необходимо, должен быть аттестован на основе соответствующего образования, подготовки и/или опыта работы. Может также стать необходимым включение в подготовку, ознакомление со специфической (проблемно-ориентированной) областью, в которой бу­ дет работать данное программное средство, и повышение квалификации в этой области. Требования к квалификации, обучению персонала и их реа­ лизации должны быть документально оформлены в системном проекте.

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

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

238

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

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

— установить правила проведения встречи и добиваться их выполне­

ния;

управлять течением дискуссии и удерживать команду на главной цели совещания;

способствовать процессу принятия решения и достижения консен­ суса, но избегать участия в содержательной части дискуссии;

удостовериться, что все заинтересованные лица участвуют и их пожелания учтены;

контролировать поведение участников, которое может привести к расколу или мешает продуктивной работе.

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

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

239