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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-13