Методологические основы

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

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

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

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

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

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

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