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

2016-01-26

462

Обсуждений (0)

0.00 из 5.00 0 оценок

⇐ Предыдущая 13 14 15 16 171819 20 21 22 Следующая ⇒

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

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

Рис. 9.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 9.1

2016-01-26

462

Обсуждений (0)

0.00 из 5.00 0 оценок

⇐ Предыдущая 13 14 15 16 171819 20 21 22 Следующая ⇒

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

Обсуждений еще не было, будьте первым... ↓↓↓