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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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