ПОДГОТОВКА КОЛЛЕКТИВА СПЕЦИАЛИСТОВ ДЛЯ ПРОЕКТИРОВАНИЯ И ПРОИЗВОДСТВА ЗАКАЗНЫХ ПРОГРАММНЫХ ПРОДУКТОВ

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

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

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

Необходимо обучение профессиональных коллективов специалистов современной программистской культуре промышленного создания крупных высококачественных программных продуктов - умению формализовать требования и достигать конкретные значения характеристик функционирования и применения сложных комплексов программ, с учетом тех ресурсов, которые доступны для обеспечения и совершенствования качества. Для этого при обучении необходимо воспитывать у каждого специалиста ряд коллективных профессиональных свойств - рис. 1.4 [1,9,10,28].

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

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

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

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

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

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

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

Рис. 1.3

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

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

Руководителю разработки программного продукта недостаточно быть хорошим управленцем, он должен стать признанным лидером. Для этого необходимо: признание коллективом профессиональной компетентности и превосходства руководителя и доверие коллектива к действиям и решениям руководителя; признание его исключительных человеческих качеств, убежденность в его честности, порядочности, вера в его искренность и добросовестность. В зависимости от состава, квалификации и ситуации задач коллектива у лидера могут быть различные стратегии руководства при назначении', руководителем в новый коллектив; в известный слаженный дружественный коллектив; в коллектив, настроенный критически; где каждый сам себе может быть руководителем. Во всех ситуациях лидер обязан последовательно организовать эффективно действующий производственный коллектив [1,10,21].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.4

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

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

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

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

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

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

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

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

Менеджеры, руководители-разработчики должны применить методы и процессы для того, чтобы понять решаемую проблему заказчика rq начала производства программного продукта (см. рис. 1.4). Для этого следует использовать анализ, выявление и освоение проблемы и интересов заказчика.

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

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

• интервьюирования и анкетирования - создание структурированных интервью;

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

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

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

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

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

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

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

Исходные требования к комплексу программ могут быть представлены и согласованы в составе спецификации всей системы. Если программный продукт нуждается во взаимодействии с другими программными или аппаратными продуктами, то в спецификации требований должны быть оговорены непосредственно или при помощи ссылок интерфейсы между разрабатываемыми и другими применяемыми продуктами. При заключении контракта спецификация сложных требований может быть определена не полностью, она может быть доработана в ходе реализации проекта. При разработке заказчиком и руководителем проекта требований технического задания на крупный комплекс программ должны учитываться общесистемные ограничения, которыми могут быть [1, 10]:

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

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

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

Руководителем проектирования программного продукта в зависимости от особенностей продукта может быть: менеджер продукта, менеджер проектирования, руководитель проекта. Лидер - руководитель проектирования должен уметь.

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

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

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

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

Состав основных требований к программному продукту:

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

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

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

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

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

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

Руководитель должен уметь подготовить укрупненные планы по каждому виду профессиональной деятельности ква-

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

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

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

Совокупные относительные затраты на автономную и комплексную отладку, а также на испытания крупных динамических комплексов программ приблизительно одинаковые и составляют по трудоемкости и по длительности около 30%. Эти соотношения имеют тенденцию медленно снижаться за счет развития современных технологий, инструментальных средств автоматизации и повышения качества начальных этапов проектирования и производства. Необходимость проведения комплексиро-вания и динамического тестирования в реальном времени может привести к меньшему улучшению экономических характеристик для класса программ реального времени при активном внедрении средств автоматизации разработки.

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

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

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

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

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

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

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

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

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

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

Глава 1.3.

ПРОЕКТИРОВАНИЕ ТРЕБОВАНИЙ

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >