Архитектура

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

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

Глоссарий

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

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

Инструментарий

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

Исходный код

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

Коллективное владение кодом. Подход хорошо описан в литературе по экстремальному программированию (XP), и в теории обладает целым рядом преимуществ, включая непрерывный обмен знаниями о системе, взаимозаменяемость участников команды, однообразие получаемого кода и непрерывное его улучшение. На практике, чтобы получить все эти преимущества, надо иметь либо по-настоящему сплоченную команду единомышленников, либо ограничиться вариантом, когда один ведущий разработчик выдает конкретные задания нескольким исполнителям и сам определяет степень их вмешательства в работу друг друга. С моей точки, коллективное владение кодом подходит лишь для очень небольших команд – от 1 до 5 человек. В любом случае надо быть готовым к тому, что коллективное владение кодом очень быстро может превратиться в бесконтрольное. В самом плохом сценарии это приведет к тому, что одни разработчики будут исправлять написанный другими код, не вникая в его детали или откатывать сделанные другими изменения, другие будут до последнего защищать свою часть кода от вмешательства со стороны. Такая ситуация порождает безответственность и напряженные отношения в группе. Каждый пишет свою часть кода. Разделяя зоны ответственности программистов, мы имеем плюсы в виде довольных программистов, часто предпочитающих работать в одиночку, и персональной ответственности за выделенную часть функциональности. Однако недостатков тоже хватает: каждый программист зачастую пишет в своем стиле, плохо понимает чужой код, а потому, когда один программист уходит из проекта, его код иногда оказывается невозможно сопровождать. Кроме того, малое внимание уделяется взаимодействию модулей, написанных разными программистами, которых больше заботит внутреннее устройство модуля, чем его интеграция с модулями других разработчиков. Худшей комбинацией обоих подходов видится мне ситуация, когда один разработчик пишет код, другой исправляет ошибки. В этом случае получаем безответственность первого программиста и разочарование второго. Должен отметить, что если исправить ошибку в собственном коде для программиста – дело чести, то доделывать некачественную работу других – крайне неприятное занятие. Наиболее привлекательной мне кажется другая комбинация подходов, возможная при компонентной архитектуре: каждый компонент разрабатывается только одной локальной командой, внутри команды – коллективное владение кодом. Взаимозаменяемость и обмен знаниями обеспечивается на уровне каждой команды, причем локальность команды гарантирует быстрое и безболезненное решение возможных спорных вопросов. Границы компонентов препятствуют непосредственному вмешательству одной команды в работу другой. В то же время ориентация на компонентную архитектуру предполагает, что вопросам взаимодействия компонентов (интерфейсам) будет уделено должное внимание.

о том, какую информацию сделать

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

Электронная почта

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

Методология разработки

Это один из тех вопросов, по которым людям может быть сложнее всего договориться. Когда для одного наилучшим подходом будет казаться экстремальное программирование, другой будет поднимать вопрос о недостатке документации и протестовать против изменения требований. Здесь у каждого найдется свой личный опыт и собственное видение ситуации. Споры могут продолжаться вечно. Мое мнение – право окончательного решения по таким вопросам должно быть только у одного человека. Авторитет этого человека должен быть достаточно высоким.

Недоверие

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

Области коллективного владения

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

Общий сетевой ресурс

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

Ощущение, что все лучше, чем на самом деле

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

Ответственность команд

Логичное следствие из предыдущего пункта. Если в проекте участвует несколько команд, нужно знать, какая команда за что отвечает и кто является контактным лицом от каждой команды.

Пересекая границы: специфика разработки ПО распределенной командой

,

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

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

Планы и бизнес-цели

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

Проблемные участки

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

Процедура внесения изменений в исходный код (Check-in)

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

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

Простейший web-ресурс с фото и краткой информацией о каждом участнике проекта

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

Система хранения документов

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

Система контроля версий

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

Системы учета заданий и ошибок (Tasktracking, Bugtracking systems)

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

Skype, Icq и другие системы мгновенного обмена сообщениями

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

Способы коммуникации

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

Структура команды

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

Текущая сборка (Build)

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

Телефон

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

Требования

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

Треккеры

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

Управляющая информация

В любом проекте самым надежным каналом связи всегда будет канал «управляющий центр – подчиненные подразделения» («Руководитель – исполнители»). Если отсутствие связи между участниками команды еще можно себе представить, то отсутствие связи с руководителем означает, что проект скорее мертв, чем жив. Наряду с управляющим воздействием, по этим каналам можно распространять и информацию, рассчитывая на то, что она действительно дойдет до всех членов команды.

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

Видеоконференция

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

возникают не только от физической

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

Живой контакт

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

Знания о разрабатываемой системе

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

Узнавание по факту. Т.е. один сделал – все остальные видят, когда попадается на глаза. Такой подход говорит о том, что взаимодействия между участниками команды нет вообще. Наиболее вероятным следствием станет то, что разрабатываемое приложение будет состоять из разнородных частей, слабо сочетающихся друг с другом. Неформальная передача информации. Существенно отличается от предыдущего варианта тем, что здесь речь как раз идет о постоянной коммуникации внутри команды. В таких условиях знания передаются легко и быстро, а излишний формализм только препятствует этому процессу. Чтобы добиться такой коммуникации, недостаточно, однако, посадить всех членов команды в одну комнату, хотя это и совершенно необходимо. (Конечно, надо разделить технических и нетехнических специалистов). Ведение проектной документации. При всем желании, в документацию, в первую очередь, попадают самые важные и наиболее общие решения. Если документация достаточно детализирована, скорее всего, она будет неактуальной – на поддержание ее в актуальном состоянии требуется слишком много времени и сил. Это главная из причин, по которой многие не придают документации большого значения. Надо согласиться, полностью заменить непосредственное общение документация не сможет. В то же время, отдельные документы могут быть чрезвычайно полезны. Кстати, самые нужные и полезные документы часто возникают сами собой, когда люди записывают что-то «для себя», а потом оказывается, что это давно нужно всем.
Я бы предпочел создавать документы только по мере необходимости, всегда обсуждая этот вопрос с группой разработки. Рассылка информации о принятых решениях по электронной почте. Один из наиболее частых вариантов, подходящий для информирования о более-менее крупных решениях. Присущи все недостатки коммуникации по электронной почте. Живого контакта в любом случае не заменяет, в то же время, рассылаемая таким образом информация чаще всего все равно попадает в документацию. В общем, рассылка - она рассылка и есть. Регулярные встречи. Первый вопрос – насколько регулярные. В команде, которая встречается раз в неделю, накапливается столько нерешенных частных вопросов, что удержаться в рамках регламента может быть очень сложно. Встречи с периодичностью раз в месяц, скорее всего, будут посвящены только самым общим организационным вопросам. Так или иначе, многие, особенно технические вопросы бывает гораздо удобнее обсудить «в процессе», чем на специально назначенном совещании. Почти все технические решения необходимо проверять на реализуемость и эффективность, их часто приходится корректировать и пересматривать много раз. Неформальная передача информации внутри команды и регулярные встречи представителей отдельных команд. Подход выглядит привлекательно в случае, если разрабатываемое приложение имеет компонентную архитектуру. Внутри команды знания распространяются благодаря ежедневным совместным обсуждениям и коллективному владению кодом, интерфейсы на компоненты разрабатываются и утверждаются на общих встречах представителей команд. Границы компонентов в этом случае могут определяться исходя из естественных ограничений на объем информации, которую каждая команда может охватить одновременно.

Литература

Боэм Б.У. Инженерное проектирование программного обеспечения. Пер. с англ. /Под ред. А.А. Красилова. – М.: Радио и связь, 1985. 512 стр.

Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения. Пер. с англ. – СПб.: БХВ-Петербург. 2005. 832 стр.

Липаев В.В., Потапов А.И. Оценка затрат на разработку программных средств. – М.: Финансы и статистика. 1988. 224 стр.

Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств. – М.: СИНТЕГ. 2004. 284 стр.

Липаев В.В. Программная инженерия. Методологические основы. Учебник. – М.: ТЕИС. 2006. 608 стр.

Организация производства и управления предприятием. Учебник. Под ред. О.Г. Туровца. – М.: ИНФРА-М. 2006. 544 стр.

Соммервилл И. Инженерия программного обеспечения. 6-е издание. Пер. с англ. – М.: Вильямс. 2002. 624 стр.

Фатрелл Р. Т., Шафер Д. Ф., Шафер Л. И. Управление программными проектами: достижение оптимального качества при минимальных затратах. Пер. с англ. – М.: Вильямс. 2003. 1136 стр.

Экономика промышленного предприятия. Учебник. Под ред. Е.Л. Кантора. – М.: МарТ. 2007. 864 стр.

Boehm B.W. et al. Software cost estimation with COCOMO II. Prentice Hall PTR. New Jersey. 2000. 506 стр.

Grady R. Practical software metrics for project management and process improvement. – Englewood Cliffs. NY. Prentice-Hall. 1992. 376 стр.

Jones C. Applied software measurement, assuring productivity and quality. McGraw-Hill. NY. 1996. 432 стр.

Londeix B. Cost estimation for software development. Cornwall: Addison-Wesley. 1987. 312 стр.

Особенности экономики производства крупных программных продуктов

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

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

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

Эти сценарии принципиально различаются методами

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

возможной эффективности

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

к стоимости (цене, затратам), которую готов заплатить пользователь при приобретении и эксплуатации данного программного продукта.

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

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

Однако для заказчика и разработчиков при заключении контракта необходимо достаточно достоверное прогнозирование требований к программному продукту и экономическое обоснование необходимых ресурсов

по трудоемкости, стоимости, срокам и другим показателям.


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

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

Методы и достоверность экономического анализа производства и

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


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

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

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

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


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

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

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


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

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

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

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

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

Наиболее полно и подробно основные закономерности и влияние факторов на экономические характеристики процессов разработки в 80-е годы представлены в [1] для более десяти моделей прогнозирования. В 1981-м году на основе исследования процессов разработки 63 программных продуктов была опубликована модель прогнозирования под названием КОМОСТ [1]. В последующем эта модель была развита, детализирована и опубликована как СОСОМО, а в 2000-м году – под названием СОСОМО II [10]. В этой модели на основе анализа более 160 реальных проектов разработки комплексов программ различной сложности уточнены рейтинги влияния выделенных факторов на основные экономические характеристики.

Кроме того, в 1988-м году были опубликованы [3] результаты анализа экономических характеристик (комплексный проект ПРОМЕТЕЙ) на основе обобщения результатов разработки свыше 250 отечественных проектов сложных программных продуктов. В общем случае для оценки экономических характеристик новых проектов необходимы следующие исходные данные:

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

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

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

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


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

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

[2, 5, 7, 8].

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

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


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

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

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

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

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

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

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

Стратегической проблемой в жизненном цикле современных систем стало обеспечение и совершенствование качества производства

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

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

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

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

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

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

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

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

Неопределенность применяемых понятий, требований и характеристик качества

присущая крупным, наукоемким проектам комплексов программ, а также многочисленные спекуляции разработчиков на их значимости приучили заказчиков не доверять рекламируемым достоинствам программных продуктов [7, 8].


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

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

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

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


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

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

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

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



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

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

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

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

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

к программам для ЭВМ исторически

Во многих предприятиях и ВУЗах отношение к программам для ЭВМ исторически базируется на подходе, как к «искусству и художественному творчеству» отдельных специалистов (программирование «в малом»). При этом считается, что невозможно применять, какие-либо экономические характеристики для определения и прогнозирования стоимости и результатов такого творчества, и они оцениваются только с позиции выполняемых функций и «эстетики»
их реализации. Такие программы не предназначены для массового тиражирования и распространения как программного продукта на рынке, их оценивают качественно и интуитивно, преимущественно, как “художественные произведения”. При этом, как правило, нет конкретного независимого заказчика-потребителя, определяющего требования к программам и их финансирование, программы не ограничиваются заказчиком допустимой стоимостью, трудоемкостью и сроками их создания, требованиями обеспечения заданного качества и документирования. Их разработчики не знают и не применяют регламентирующих, нормативных документов производства, вследствие чего жизненный цикл таких изделий имеет непредсказуемый характер по структуре, содержанию, качеству и стоимости основных результатов творчества. Их создание не определяется экономическими характеристиками и регламентированными производственными процессами и далее не рассматривается.
Для небольших относительно простых проектов программных средств, во многих случаях достаточно достоверными могут быть интуитивные оценки требуемых экономических ресурсов, которые выполняются опытными руководителями, реализовавшими несколько аналогичных проектов. Однако интуитивные оценки руководителями
размеров и сложности крупных программных проектов (программирование «в большом»), как правило, отличаются большими ошибками при планировании экономических характеристик —
сроков, трудоемкости и стоимости создания продуктов. Это во многих случаях приводит к значительному запаздыванию завершения разработок и к превышению предполагавшихся затрат.
Практика последних лет показывает, что вследствие пренебрежения тщательным экономическим обоснованием до 15% проектов сложных программных комплексов не доходит до завершения, а почти половина проектов не укладывается в выделенные ресурсы, бюджет и сроки, не обеспечивает требуемые характеристики качества. Типичны ситуации, когда отставание сроков внедрения промышленных систем управления и обработки информации полностью зависит от неготовности для них программных продуктов.
Приступая к разработке сложных программных проектов, заказчики и исполнители, прежде всего, должны пытаться понять, целесообразно ли экономически создание соответствующих продуктов, и оценить, какова будет возможная эффективность применения готового продукта, оправдаются ли затраты на его разработку и использование. Поэтому такие технические проекты традиционно должны начинаться с анализа и разработки экономического обоснования предстоящего жизненного цикла предполагаемого продукта. Заказчику проекта необходимо оценивать реальную потребность в создании продукта и возможную конкурентоспособность, а потенциальному разработчику предполагаемого продукта – проводить оценку реализуемости проекта в условиях и ресурсах, предлагаемых заказчиком. Часто разработчики не в состоянии привести заказчику или руководителю проекта достаточно обоснованные доказательства нереальности выполнения выдвигаемых требований к продукту при предложенных ограниченных значениях бюджета и сроков. Это, как правило, означает, что программная часть системы с самого начала выходит из-под экономического контроля, и возможна катастрофа с реализацией и завершением проекта всей системы в требуемый срок с заданным качеством.
Массовое создание сложных и дорогих программных продуктов промышленными методами и большими коллективами специалистов вызвало необходимость их достоверного экономического анализа и оценки, четкой организации производства, планирования работ по затратам, этапам и срокам реализации. Для решения этих задач еще в 1980-е годы


начала формироваться новая область знания и инженерная дисциплина — экономика производства крупных программных продуктов
[]. Необходимо было научить специалистов анализу и оцениванию конкретных факторов, влияющих на экономические характеристики проектов программных продуктов со стороны реально существующих и потенциально возможных воздействий, а также ограничений ресурсов проектов комплексов программ. Это привело к появлению новой области экономической науки и практики — экономики производственных процессов и жизненного цикла сложных рограммных продуктов как части экономики промышленности и вычислительной техники в общей экономике предприятий и государства. Ее основной задачей является прогнозирование, эффективное управление, распределение ресурсов и экономное использование необходимых быстро возрастающих капиталовложений в производство сложных комплексов программ высокого качества и различного назначения.
Развитие этой области экономики связано с большими трудностями, типичными для новых разделов науки и техники, появляющихся на стыке различных областей знания. В данном случае особенности состоят в том, что менеджеры и разработчики комплексов программ, как правило, не знают даже основ экономики промышленного производства сложной продукции, а экономисты современного производства
не представляют сущность и свойства объектов разработки — программных продуктов, а также особенностей экономики технологических процессов их проектирования, производства и применения. Объективно положение осложнено трудностью измерения экономических характеристик таких объектов. Широкий спектр количественных и качественных показателей, которые с различных сторон характеризуют содержание компонентов и комплексов программ, и невысокая достоверность оценки их значений определяют значительную дисперсию при попытке описать и измерить свойства создаваемых сложных программных продуктов для их экономического прогнозирования и оценки.
Крупные программные продукты являются одними из наиболее сложных объектов, создаваемых человеком, и в процессе их производства творческая работа специалистов – поиск новых методов, альтернативных решений и способов осуществления заданных требований, а также формирование и декомпозиция этих требований – составляет значительную часть всех трудозатрат.


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


Основной целью производства многих программных продуктов является повышение эффективности промышленных систем обработки информации и/или управления объектами, в которых применяются сложные комплексы программ. Такими системами могут быть средства автоматизированного управления самолетами, системами вооружения или электростанциями, информационно-справочные системы административного управления, системы автоматизации проектирования и обучения. В ряде случаев программные продукты невозможно или очень трудно характеризовать непосредственной экономической эффективностью. Примером могут служить комплексы программ в административных системах, в системах управления воздушным движением или космическими аппаратами, а также военного назначения или автоматизации научных экспериментов. В таких случаях при анализе программ невозможно определять прямую экономическую эффективность систем в зависимости от затрат ресурсов, и целесообразно исключать из анализа характеристики эффективности программных продуктов. В результате исследование экономической эффективности создания комплексов программ приходится проводить по величине затрат ресурсов на производство программного продукта
в предположении, что обеспечена реализация заданных их функциональных характеристик с требуемым качеством.
Зачастую при экономическом анализе проектирования и производства предполагается [, , ], что для продукта зафиксирован эффект от его создания и использования, и необходимо выявить все основные факторы, способствующие минимизации совокупных производственных затрат на всем жизненном цикле. Для этого должен быть подготовлен согласованный между заказчиком и разработчиком утвержденный документ, в котором определяются цели и задачи проекта, требуемые характеристики продукта и доступные экономические и другие ресурсы для его реализации. Эти данные должны быть предварительно сбалансированы, и они должны обеспечивать реализацию целей проекта при выделенных ресурсах с минимальным допустимым риском. Однако масштабы целей и функций сложных программных проектов имеют устойчивую тенденцию изменяться и увеличиваться по мере развития, а первоначально выделяемые ресурсы – не удовлетворять их реализацию. Экономическое обоснование проектов на начальном этапе их развития должно содержать оценки рисков реализации поставленных целей, обеспечивать возможность планирования и выполнения жизненного цикла (ЖЦ) программного продукта или указывать на недопустимо высокий риск его реализации и целесообразность прекращения разработки.Большую часть рисков и негативных последствий производства можно избежать, используя существующие методы оценивания и прогнозирования производственных затрат, а также управления проектами программных продуктов для их успешного завершения.

За последние годы ряд исследований

За последние годы ряд исследований и работ по сбору и обобщению экономических данных о производстве программных продуктов
заложили основы для методов и моделей оценивания затрат [1, 10, 13]. Имеющиеся модели не всегда точны, как хотелось бы, но могут весьма существенно помочь в экономическом анализе и обосновании решений при создании сложных программных продуктов. Для сбора и обобщения экономических характеристик о производстве программных продуктов необходимо детально исследовать требуемые ресурсы для современных процессов создания и использования комплексов программ различных классов и назначения. Необходимы активные исследования на разных уровнях детализации, начиная от экономики и планирования создания программных продуктов в масштабах страны или предприятия и кончая экономикой выполнения частных операций отдельными специалистами при проектировании или производстве компонентов и конкретных продуктов. Одна из важнейших задач состоит в том, чтобы увязать четкими экономическими категориями взаимодействие разных специалистов и предприятий в типовой производственной цепочке: заказчик—разработчик — изготовитель—пользователь. Для этого объект — программный продукт – и все процессы взаимодействия в цепочке должны быть связаны системой экономических и технических характеристик, в той или иной степени использующих основные экономические показатели — реальные затраты ресурсов: финансов, труда и времени специалистов, затрачиваемых на создание конечного продукта.
Проблема состоит в создании и представлении специалистам современных методов экономического анализа, оценивания и прогнозирования необходимых ресурсов при производстве комплексов программ.
Тем самым, должен быть выделен очень важный, базовый раздел из всей экономики жизненного цикла программных комплексов. Такое выделение определяется тем, что без подобных базовых исследований имеющихся прототипов вряд ли возможно последующее серьезное развитие экономики в этой отрасли. Внимание должно быть сосредоточено на концептуальной основе распределения затрат труда в процессе разработки компонентов и комплексов программ, на факторах, определяющих реальные трудозатраты и другие экономические характеристики, а также на исследовании их в реализованных современных разработках.


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

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

Использование инструментальных средств при адаптации и реализации СТАНДАРТА преследует следующие цели:

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

В проектах внедрения процесса сопровождения ЖЦ ПС целесообразно использовать инструментальные средства фирмы Rational/IBM, представленные в Таблице 1.

Таблица 1. Использование инструментальных средств при адаптации и реализации СТАНДАРТА

Инструментальное средство

Адаптация процесса

Реализация процесса

Rational Process Workbench	Автоматическая генерация контента веб-сайта
Rational Rose	Разработка модели процесса сопровождения	Выполнение задач проектирования в процессе сопровождения
Rational SoDA	Создание отчетов на основании данных, содержащихся в репозиториях инструментальных средств Rational	Создание отчетов на основании данных, содержащихся в репозиториях инструментальных средств Rational
Rational ClearCase	Выполнение задач конфигурационного управления при адаптации	Выполнение задач конфигурационного управления в процессе сопровождения
Rational ClearQuest	Выполнение задач управления изменениями при адаптации	Выполнение задач управления изменениями в процессе сопровождения
Rational RequisitePro	Выполнение задач управления требованиями при адаптации	Выполнение задач управления требованиями в процессе сопровождения
Rational TeamTest		Выполнение задач тестирования в процессе сопровождения

Ключевые особенности Rational Unified Process (RUP)

Выбор технологии RUP для реализации СТАНДАРТА и его адаптации к нуждам конкретной организации обусловлен тем, что RUP:

основан на ГОСТ Р ИСО/МЭК 12207 структурные элементы RUP соответствуют основным структурным элементам СТАНДАРТА, таким как:

Процесс; Работа; Задача; Входные/выходные артефакты RUP , которые соответствуют входным/выходным документам СТАНДАРТА; Ролевые функции.

Взаимосвязи между структурными элементами соответствуют их взаимосвязям в СТАНДАРТЕ; Удобство RUP при адаптации процессов к потребностям заказчика:

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

Оформление разработанных материалов в виде веб-сайта

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

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

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

Сведения об авторах:

Все авторы работают в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК в г. Москва.

Галахов И.В. - начальник управления; Лапыгин Д.В. - главный специалист; Позин Б.А. - директор по консалтингу и методологии; Шкляева Н.А. - старший специалист.

Другие статьи авторов:

document.write('

');

Новости мира IT: 02.08 - 02.08 - 02.08 - 02.08 - 02.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 31.07 - 31.07 - 31.07 - 31.07 - 31.07 - Архив новостей Последние комментарии:  (66) 2 Август, 17:53  (19) 2 Август, 17:51  (34) 2 Август, 15:40  (42) 2 Август, 15:35  (1) 2 Август, 14:54  (3) 2 Август, 14:34  (3) 2 Август, 14:15  (2) 2 Август, 13:34  (7) 2 Август, 13:04  (3) 2 Август, 12:28 BrainBoard.ru Море работы для программистов, сисадминов, вебмастеров. Иди и выбирай! Loading google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true); < Реализация стандарта ГОСТ Р ИСО/МЭК Галахов И.В., Лапыгин Д.В., Позин Б.А., Шкляева Н.А. Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем" Роль артефактов в процессе адаптации В СТАНДАРТЕ представлены два вида артефактов, используемых в задачах процесса сопровождения - входные и выходные. На основании СТАНДАРТА можно выделить ряд документов(артефактов), рекомендуемых к использованию в процессе сопровождения, например, «концепция сопровождения», «программное средство», «исходные программы», «уведомление о завершении переноса» и т.п. При внедрении процесса сопровождения в организации обычно не используются точные названия артефактов СТАНДАРТА, а производится разметка требований и рекомендаций стандарта для набора артефактов, определенного на основе артефактов RUP . Например, кроме артефакта «результаты тестирования» также используются артефакты «сводная оценка результатов тестирования», «модель тестирования», «тестовый скрипт» и т.п. Разделение артефактов на «входные» и «выходные» находит развитие в концепции RUP , согласно которой каждый артефакт может играть роль «входного» или «выходного» в разных задачах. При этом также уделяется внимание состоянию артефакта, поскольку каждый артефакт может иметь несколько степеней готовности, начиная от момента создания первой версии артефакта до момента завершения изменений артефакта. Для удобства оценки готовности артефакта и облегчении его создания (в том числе автоматизированного) каждый артефакт снабжается шаблоном, на основании которого он может быть разработан. В процессе адаптации шаблоны артефактов структурируют информацию, создаваемую и используемую в процессе сопровождения ПС. Ролевые функции и организационная структура При внедрении процесса сопровождения программных средств в организации на основе СТАНДАРТА одна из основных задач, требующих решения - определение функциональных ролей, ответственных за выполнение задач процесса сопровождения. Описание процесса сопровождения в терминах функциональных ролей позволяет не зависеть от существующей организационной структуры, которая может меняться . При этом привязка организационной структуры к ролевым функциям осуществляется выпуском организационно-распорядительных документов определяющих, кто какие ролевые функции выполняет. Например, можно использовать таблицу, где в каждой строке в правом столбце указан сотрудник, а в левом - одна или более ролей, которые он выполняет. Изменение организационной структуры не влияет на процесс сопровождения и требует лишь выпуска распоряжения, корректирующего распределение ролевых функций среди персонала. Рисунок 2 - Привязка организационной структуры к ролевым функциям процесса. В СТАНДАРТЕ ролевые функции в явном виде не вводятся, хотя в тексте использованы термины «заказчик», «разработчик», «сопроводитель», «поставщик», к которым относятся требования по сопровождению ПС. Поэтому при адаптации СТАНДАРТА рекомендуется использовать за основу ролевую структуру, существующую в RUP, дополнив ее функциональными требованиями к ролям из СТАНДАРТА. Например, требования к «сопроводителю» обычно распределяются между такими ролями как «менеджер по сопровождению», «менеджер по управлению требованиями» и «менеджер по конфигурационному управлению». Технология адаптации Внедрение процесса сопровождения на основе СТАНДАРТА требует значительных усилий как в нормативно - методологической, так и организационно - технологической плоскости, поскольку универсальность стандарта оборачивается необходимостью проработки деталей для реализации основных положений стандарта в соответствии с потребностями и условиями деятельности заказчика. Основное правило, используемое при адаптации СТАНДАРТА для внедрения процесса сопровождения у заказчика - все положения стандарта используются без изменений. Они могут быть дополнены, детализированы или просто могут не использоваться, но если используются, то в том виде, как это определено в стандарте. При проведении адаптации СТАНДАРТА проводится обследование организации, завершающееся анализом и разработкой структуры процесса сопровождения, после чего проводится автоматизация процесса сопровождения и его ввод в действие. При этом выполняются следующие шаги: Определение положений СТАНДАРТА, на основе которых будет строиться процесс сопровождения; Детализация положений СТАНДАРТА до уровня последовательности выполнения работ и задач процесса сопровождения с указанием входных и выходных артефактов для каждой задачи. Определение взаимодействия процесса сопровождения с другими процессами ЖЦ ПС, используемыми в организации (если в организации определены другие процессы ЖЦ ПС); Определение ролевой структуры ответственности за выполнение работ; Разработка шаблонов артефактов; Привязка ролевой структуры к организационной структуре организации; Выбор инструментальных средств и разработка процедур автоматизации процесса сопровождения; Ввод в действие процесса сопровождения. МЭК 12207 определяет архитектуру верхнего Стандарт ГОСТ Р ИСО/ МЭК 12207 определяет архитектуру верхнего уровня жизненного цикла программных средств (ЖЦ ПС) и может быть использован для организации работ по одному или нескольким процессам ЖЦ ПС. Вместе с ГОСТ Р ИСО/МЭК ТО 15271-2002 «Руководство по применению ГОСТ Р ИСО/МЭК 12207» стандарт ГОСТ Р ИСО/МЭК 12207 предоставляет возможности для адаптации к широкому кругу задач на основе расширения рекомендаций стандарта путем ввода новых процессов, работ, задач или других объектов ЖЦ ПС, не рассматриваемых в стандарте. В качестве примера можно сослаться на раздел 4 приложения « D » к ГОСТ Р ИСО/МЭК ТО 15271-2002 - «Пример сопровождения». В последнее время все большим интересом у наших заказчиков пользуется процесс сопровождения ПС. До недавнего времени при его внедрении на основе стандарта ГОСТ Р ИСО/МЭК 12207 детализацию основных положений процесса сопровождения приходилось выполнять на основе различных международных источников и собственного опыта. Новый СТАНДАРТ детализирует процесс сопровождения, установленный в ГОСТ Р ИСО/МЭК 12207, и содержит рекомендации по планированию и выполнению процесса сопровождения, контролю и надзору за ним, его оценке и завершению. СТАНДАРТ устанавливает основную структуру процесса сопровождения ПС, но не определяет подробности реализации или выполнения работ и задач, входящих в данный процесс. СТАНДАРТ предназначен для организаций, сопровождающих ПС или отвечающих за разработку и качество ПС, и детализирует требования к: к составу и содержанию работ процесса сопровождения; к исходным данным и результатам каждой работы; к очередности выполнения работ и задач; к ответственности за выполнение задач, введенной на уровне ролей (используются роли «Заказчик», «Разработчик», «Сопроводитель»); к связи работ со вспомогательными и организационными процессами ЖЦ ПС. СТАНДАРТ не предназначен для готовых программных продуктов, если они не входят в состав ПС в качестве его элементов. Далее будет представлена методика постановки процесса сопровождения на основе СТАНДАРТА и технологии RUP , используемой для адаптации процесса сопровождения к потребностям конкретной организации. Взаимодействие с другими процессами ЖЦ ПС Процесс сопровождения выполняется на всех стадиях ЖЦ ПС, поэтому важную роль играет правильное определение его взаимодействия с остальными процессами ЖЦ ПС. В частности, многие задачи, которые требуется выполнять в процессе сопровождения, относятся к другим процессам. Обычно это вспомогательные процессы ЖЦ ПС такие как управление конфигурацией и обеспечение качества. В этом случае возможны два варианта определения таких задач: В организации внедряется процесс сопровождения в то время, как остальные процессы ЖЦ ПС не определены - в этом случае все задачи относятся к процессу сопровождения, а в дальнейшем при внедрении остальных процессов ЖЦ ПС потребуется реструктуризация и переопределение процесса сопровождения с передачей не свойственных ему задач другим процессам ЖЦ ПС. Процесс сопровождения внедряется после внедрения других процессов ЖЦ ПС или одновременно с ними. В этом случае задачи, используемые в процессе сопровождения и выполняющиеся другими процессами, выделяются и описываются таким образом, чтобы не нарушать целостность процесса сопровождения и продемонстрировать тот факт, что задача относится к другому процессу. Пример такого описания представлен на Рисунке 1 (в работе переноса ПС в процессе сопровождения используются задачи, выполняемые менеджером по развертыванию в процессе разработки при выполнении работы по вводу ПС в действие). Выделенные на Рисунке 1 задачи определяются в процессе «Разработка» и выполняются ролью «Менеджер по развертыванию», которая также определена в этом процессе. Поэтому при наличии в организации описанного процесса «Разработка» для выполнения работы «Перенос ПС» используются указанные задачи без их дублирования или переопределения. При отсутствии в организации описанного процесса «разработка» такие задачи следует определять в качестве задач процесса «сопровождение». Рисунок 1 - Использование задачи процесса разработки в процессе сопровождения. Обзор и классификация АСУПП Несмотря на разнообразие систем, представленных на рынке АСУПП, все они имеют следующие составляющие: средства для календарно-сетевого планирования; средства для решения частных задач (предпроектный анализ, разработка бюджетов, анализ рисков, управление контрактами, временем, финансами); средства для упрощенного доступа к проектным данным; средства для организации коммуникаций; средства для интеграции с другими приложениями. Средства календарно-сетевого планирования могут быть представлены в виде модулей для составления расписаний и комплексных систем. Первые ориентированы на тех руководителей, которым время от времени приходится планировать простые проекты. Это ПО позволяет задавать взаимосвязи между работами, строить диаграммы Гантта, рассчитывать критический путь, упрощенно оценивать загрузку ресурсов, стоимость проекта и так далее. К сожалению, локализированных продуктов данного класса на отечественном рынке пока не представлено. Комплексные системы стоят значительно дороже. И если предыдущий класс ПО ориентирован на менеджеров практически любой компании, то комплексные системы рассчитаны именно на служащих проектно-ориентированных компаний. Они включают не только профессиональные инструменты для планирования, анализа и контроля над выполнением проектов, но и все необходимые средства для организации эффективных коммуникаций между участниками проектных команд и интеграции с комплексными АСУП. Программное обеспечение такого класса выпускают компании Artemis Management Systems, Primavera Systems, Welcom Software Technologies. В фокусе нашего внимания — системы из ценовой категории $300-800. Среди них программы как начального уровня, в которых упор сделан на легкость применения, так и системы с расширенной функциональностью. Большинство из них содержат средства для интеграции с другими приложениями и организации эффективных коммуникаций в проектной команде: обмен информацией по электронной почте, удаленный доступ через веб-браузер с возможностью обновления данных, мастера для создания веб-отчетов и прочие функции. В качестве примера таких систем можно назвать MS Project 2002 (Microsoft), SureTrak Project Manager (Primavera Systems), Spider Project Management Technologies (Spider) — все они позволяют эффективно планировать проекты практически любой сложности. С помощью АСУПП данной ценовой категории можно определять этапы и список работ проекта, создавать расписания, задавать календарные сроки выполнения задач и трудозатраты, назначать приоритеты, устанавливать взаимосвязи, рассчитывать критические пути и так далее. Кроме этого, есть возможность поддерживать множественное разбиение работ на структурные части, соответствующие различным представлениям проекта и учитывающие его специфику. Каждый из пакетов имеет свои особенности в обеспечении операций планирования. Так, инструменты Primavera позволяют организовывать более чем одну связь между двумя работами, в то время как MS Project и Spider — лишь одну. Также продукты Primavera требуют от менеджера создать структурную схему прежде, чем начать календарное планирование, тогда как MS Project и Spider позволяют получить сетевой график как побочный результат календарного планирования. Spider при определении работы наряду со стандартными параметрами, принятыми в западном мире (длительность, трудозатраты, расход ресурсов), предоставляет возможность задать ее объем в условных единицах (для организаций, которые ведут документацию по старым правилам, принятым в советское время). Во всех системах организованы развитые возможности оптимизации хода выполнения работ по времени, бюджету и использованию ресурсов, в том числе трудовых. И хотя подобная оптимизация предусматривает активную самостоятельную коррекцию задач и назначений ресурсов, инструментальные средства планирования наглядно показывают, что подлежит оптимизации, а что нет. В итоге менеджеру остается только проверить идеологическую возможность оптимизации, и если это реально, внести соответствующие изменения. По такому сценарию действуют пакеты от Primavera и Microsoft. Отечественные же разработчики считают, что более эффективна скрупулезная настройка мастера оптимизации с последующим включением его функционирования одним нажатием кнопки. Хотя планирование рисков — процесс, по сути, малооптимизируемый, неплохие средства по структурированию рисков имеются во всех проектных программных модулях. Например, неплохие мастера, встроенные в пакеты уже на самом раннем этапе проектирования, могут подсказать менеджеру, какие риски способны оказать негативное влияние на проект. Так, рассматриваемые системы обеспечивают идентификацию потенциальных рисков в бюджетной сфере, рисков относительно доставки ресурсов и прочих. Кроме того, ПО от Primavera и Microsoft позволяет моделировать последствия срабатывания рисков (влияние на календарный план, бюджет, затраты по проекту) с помощью мощных аналитических средств. Для этого применяются имитационные сценарии «если.., то…», а также учитываются вероятности риска и финансовые последствия его срабатывания для каждой отдельной работы в проекте. В отличие от них дополнительные возможности Spider в области планирования рисков сводятся к статистическому анализу вероятностей окончания проекта в пределах установленных календарных, бюджетных и ресурсных ограничений. Что касается планирования обеспечения проекта ресурсами, в данной сфере описываемое ПО весьма похоже. Все АСУПП способны вести планирование назначений индивидуальных исполнителей на работы, учет неполной загрузки, планирование расходов материальных ресурсов на отдельных этапах. Во всех трех системах неплохо развито планирование затрат: предоставляется возможность поддержания учета стоимости отдельных работ, времени работы исполнителей, использования единицы материального ресурса или часа эксплуатации оборудования, а также статьи фиксированных затрат. К тому же инструменты от Primavera и Microsoft, в отличие от Spider, позволяют учитывать отдельно стоимость урочной и сверхурочной работы исполнителей. Одновременно Spider допускает использование фиксированных затрат, не связанных с длительностью и объемом работы. Что касается мониторинга и анализа выполнения проекта, здесь возможности описываемого ПО также находится на высоком уровне. Системы хороши для контроля и управления календарными сроками и расходом ресурсов. Кроме того, они позволяют контролировать отклонение реального графика проекта от базового, проводить анализ освоенных объемов, а также создают понятные информативные отчеты. Весьма важным моментом в работе современного АСУПП является функция коллективного управления проектом. Например, несколько менеджеров, ведущих дела проекта, должны иметь возможность не только параллельно работать в многопользовательском режиме, но и одновременно предлагать свои решения на суд оптимизационных модулей программы. Технологически программный модуль проектной оптимизации разработки Spider, функционируя в мульпользовательском режиме, создает набор файлов, который рассылается по FTP всем менеджерам проекта. Таким образом, каждый из участников работ постоянно находится в курсе выполненного объема задач. Аналогично действуют и ПО Primavera и MS Project. Они используют СУБД. Доступ к последним осуществляется через глобальные и локальные сети (правила доступа четко регламентируются). Дополнительное удобство MS Project — способность поддерживать интегрированный документооборот в проектной группе, благодаря тесной интеграции с серверными продуктами компании. Современные инструменты проектного менеджмента &laquoЭкспресс-Электроника&raquo Сегодня на российском рынке автоматизированных систем управления проектами наиболее активны несколько игроков: лидер мирового рынка ПО данного класса — Primavera Systems, компания Microsoft со своим пакетом Project 2002 и отечественный разработчик Spider Project Management Technologies, продукт которого отражает локальную специфику. О преимуществах и недостатках их решений мы и поговорим. Перед тем как начать анализ возможностей продуктов, рассмотрим среду, в которой они призваны функционировать, а также ее потребности. Приведенная ниже классификация пользователей взята из исследования Welcom Software Technologies. Итак, выделяют три основные категории — все они участвуют в процессе управления деятельностью проектно-ориентированной компании и, соответственно, оказывают влияние на ход управления проектом. Именно на этих пользователей в основном рассчитаны автоматизированные системы управления предприятием и проектом (АСУПП). В первую очередь это высшее руководство компании, — даже не участвуя в проекте, оно может существенно повлиять на его выполнение. Как правило, к данной группе относятся специалисты, отвечающие за планирование деятельности организации, постановку целей и задач, а также за оценку их выполнения. Пользователи управленческой категории предпочитают легкие в управлении программные модули, имеющие возможность выдавать демонстрационные отчеты в любой момент времени выполнения проекта. Кроме того, они требуют наличия не только мощных возможностей обобщения оперативных сведений, но и средств для интеграции с данными из других программных приложений. Вторая категория — менеджеры, ответственные за разработку детальных планов достижения целей, поставленных руководством. Они распределяют работы по конкретным исполнителям, обеспечивают планирование использования ресурсов и осуществляют контроль над выполнением планов и подготовку укрупненных отчетов для руководства. От АСУПП данный класс пользователей требует расширенных возможностей анализа рисков. И для менеджеров возможность интеграции АСУПП с другими приложениями важна не меньше, чем для руководства. Третья категория пользователей АСУПП — специалисты на местах, ответственные за выполнение работ, определенных проектным графиком. Им поручается предоставление отчетов о состоянии выполняемых работ, их качестве, доступности, загрузке ресурсов и прочих параметрах. Для пользователей данного уровня очень важна простота использования, легкость изучения, «прозрачность» процедур ввода данных, а также наглядность функционирования ПО. Разумеется, предложенная классификация весьма условна. Так, при реализации несложных проектов или в небольших организациях, уровень детального планирования будет представлен второй группой сотрудников — руководителями, для которых планирование проектов не является основной работой. Это может быть директор небольшой фирмы или заместитель руководителя крупной компании, планирующий текущую деятельность своего предприятия, или начальники отделов, которые планируют загрузку своих сотрудников. Для этой группы управленцев более важны такие характеристики системы, как простота использования и легкость обучения. Как видно, сегодня работа проектного Как видно, сегодня работа проектного менеджера может быть достаточно эффективно модернизирована. При этом на рынке сосуществуют продукты, отвечающие и мировым канонам в области ведения проектов (Primavera и MS Project), и советским нормам проектирования, которые до сих пор активно используются отдельными российскими предприятиями. В этом случае продукт отечественной компании Spider Project Management Technologies представляется наиболее перспективным. С другой стороны, по сравнению с продуктами западных поставщиков, где задачи этапов легко дифференцируются между подрядчиками, Spider имеет значительно меньшие возможности в области работы над коллективными проектами. Сильная сторона отечественно разработки – оптимизация проектов по заранее настроенному мастеру. Для компаний, занимающихся, например, только интеграционной деятельностью и наладкой сетей, такой подход окажется весьма эффективным. Что касается предприятий, которые оказывают комплексные услуги, им больше подойдут Primavera или MS Project, постоянно требующие от менеджера индивидуального подхода. Одно из основных достоинство MS Project 2002 — мощная поддержка местных партнеров Microsoft. Не стоит забывать и о том, что MS Project 2002 тесно переплетается с офисными пакетами Microsoft, а также Exchange Server. MS Project 2002 гибок и может быть настроен как по шаблону, так и в режиме скрупулезной проработки возможностей оптимизации нового проекта. Лидерское положение компании Primavera на рынке ощущается довольно-таки сильно. Ее системы наиболее функциональны, однако имеют и самую высокую стоимость на рынке, поэтому не популярны среди менеджеров, ведущих работу над небольшими проектами. Пакет Primavera по-настоящему эффективен в тех проектах, где занято свыше 350 участников. В подобных случаях продукту Primavera равных нет — широкие возможности по настройке оптимизации, а также множество способов контроля делают SureTrak Project Manager оптимальным выбором для крупных проектов с большим числом подрядчиков и длительным сроком реализации. Пожалуй, наилучшим образом Primavera SureTrak Project Manager может проявить себя в строительно-монтажных и промышленных организациях.