Керування спеціалістами при документуванніВажнейшим фактором при оценивании затрат на документирование в ЖЦ ПС являются люди - специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности, повышение требований и ответственности за качество документов комплексов программ привели к появлению новых требований к специалистам, обеспечивающим все этапы жизненного цикла ПС. Каждый специалист ограничен в своих возможностях, способностях и квалификации, что отражается на специфических дефектах результатов и документах его деятельности. Специалисты в соответствии со своей квалификацией и ролью в проекте вносят в него специфические дефекты и ошибки достаточно определенных категорий, что целесообразно учитывать при прогнозировании документов проекта. Разработка и документирование сложных ПС, особенно, на начальных и завершающих этапах, характеризуется высокой долей творческого труда. Дефекты, трудоемкость и длительность отдельных операций и частных работ существенно зависят от индивидуальных особенностей их исполнителей и характеристик конкретного проекта. Отсюда принципиальной особенностью планирования документирования комплексов программ является необходимость активного участия руководителей и заказчиков проектов в составлении планов на базе исследованных характеристик прототипов завершенных разработок ПС и их личного опыта. Недостатки или отсутствие достоверного обоснования необходимых ресурсов для документирования проектов новых ПС, являются причинами острых конфликтов между заказчиками и разработчиками. Поэтому целесообразно активно привлекать заказчиков к управлению документированием проектов, чтобы обеспечить своевременность разработки ПС в условиях ограниченных ресурсов. Необходимы согласия заказчиков при принятии основных решений, и только они могут реально определить, как получить комплекс программ с необходимой документацией высокого качества, выполненный в срок и в пределах бюджета. При разработке комплексов программ большими коллективами велика роль квалификации руководителей разработки, что непосредственно отражается на интегральных дефектах и документах проекта ПС. Руководство крупномасштабным проектом ПС должны осуществлять один или два лидера - менеджера с различными функциями - рис. 1.4:
Рис. 1.4 - менеджер проекта - этот специалист, обеспечивающий коммуникацию между заказчиком и проектной командой, его задача определять и обеспечивать удовлетворение требований заказчика с учетом согласованных с ним доступных ресурсов, и по возможности сокращать ошибки оценивания реальной сложности ПС и документов; - менеджер-архитектор комплекса программ и документации - управляет коммуникациями и взаимоотношениями в проектном коллективе, является координатором создания компонентов, разрабатывает базовые, функциональные спецификации и управляет ими, ведет график проекта и отчитывается за его состояние, инициирует принятие критичных для хода проекта решений, которые могут содержать соответствующие типы ошибок документов планирования и системного проектирования ПС. Уровень квалификации заказчика и корректность технического задания на разработку ПС может весьма сильно влиять на выделяемые ресурсы при создании комплекса программ. По тем или иным причинам даже при испытаниях заказчик зачастую обнаруживает, что решаются не совсем те задачи и не совсем так, как нужно, вследствие чего необходима переработка готовых программ, что отражается большим ущербом вследствие дефектов исходных требований заказчика (таблица 1.1). При проектировании и создании высококачественных комплексов программ, прежде всего, необходима организация и тесное взаимодействие представителей заказчика и менеджеров разработчиков проекта. Взгляды и требования заказчика, в основном, отражаются в функциональных и потребительских характеристиках и документах ПС. Устремления разработчиков направлены на возможность и способы их реализации с требуемым качеством. Эти различия исходных точек зрения на проект приводят к тому, что некоторые неформализованные представления тех и других имеют зоны неоднозначности и взаимного непонимания, отражающиеся на документах, что может приводить к конфликтам. Разработчики должны иметь в своем составе квалифицированных, проблемно-ориентированных аналитиков и системных архитекторов, способных переводить функциональные требования заказчика в конкретные документы, спецификации и технических требования к комплексу программ и его компонентам [13, 17, 26]. Им необходима высокая квалификация по архитектурному построению, комплексной отладке и испытаниям ПС определенных классов, умение организовать коллектив для решения общей целевой задачи системы. Это позволит на ранних этапах исключать или сокращать системные и алгоритмические дефекты документов, обусловленные различием представления ими целей и задач проектов, а также их показателей качества Таблица 1.1
Затраты труда при реализации и документировании крупномасштабного проекта ПС полезно распределить по двум категориям специалистов: разрабатывающим компоненты и ПС в целом и обеспечивающим технологию и качество программного продукта и документов. Организационное разделение специалистов, осуществляющих разработку ПС (первая категория), и специалистов, контролирующих и управляющих его качеством и документами в процессе разработки и всего ЖЦ (вторая категория), должно обеспечивать эффективное достижение заданных характеристик, а также независимый, достоверный контроль затрат ресурсов при разработке ПС. Специалисты первой категории непосредственно создают компоненты и ПС в целом с заданными показателями качества и документами. В процессе разработки их функции заключаются в тщательном соблюдении принятой в предприятии технологии и в формировании всех предписанных руководствами исходных, промежуточных и отчетных документов. При этом предполагается, что выбранная технология способна обеспечить необходимые значения конструктивных показателей качества продукта, а достижение заданных функциональных характеристик гарантируется тематической квалификацией соответствующих специалистов, регулярным контролем и сокращением возможных дефектов и ошибок в процессе разработки. Система стандартизированного документирования частных работ должна обеспечить объективное отражение качества компонентов и процессов их создания на всех этапах ЖЦ ПС [5, 15, 20]. Разделение труда специалистов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалификации и областям деятельности, каждая из которых характеризуется определенными типами документов и возможных дефектов (см. рис. 1.4): - спецификаторы подготавливают описания функций соответствующих компонентов с уровнем детализации, достаточным для корректной разработки текстов программ программистами и их интерфейсов, которые могут содержать преимущественно алгоритмические ошибки; - разработчики программных компонентов - программисты создают компоненты, удовлетворяющие спецификациям, реализуют возможности продукта, отслеживают и исправляют про дефекты и ошибки, при разработке сложных систем это требует детального знания методов, технологии и языков программирования а также проектирования баз данных; - системные интеграторы сложных проблемно-ориентированных ПС работают над проектами, в значительной степени, от личными от программистов методами, на разных языках проектирования, используют различные средства автоматизации и имеют на выходе различные документы крупных компонентов и комплексов программ, с соответствующими системными ошибок документов проектирования; - тестировщши обеспечивают проверку функциональных спецификации, систем обеспечения производительности, пользовательских интерфейсов, разрабатывают стратегию, выполняют и документируют тестирование для каждого компонента проекта ПС, должны быть административно независимыми от программистов и спецификаторов, характеризуются соответствующими уровнями оставшихся не выявленными программных, алгоритмических и системных ошибок документов; - управляющие сопровождением и конфигурацией, инструкторы интерфейсов отвечают за снижение затрат на модификацию и сопровождение продукта, обеспечение максимальной эффективности разработчиков по взаимодействию компонентов и реализации версий ПС, принимают участие в обсуждениях пользовательского интерфейса и архитектуры продукта, что также не может быть без ошибок проектирования, планирования и документирования проекта; - документаторы процессов и объектов ЖЦ ПС обеспечивают подготовку и издание сводных обобщающих технологических и эксплуатационных документов в соответствие с требованиями стандартов и возможными дефектами документов. Анализ и мониторинг характеристик, последствий и частости выявленных дефектов в документах конкретного комплекса программ может служить ориентиром для оценки индивидуальной квалификации и качества работы определенных специалистов. Следствием такого анализа может быть выделение некоторых специалистов, отличающихся большим числом дефектов, для их замены и дополнительного обучения с целью сокращения числа ошибок соответствующего типа. Накопление, классификация и обобщение характеристик дефектов определенных классов документов позволяет прогнозировать изменение ошибок по этапам развития жизненного цикла ПС, а также необходимое распределения состава и квалификации специалистов. При выборе заказчиком надежного поставщика-разработчика проекта необходима оценка тематической и технологической квалификации возможного коллектива специалистов, а также его способности реализовать проект с заданными требованиями и качеством документации. Тематическую квалификацию специалистов в области создания ПС определенного функционального назначения приближенно можно характеризовать средней продолжительностью работы в данной проблемной области основной части команды, непосредственно участвующей в разработке алгоритмов, спецификаций, программ, баз данных и документов. Важнейшую роль играет комплексная квалификация руководителей - менеджеров разработки и системных аналитиков функциональных компонентов, и в меньшей степени непосредственных разработчиков программ в конкретной прикладной области. Особенно важна не индивидуальная характеристика каждого специалиста, а, прежде всего, интегральный показатель квалификации «команды», реализующей некоторую, достаточно крупную функциональную задачу или весь проект. При низкой тематической квалификации допускаются наиболее грубые системные ошибки, требующие больших затрат при доработке программ или даже делающие проект практически не реализуемым [18, 19,25]. Специалисты второй категории - технологи, обслуживающие и сопровождающие технологический инструментарий документирования, который применяется специалистами первой категории, обеспечивают применение системы качества проекта или предприятия, контролируют и инспектируют ее использование. Основные задачи второй категории специалистов должны быть сосредоточены на контроле процессов, затратах ресурсов, результатах выполнения работ, а также на принятии организационных и технологических контрмер для достижения их необходимого качества, обеспечивающего выполнение всех требований технического задания на ПС и документацию. Технологи должны выбирать, приобретать и осваивать наиболее эффективный инструментарий для проектов, реализуемых конкретной фирмой с учетом особенностей создаваемых ПС требуемого качества и рентабельности технологических средств. Они должны разматывать регламентированный технологический процесс и систему качества, поддерживающие весь ЖЦ ПС и обучать разработчиков ПСквалифицированному применению соответствующих инструментальных средств, документации и технологий. Специалисты, непосредственно управляющие обеспечением качества ПС и документов, должны овладеть стандартами и методиками предприятия, поддерживающими регистрацию, контроль, документирование и воздействия на выявление дефектов на всех этапах ЖЦ комплекса программ. Они должны обеспечивать эксплуатацию системы качества проекта, выявление всех отклонений от заданных показателей качества объектов, процессов и документов, а также от предписанной технологии на промежуточных и заключительных этапах разработки. Для сокращения и устранения дефектов документов проекта посредством адекватных контрмер необходима четкая организация коллектива специалистов и автоматизация процессов исправления дефектов, которые позволяют избегать множества вторичных ошибок, обусловленных недостаточной координацией проводимых корректировок и формирования новых версий сложных ПС и документов. Этому должна способствовать утвержденная дисциплина и иерархия принятия решений на координированные изменения компонентов и ПС в целом, должностными лицами проекта, поддержанная методами и средствами защиты от несанкционированного доступа при выполнении корректировок документов специалистами различной квалификации и права доступа к модификациям компонентов на разных уровнях проекта (см. п.1.5). Следует установить полномочия специалистов или групп для санкционирования и выполнения изменений документов - контрмер на каждом уровне разработчиков ПС (например, программист, аналитик, руководитель группы программистов, менеджер проекта, заказчик - таблица 1.2). В контрмеры входит последовательность работ, которые необходимо выполнить для того, чтобы: запросить разрешение на изменение; обработать запрос на изменение; проследить вменение; распределить изменения и сопровождать предыдущие версии программного продукта и документации. Изменения, которые воздействуют на продукт, уже находящийся на эксплуатации, должны быть предоставлены заказчику в соответствии с установленными контрактом формами и процедурами.
Таблица1.2
На основе проведенного анализа персонал разработки должен разрабатывать варианты реализации изменений и документально оформлять: сообщение о каждом дефекте или заявку на внесение изменений; результаты их анализа и варианты реализации изменений, оценку их влияния на функциональную пригодность. Следует согласовывать с заказчиком выбранные варианты изменений документов в соответствии с договором. Регистрация и учет истории этого процесса обеспечивает возможность его контроля и пошагового восстановления выполненных изменений (отката) документов для выявления вторичных дефектов, внесенных в процессе разработки очередной версии. Такие дефекты обычно обусловлены одновременным, не скоординированным внесением групп изменений документов несколькими специалистами или потерей некоторых корректировок в определенной версии ПС. Если предполагается, что программный продукт будет иметь длительный, жизненный цикл поддержки или ожидаются значительные корректировки в ЖЦ ПС, то следует рассмотреть и учесть наиболее детальные требования к методике организации и к коллективу ответственному за совершенствование и документирование программ. В стратегии сопровождения документов следует учесть характеристики системы: количество компонентов программного средства, типы, размер, критичность и безопасность создаваемых и применяемых программных продуктов и документов. Для конкретного проекта они должны быть определены и зафиксированы в Программе управления конфигурацией ПС. Управление конфигурацией ПС - это процессы (см. стандарты ISO 12207, ISO 15846, ISO 14764): - оценивания состояния версий программных средств, их дефектов и документов; - идентификации, определения и базирования конфигурации - планирования процедур управления конфигурацией ПС и его - управления, модификацией и выпуском версий программных Цель конфигурационного управления документацией при создании сложных систем, состоящих из многих компонентов (единиц конфигурации), каждый из которых может иметь разновидности или версии, обеспечить управляемое и контролируемое развитие их структуры, состава компонентов и функций, а также сокращение Дефектов в течение всего жизненного цикла ПС и документов. В процессе организации конфигурационного управления необходимо построить и использовать компактные и наглядные схемы однозначной иерархической идентификации и изменения компоненте и документов ПС (рис. 1.5):
Рис. 1.5
- объектов - модулей и компонентов ПС разного уровня интеграции, подвергающихся корректировкам (систему идентификации адресации изменений в комплексе программ и в документах); - корректировок содержания и взаимодействия проводимых изменений, которая должна обеспечивать возможность однозначного контроля, истории развития модификаций компонентов любого уровня, во времени и в пространстве элементов версий комплекса программ (типы, содержание и взаимосвязь корректировок документов); - специалистов, участвующих в конфигурационном управлении и сокращении дефектов, их права на доступ к определенным компонентам ПС и документам на конкретных стадиях разработки, реализации и утверждения изменений (см. табл. 1.2). В процессах совершенствования сложных ПС и документации участвует большое число специалистов различных направлений и квалификации, которые при необходимости могут объединяться в единый коллектив - службу сопровождения, управления конфигурацией программного продукта и документов. Менеджер проекта является высшим должностным лицом, принимающим важнейшие решения по внесению изменений и корректировке конфигурации сложных ПС и документов. Он взаимодействуют с заказчиком и пользователями, определяющими разработку или эксплуатацию ПС, для согласования изменений в системе, в контракте и в техническом задании. Заказчик системы должен оценивать и утверждать наиболее крупные изменения, заметно влияющие на условия контракта, технические требования или стоимость проекта ПС. Организационная структура коллектива специалистов при корректировках сложных комплексов программ должна учитывать: цели и функции управления конфигурацией; взаимодействующие организации; службы проектирования, закупок и контрактов; систему обеспечения качества и другие средства, которые могут быть привечены, охватывая, если необходимо, субподрядчиков и поставщиков. Она должна определять связи между различными видами деятельности, непосредственно входящими в процесс управления конфигурацией, обеспечивать координацию действий с другими работами, а также распределение соответствующих полномочий и ответов за все действия по управлению корректировками документов. При организации сложного проекта следует идентифицировать инстанцию, уполномоченную утверждать конфигурационные базы программных продуктов и документов для поставки заказчику и пользователям, и любые изменения к ним. В процессе эксплуатации версий ПС у каждого пользователя могут появляться некоторые претензии к функционированию, которые квалифицируются им как ошибки или дефекты эталонной или собственной версии. Для общения с пользователями и накопления информации о выявляемых недостатках в широко тиражируемых сложных ПС целесообразно выделение группы специалистов высокой квалификации, овладевших всеми функциональными возможностями данного ПС. От пользователей или заказчика могут поступать также предложения по внесению изменений в версию для улучшения эксплуатационных характеристик и расширения функциональных возможностей ПС. Аналогичные предложения могут поступать от разработчиков комплекса программ. Для оценки предложений полезно экспериментальное тестирование предварительных вариантов изменений версии ПС и документов (см. рис. 1.5). Структура коллектива разработчиков, обычно, в значительной степени отражает структуру разрабатываемого ПС. Особенно это заметно при создании крупных комплексов программ размером 105 - 10 6 строк. При этом группы функциональных программ локализуются по соответствующим группам специалистов с целью минимизации связей и упрощения взаимодействия, как между группами разработчиков, так и между создаваемыми ими программами и документами. Для реализации мероприятий по планированию и управлению жизненным циклом и документированием концептуально целостных, крупномасштабных ПС и обеспечения их качества в пределах допустимых затрат, необходимы организационные действия менеджеров и системных архитекторов, направленные на подбор и обучение коллектива специалистов разных категорий и специализаций. Перечисленные выше специализации и квалификации персонала (см. рис. 1.4), участвующего в крупномасштабных проектах ПС, требуют соответствующей их подготовки, отбора и обучения. Должны быть разработаны и документированы планы проекта, требования и цели обучения, а также разработаны руководства, включая документы, используемые для обучения (см. шестую часть ISO 15504, [15]). Персонал, ответственный за выполнение конкретных чада4 с высоким риском [14, 23, 28] должен быть аттестован, если это необходимо, на основе соответствующего образования, подготовки и/или опыта работы. Оценка размера будущего продукта и комплекса документации является весьма важной, поскольку она является частью одной наиболее сложной задач проекта: установки реальных ориентиров затрат для заказчика. Нереальные ожидания, основанные на неточных оценках требуемых ресурсов, представляют собой одну из частых причин провала проектов вследствие высоких рисков ограничения ресурсов. Зачастую причина кроется не в недостаточной производительности команды специалистов проекта, а в неточном предвидении уровня её уровня, и размера документации проекта. Так как величина и достоверность определения размера проекта ПС ключевой фактор последующего анализа влияния ограничений ресурсов, то целесообразно применять несколько доступных методов для его оценивания. Конкретизация функций, структуры ПС, состава компонентов проекта позволяет более достоверно определить размеры групп программ и, суммируя их, рассчитать размер всего комплекса программ и документов. Кроме того, на этом этапе повышается возможность выбора и использования аналогов данного проекта, так как становятся более определенными задачи, функции и компоненты разрабатываемого ПС, для которого желательно найти аналоги с известными апробированными характеристиками. Особенно сильно на снижение суммарных затрат влияет использование готовыx компонентов и документов из предшествующих разработок. При анализе аналогов могут быть выделены компоненты, пригодные Для повторного применения в новом проекте. Это позволяет оценить возможную долю использования готовых компонентов и тем самым определить эффективный размер комплекса программ и документов, подлежащий непосредственной разработке.
|
