Управление проектами - статьи
Быстрое моделирование
Независимо от того, что вы могли слышать раньше, эволюционные и быстрые методы не являются просто новым названием «кодирования и устранения ошибок». По-прежнему требуется анализировать требования и продумывать архитектуру и конструкцию системы до ее построения, и один из хороших подходов состоит в моделировании до кодирования. На рис. 1 изображен жизненный цикл Быстрой Разработки под Управлением Модели (Agile Model Driven Development, AMDD) (Ambler 2004). При использовании AMDD в начале проекта создаются начальные высокоуровневые модели, которые обеспечивают общее представление проблемной области, которую вы затрагиваете, а также потенциальной архитектуры будущей системы. Одной из моделей, которые обычно создаются, является «тонкая» («slim») концептуальная/прикладная модель, описывающая основные бизнес-объекты и связи между ними. Вашей целью является продумывание основных проблем в начале проекта без немедленного погружения в пока еще ненужные детали – детали можно проработать позже, когда это понадобится (just-in-time, JIT), путем мозгового штурма модели. Более подробно метод AMDD описывается на странице http://www.agilemodeling.com/essays/amdd.htm.
Рис. 1. Жизненный цикл AMDD
Быстрые методы для объектных баз данных
Скотт Амблер, Ambysoft Inc.,Перевод -
Предисловие переводчика
Скотт Амблер – известный, судя по Internet, специалист в области методологий разработки программного обеспечения. Его даже называют “гуру” быстрых (agile) методов разработки. Сам он ассоциирует себя с двумя компаниями – Ambisoft и Robin International – и называет себя старшим консультантом в обеих компаниях. Судя по фотографиям, Амблер достаточно молодой человек, а судя по числу написанных и изданных им книг, а также объему подготовленных им материалов, размещенных на www.ambysoft.com, исключительно активный. Статью, перевод которой мы вам предлагаем, Амблер написал специально для портала www.odbms.org (хотя, похоже, что в этом его стимулировала компания db4objects, о которой мы еще поговорим).
Название статьи не совсем соответствует ее содержанию. Про разработку объектных баз данных в ней почти ничего не говорится. Большая часть статьи содержит обзор быстрых методов разработки, и в этой части нет каких-либо откровений, хотя она дает возможность в целом понять, что представляет из себя быстрый подход к разработке программного обеспечения. По нашему мнению, некоторой оригинальностью отличается только шестой раздел статьи (“Быстрый подход с применением объектных баз данных”), хотя и его название не совсем соответствует содержанию. Почти весь раздел посвящен трудностям, с которыми сталкиваются быстрые разработчики (автор вводит новый термин для обозначения этой категории разработчиков – агилисты) при потребности использовать реляционные базы данных. По нашему мнению, этот раздел заслуживает отдельного комментария.
Автор выдвигает три тезиса:
Что касается первого тезиса (technology impedance mismatch), то именно он лежал в основе , опубликованного в конце 1990-х и способствовавшего в то время развитию технологии объектно-ориентированных баз данных.
Тогда под несоответствием понималось, главным образом, серьезное различие в системах типов, поддерживаемых в языках программирования и реляционных (SQL-ориентированных) СУБД. С той поры прошло уже много лет, и в современном стандарте языка SQL (и основных реализациях РСУБД) поддерживается очень развитая система типов (во многом схожая с системой типов языка Java). Поэтому об этой разновидности технологического несоответствия говорить уже не приходится, и автор напирает на несоответствие по причине потребности в “объектно-реляционном” отображения, если разработка ведется в объектной технологии, а базы данных используются реляционные. Но и об этом нужно говорить более точно и аккуратно. У языка SQL имеется своя объектная модель, и SQL-ориентированную базу данных (по крайней мере, если использовать IBM DB2 или Oracle) можно спроектировать и использовать в объектном стиле. Так что, похоже, что в действительности речь идет о том, что при использовании в быстрых методах языка SQL нужно хорошо знать этот язык, а быстро узнать его у агилистов не получается.
Со вторым тезисом до сих пор мне сталкиваться не приходилось. По-видимому, “профессионалами в области данных” автор называет специалистов, которые умеют производить логическое и физическое проектирование баз данных. Мне всегда казалось, что при создании приложения, для которого создается собственная база данных, должен вестись единый проект, поскольку особенности конструкции базы данных должны соответствовать общим требованиям к приложению. Какой подход выбирается для реализации всего проекта – это вопрос предпочтений проектной группы. И вот выясняется, что в группе, выполняющей проект быстрыми методами, проектировщики реляционной базы данных не вписываются в коллектив разработчиков. Очень может быть, что автор руководствуется своим личным опытом, но приводимые им доводы не очень убедительны. Фактически он утверждает, что “профессионалы в области данных” не хотят (или не могут) пользоваться быстрыми методами и поэтому нужно отказаться от реляционных баз данных и перейти на использование объектных баз данных (для разработки которых, по всей видимости, профессионалы не требуются).
Мне кажется, что этот тезис открывает простор для дискуссии (и это одна из причин, по которой мы решили опубликовать перевод статьи Амблера).
Свой третий тезис автор сам расценивает не очень серьезно. Действительно, откуда бы взялись инструменты быстрой разработки реляционных баз данных, если “профессионалы в области данных” быстрой разработкой пользоваться не хотят (или не могут). И в связи с этим, я вижу некоторое противоречие с замечанием автора, что сообщество open source озабочено отсутствие средств быстрой разработки баз данных и стремится закрыть эту брешь. Кто же будет пользоваться этими средствами? Или в этом случае для проектирования реляционных баз данных профессионалы уже не потребуются?
В конце статьи, наконец, выясняется, к чему ведет автор. Около года тому назад компания db4objects объявила о выходе своей объектно-ориентированной СУБД db4o, доступной с исходными кодами (система написана на языке Java) по лицензии GPL. Вернее, компания придерживается подхода двойного лицензирования: для клиентов, желающих использовать систему для построения коммерческих приложений, обеспечивается специальная коммерческая лицензия. По этому поводу (как и в случае MySQL) разработка системы ведется исключительно силами сотрудников компании. Суть последнего раздела статьи Амблера в этом контексте сводится к тому, что использование db4o при быстрой разработке приложений баз данных снимает все противоречия и делает жизнь агилистов счастливой. Дай Бог, чтобы это так и было! Но только у меня имеются сомнения.
Я не слишком глубоко познакомился с техническим устройством db4o, но у меня уже создалось впечатление, что серьезных технологических новшеств в этой системе нет. Подобно тому, как когда то разработчики одной из самых успешных объектно-ориентированных СУБД Object Store начинали свой проект с полной привязки с среде языка C++, разработчики db4o ориентируются на среды Java и .NET. Как и раньше, основными козырями системы объявляется возможность сохранения в базе данных объектов произвольно сложной структуры, с которыми можно работать так же, как если бы они создавались в соответствующей программной среде во время выполнения приложения.
Почему-то в качестве особого достоинства системы объявляется поддержка ACID-транзакций, хотя, вроде бы, это является обязательной характеристикой любой современной СУБД.
Интересно, что компания db4objects (пока) даже и не претендует на конкуренцию с реляционными системами в наиболее доходном секторе рынка – секторе корпоративных информационных систем. Подобно многим известным ранее начинающим компаниям, db4objects претендует на соответствие возможностей своего продукта потребностям встроенных систем, в которых база данных является неотъемлемой принадлежностью приложения и не требует внешнего админитстрирования. Мне кажется, что в этой области у db4o шансы действительно имеются, если СУБД работает достаточно устойчиво. И, скорее всего, быстрые методы Скотта Амблера в совокупностью с технологией db4o здесь смогут принести успех.
Предисловие получилось несколько длинноватым, но мне хотелось предостеречь читателей от слишком больших ожиданий, которые могут появиться после прочтения статьи агилиста-энтузиаста Амблера. Надеюсь, что в совокупности с этим текстом статья окажется более понятной и полезной.
Современные процессы разработки программного обеспечения, такие как Rational Unified Process (RUP), Extreme Programming (XP) и Scrum, являются эволюционными по своей природе, и многие из них – быстрые (agile). При применении эволюционного подхода вы работаете одновременно в итерационной и инкрементальном режимах; быстрый подход сочетает эволюционность с высоким уровнем сотрудничества. Работая в итерационном режиме, вы в каждый момент времени немного моделируете, немного тестируете, немного кодируете и немного развертываете, потом еще немного, и еще немного, и т.д. При использовании инкрементального подхода вы организуете свою систему в виде последовательности выпусков, а не одного большого выпуска. Когда группа разработчиков прибегает к коллаборативному подходу, ее участники активно стараются найти способы эффективной совместной работы; следует даже добиваться того, чтобы инициаторы проекта (заказчики системы) являлись активными членами группы.
В этой статье приводится обзор набора быстрых методов для разработки программного обеспечения, ориентированного на работу с данными. В большинстве работ, посвященных этому предмету, в частности, в моих книгах Agile Database Techniques (John Wiley Publishing, 2003) и Database Refactoring (Prentice Hall PTR, January 2006), предполагается использование объектной технологии, например, Java или C# в клиентской части приложения и технологии реляционных баз данных, например, Oracle или DB2 в серверной части. К сожалению, по причинам наличия несоответствия между объектной и реляционной парадигмами и отсутствия в настоящее время соответствующего инструментария, возможности применения быстрых методов здесь ограничены. Как вы увидите, гораздо легче применять быстрый подход при использовании технологии объектных систем управления базами данных (ОСУБД).
Прежде всего, обсудим методы быстрой разработки, которые следует применять при разработке баз данных. Эти методы включают следующее:
Рефакторинг
Быстрое моделирование
Постоянное регрессионное тестирование
Конфигурационное управление
«Песочницы» (sandbox) разработчиков
Быстрые методы с использованием неагрессивной объектной базы данных db4o
Основная идея состоит в том, что чем менее агрессивной является стратегия персистентности, тем проще будет разрабатывать, развивать и сопровождать приложения. ОСУБД с открытым кодом db4objects, доступная под лицензией GPL на сайте www.db4o.com, является хорошим примером неагрессивной стратегией персистентности для платформ Java и .NET. Запросы задаются на основе открытого API, который просто используется и развивается – доступ к данным производится через собственный исходный код, который можно подвергать рефакторингу и тестированию с использованием существующих средств разработки. Отсутствуют техническией и культурные несоответствия, которые нужно было бы преодолевать, и инструменты, требуемые для быстрого развития схемы, уже существуют.Быстрый подход с применением объектных баз данных
Я полагаю, что быстрым быть проще при использовании технологии объектных баз данных (ОСУБД), чем технологии РСУБД, на основе трех соображений:Несоответствие технологий. Объектная и реляционная технологии основываются на разных парадигмах, в результате между ними имеется “потеря соответствия” (“ impedance mismatch”), которую необходимо преодолевать. На рис. 4 показаны стеки приложений при использовании технологий РСУБД и ОСУБД. Как можно видеть, при использовании технологии РСУБД на уровне персистентности требуется реализовывать объектно-релляционное отображение между объектной схемой и схемой данных, в то время как при использовании технологии ОСУБД эта проблема отсутствует. При использовании технологии РСУБД приходится выполнять больше работы, приходится определять объектную схему и схему данных и отображения между ними, а затем все это необходимо развивать по мере появления новых требований к приложению. При использовании технологии ОСУБД нужно всего лишь определить и развивать объектную схему приложения.
Несоответствие культур. Под несоответствием культур мы понимаем разницу в культуре объектных разработчиков и пррофессионалов в области данных. Объектные разработчики, включая тех, которые используют технологию ОСУБД, годами работают в эволюционной манере и легко переходят к быстрым методологиям. Профессионалы в области данных, с другой стороны, тяготеют к традиционному подходу, который обычно является по своей природе последовательным и часто предписывающим (т.е. бюрократическим). Еще хуже то, что, как показывает таб. 1, сообщество данных в основном избегает новых методов разработки, таких как AMDD и TDD, в то время как объектные разработчики охотно их принимают. Эти культурные различия часто проявляются в дискуссиях относительно способа выполнения работы, излишних совещаниях, дополнительной работе части профессионалов в области данных, которые всего лишь должны делать свое дело по своим правилам, и даже двойной работе, поскольку и в объектной группе, и в группе данных возникает свое видение концептуальной и проектной схем. Более подробное обсуждение этой темы см. на www.agiledata.org.
Поддержка инструментальных средств. В настоящее отсутствует инструментальная поддержка рефакторинга схем РСУБД и, в меньшей степени, автономного тестирования РСУБД. Инструментальные средства рефакторинга и автономного тестирования для объектной технологии являются достаточно зрелыми, что повышает производительность труда объектных разработчиков. Я очень надеюсь, что в течение нескольких следующих лет инструментальная поддержка быстрой разработки РСУБД улучшится, но в настоящее время ситуация не является блестящей.
Рис. 4. Сравнение стеков приложений при использовании РСУБД и ОСУБД
Конфигурационное управление
Иногда изменение в системе оказывается очень плохой идеей, и нужно откатить систему в состояние до внесения этого изменения. Например, переименование столбца Customer.Fname в Customer.FirstName может нарушить работоспособность 50 внешних программ, и стоимость их модификации может оказаться слишком высокой. Подобно тому, как разработчики помещают свое имущество (исходные коды и модели разработки) под охрану конфигурационного управления, профессионалам следует аналогично поступать со следующими предметами:Скрипты DLL (data definition language) для создания схемы базы данных
Скрипты загрузки/извлечения данных
Файлы моделей данных
Метаданные объектно-реляционного отображения
Эталонные данные
Определения хранимых процедур и триггеров
Определения представлений
Ограничения ссылочной целостности
Тестовые данные
Скрипты генерации тестовых данных
Тестовые скрипты
Песочницы разработчиков
«Песочница» – это полностью функционирующая среда, в которой систему можно построить, оттестировать и/или запустить. По причинам безопасности может захотеться поддерживать различные отдельные песочницы – у разработчиков должна иметься возможность работать в своей собственной песочнице без опасения навредить другим работам, у группы поддержки качества и тестирования должна иметься возможность безопасного запуска их тестов системной интеграции, а у конечных пользователей должна иметься возможность запуска своих систем без опасения того, что разработчики повредят их исходные данные и/или функциональность системы.На рис. 3 изображена логическая организация песочницы – в большой и сложной среде может иметься семь или восемь физических песочниц, в то время как в небольшой и простой среде может иметься только две или три песочницы. Понадобится отдельная песочница для каждого разработчика, а в случае команд, в которых программисты работают парами, – одна песочница на каждую пару разработчиков.
Разработчики нуждаются в своих собственных физических песочницах для работы в них, в копии исходного кода для его развития и в копии базы данных для работы с ней и ее развития. При наличии собственной среды они могут безопасно вносить изменения, тестировать их и либо принимать их, либо отбрасывать. Если разработчик считает изменение жизнеспособным, он продвигает его в совместно используемую среду проекта, тестирует его и заносит под контроль CM, чтобы другие члены группы могли его взять. В конце концов группа продвигает свою работу в какую либо тестовую демо-среду и/или среду подготовки. Это продвижение часто происходит один раз на весь цикл разработки, хотя может происходить более или менее часто в зависимости от особенностей среды (чем более часто продвигается система, тем больше шансы получить значительную обратную связь). Наконец, когда система проходит приемку и системное тестирование, она внедряется в производство.
Рис. 3. Логические песочницы для обеспечения безопасности разработчиков
Постоянное регрессионное тестирование
Чтобы безопасно изменять существующее программное обеспечение с целью рефакторинга или добавления новых функций, требуется возможность проверки, не было ли что-нибудь повреждено в процессе внесения изменений. Другими словами, требуется возможность пропуска на системе полного регрессионного теста. При обнаружении какого-либо повреждения необходимо либо его исправить, либо откатить изменения. В сообществе быстрой разработки среди программистов все более принято разрабатывать полный тестовый набор в параллель с разработкой приложения, а в действительности приверженцы быстрого подхода (агилисты, agilest) предпочитают писать код тестов до написания «настоящего» кода. Не следует ли тестировать и базу данных подобно тому, как тестируется исходный тест приложения? Внутри базы данных реализуется важная бизнес-логика в форме хранимых процедур, правил проверки корректности данных и правил ссылочной целостности (referential integrity, RI). Очевидно, что эту бизнес-логику следует тщательно тестировать.Метод разработки, начинающийся с создания тестов (test-first development, TFD), называемый также программированием, начинающимся с создания тестов (test-first programming), является эволюционным подходом, при котором до написания нового функционального кода вы должны написать тест, который не проходит на существующем коде. Шаги TFD изображены на рис. 2 в виде диаграммы активностей UML. Разработка под управлением тестов (tеst-driven development, TDD) (Astels 2003; Beck 2003) – это комбинация TFD и рефакторинга. Сначала вы пишите код, применяя подход TFD, а когда он работает, вы обеспечиваете высокое качество разработки путем применения рефакторинга. После рефакторинга требуется снова пропустить регрессионные тесты для проверки того, что ничего не повреждено.
Рис. 2. Метод разработки, начинающийся с создания тестов
Рефакторинг
Рефакторинг (Fowler 1999) – это дисциплинированный способ внесения небольших изменений в исходный код для совершенствования его конструкции, упрощения работы с ним. Важным аспектом рефакторинга является то, что он сохраняет неизменной поведенческую семантику кода – в процессе рефакторинга никогда ничего не добавляется и не удаляется, только совершенствуется качество кода. Примером рефакторинга могло бы быть переименование операции getPersons() в getPeople(). Для реализации этого рефакторинга необходимо изменить определение операции, а затем поменять каждый вызов этой операции в коде приложения. Процесс рефакторинга не завершается до тех пор, пока код снова не заработает так, как раньше.Аналогично, рефакторинг баз данных (Ambler 2003, Ambler & Sadalage 2006) – это простое изменение схемы реляционной базы данных, которое улучшает ее конструкцию, оставляя неизменной ее поведенческую и информационную семантику. Рефакторингу можно подвергать либо структурные аспекты схемы базы данных, например, определения таблиц и представлений, либо функциональные аспекты, например, хранимые процедуры и триггеры. В процессе рефакторинга схемы базы данных требуется переработать не только саму схему, но и внешние программы (бизнес-приложения или программы извлечения данных), связанные с этой схемой. Очевидно, что рефакторинг баз данных реализуется сложнее рефакторинга кода, потому что не допускается разрушение ни данных, ни функциональных возможностей, поэтому здесь требуется осторожность.
Современные процессы разработки программного обеспечения
Современные процессы разработки программного обеспечения являются по своей природе эволюционными и достаточно часто быстрыми. Если организация принимает быстрый подход, то ее IT-профессионалы должны принять на вооружение соответствующие методы, которые позволят им работать в быстрой манере. Эти методы включают рефакторинг, быстрое моделирование, постоянное регрессионное тестирование, конфигурационное управление всеми активами разработки и отдельные песочницы для работы разработчиков. Использование РСУБД усложняет применение этих методов по причинам технического несоответствия, культурного несоответствия и отсутствия в настоящее время инструментальной поддержки.Взгляд мельком: Применение быстрых методов с использованием двух технологий СУБД
| Метод | При использовании технологии РСУБД | При использовании технологии ОСУБД |
| 1. Рефакторинг | Средства рефакторинга баз данных пока не существуют Технология РСУБД не поддерживает простую эволюцию схемы, поскольку она часто основывается на предположении о последовательном подходе к разработке |
Используются существующие инструментальные средства рефакторинга Технология ОСУБД поддерживает гораздо более простую эволюцию схемы, поскольку она часто основывается на предположении, что разработчики будут следовать эволюционному подходу |
| 2. Быстрое моделирование | Требуется моделировать как объектную схему, так и схему данных, а затем организовывать их отображения Реально возникновение конфликтов, если это делается разными группами (как часто и бывает) |
Нужно моделировать только объектную схему |
| 3. Постоянное регрессионное тестирование | Средства тестирования РСУБД все еще развиваются, хотя сообщество open source быстро наверстывает упущенное Средства тестирования данных очень зрелые, но часто дорогие Для многих профессионалов в области данных TDD является новой идеей |
Средства автономного тестирования для объектной технологии, такие как Junit и CSUnit, являются очень зрелыми. В сообществе быстрого программирования хорошо воспринимается TDD |
| 4. Конфигурационное управление | Требуется поставить все артифакты разработки под контроль CM | Требуется поставить все артифакты разработки под контроль CM |
| 5. Песочницы разработчиков | Требуются все средства разработки, объектный код и экземпляр базы данных | Требуются все средства разработки и объектный код |
Таблица 1. Применение быстрых методов с использованием двух технологий
Управление проектами - статьи
Антипаттерны мнительности
«Агрессия». «На то и волк в лесу, чтоб пастух не дремал!» Руководитель стремится удерживать подчиненных вне «зоны комфорта». («Настоящие лидеры задают трудные вопросы и выбивают людей из зоны их комфорта. Затем они управляют возникающим стрессом!», (с) Р.А. Хейфетц, Д.Л. Лори, «Работа лидера», 1997.) Постоянное давление. Нереальные сроки. Сверхурочные. Авралы. Непрерывная критика и понижение самооценки («заодно можно сэкономить на зарплате!»). Грубость. Запугивание. «У нас незаменимых нет!» «Поощрение непричастных и наказание невиновных». Назначение в несколько проектов одновременно. («Чем больше, тем лучше - обязательно что-нибудь провалит! Сотрудник должен все время ощущать свою вину!») Постоянные перемещения людей по горизонтали и вверх-вниз. Обязанности определены самым общим образом: «Ты в ответе за все!» Поручения не зависят от обязанностей. Правила меняются по ходу игры.«Управление грибами». (Почему грибами? Потому, что грибы держат в темноте и кормят навозом.) Удержание работников в неинформированном и постоянно занятом состоянии. Замыкание всех внешних и внутренних потоков информации на себя. Фильтрация и искажение информации в личных интересах. Зависимость исполнителей от более информированного начальника. Строгое разграничение прав доступа к проектной документации и исходным кодам. Ограничение доступа в Интернет («а вдруг узнают среднюю зарплату на рынке?»), запрет ICQ, препятствование общению с коллегами из других компаний. Загрузить работой так, чтобы времени на обдумывание чего-либо не оставалось. Постоянно находить какие-нибудь «важные и неотложные» дела.
«Микроменеджмент». Отсутствие делегирования в любом виде. Строгий контроль всех работ через активное личное наблюдение. Руководитель замыкает на себя принятие решений по всем вопросам.
Считает себя самым компетентным. Влезает во все самые мелкие работы, от структуры таблиц в БД до цвета шрифтов в интерфейсе. Вместо объяснения того, что надо делать, постоянные указания на то, как надо делать. Навязывает собственные идеи. «Думать – это моя работа! Просто, делай, как я сказал!» Жестко контролирует, каждый шаг исполнителей.
«Методологическое безумие». Безграничная вера руководителя в методологию с большой буквы «М» - всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!» Методология принимает все решения, люди не принимают решения вовсе. Многоступенчатая бюрократия. Все процессы регламентированы. Все делается по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Установлен тотальный контроль соблюдения регламентов. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации. Внедрены всеобъемлющие нормы и метрики. Большая часть времени исполнителей тратится на соблюдение правил и писанину, которую никто никогда не читает. Большая доля «сизифова труда».
Антипаттерны некомпетентности
«Я сделал все, что мог!» Руководитель не способен оценить сложность решаемых задач, эффективность способов их решения и реальное состояние проекта. Постоянные негативные оценки прогресса проекта: «Все плохо! Надо делать быстрее! Надо делать лучше!», не вдаваясь в подробности «как это надо делать». Раздувание недостатков до глобальных размеров. Постоянная публичная критика участников команды и жалобы вышестоящему руководству на некомпетентность исполнителей. Надежда на то, что если проект провалится, то удастся свалить вину на команду: «Я сделал все, что мог!». Если же проект окажется успешным – присвоить успех себе: «Если бы я не «строил» команду, ничего бы не получилось!»«Yes-man!» Руководитель, который полностью зависим от Босса. Всегда согласен с его мнением, как бы оно не расходилось с его собственными взглядами и мнением его команды. Руководствуется принципом: «Возлюби Босса своего и никогда не спорь с ним!». Интересы фирмы, команды, продукта и его пользователей не учитываются вовсе. «Босс хочет, что бы мы закончили проект в два раза быстрее. Как? Это ваша забота, вам за это деньги платят!». Не принимает ни одного решения без согласования с Боссом. Испытывает постоянную потребность «угадать и угодить» Культивирует любимчиков в команде, которые никогда с ним не спорят.
«Охота на ведьм». Руководитель сознает свою некомпетентность и опасается, что если он не возглавит борьбу с «врагами» проекта, то «врагом» проекта может оказаться он сам. Постоянный поиск виновных и «козлов отпущения». Наказания. Разжигание конкуренции в команде: «После проекта останутся только лучшие!». Действия по принципу «разделяй и властвуй». Исполнители проекта распадаются на несколько противоборствующих клик.
Пресечение любой критики и опасного для себя поведения подчиненных: «Ваше поведение непрофессионально / некорпоративно!» (вы ни разу не слышали этой фразы – завидую, вам везло с начальниками).
«Нет времени точить пилу!» (в англоязычной википедии у этого антипаттерна другое, более жесткое название – «Headless chicken»). Руководитель не умеет управлять приоритетами, постоянно занимается пожаротушением, полностью погружен в решение неотложных вопросов. Времени на уточнение целей, разработку стратегии, адекватное планирование, оценку и повышение эффективности применяемых процессов не остается. Героический труд («у плохих генералов всегда много героев»). Темп поступления проблем превышает скорость их решения. Большинство задач, которые получают участники проекта, имеют наивысший приоритет и срочность. «Это надо было сделать еще вчера!» Работа постоянно выполняется под давлением нереальных сроков. Обучение, анализ, проектирование и рефакторинг – «Это все потом!». Постоянные сверхурочные и авралы. Большой проблемный код.
Антипаттерны руководства командами разработки ПО
Сергей АрхипенковПрокомментировать статью можно здесь
«Программист рожден для счастья…,
а приходится работать!»
(с) В. Короленко + программисты
Что такое эффективность?
Эффективность это количество полученных результатов на единицу затрат. В новых условиях надо осознать, что люди – это теперь не затраты. Люди - это капитал. Затраты: плата за аренду, коммунальные услуги, электроэнергию и проч., - не надо путать с инвестициями, которые увеличивают капитализацию. Вложение в людей это увеличение числителя в формуле эффективности. Создание и закрепление эффективной команды - это стратегическое приобретение компании. Обучение участников проекта новым технологиям – инвестиции. Уход из компании всех профессионалов после проекта, выполненного по принципу «любой ценой», – затраты, причем очень тяжело восполняемые. Это все равно, что «зарезать курицу, которая несет золотые яйца». Что стоит выигранное сражение, если мы проиграли войну?Предприятие обязано относится к своим работникам так же, как к своим лучшим клиентам. Те предприятия, которые этого не поняли, не выживут потому, что не смогут быть эффективными. Современное предприятие – это посредник. Предприятие, с одной стороны, предоставляет услуги и продукты своим клиентам, а с другой, - рабочие места для наемного персонала.
Принципы «Одно предприятие на всю жизнь», «Работай продуктивно, а предприятие о тебе позаботится» - ушли в прошлое. Посмотрите на рынок рабочей силы в ИТ - правила устанавливают профессионалы. Мало кого интересует, в каких компаниях вы работали, зато всех интересует, в каких проектах вы участвовали и ваш вклад в их успех.
Цель предприятия, которое стремиться к эффективности, сделать счастливыми не только своих клиентов, но и своих работников. Сегодня у проекта разработки ПО не три, а четыре фактора успеха:
Задача эффективных руководителей сделать так, чтобы этот четвертый фактор успеха был воспроизводимым.
Сегодня эффективный менеджер – это в первую очередь лидер, который признан командой. Во-первых, получил признание своей профессиональной компетентности, во-вторых, своих исключительных человеческих качеств. Не выполнение хотя бы одного из этих условий служит причиной воспроизводства неадекватных методов управления, которые приводят к катастрофическим результатам:
Некомпетентность. Руководитель не самостоятелен. Не имеет необходимого опыта. Не является специалистом в своей области. Сильно зависим от окружения и обстоятельств. Не готов брать на себя ответственность. «Армия львов под управлением барана всегда проиграет армии баранов под управлением льва», (с) Наполеон Бонапарт.
Мнительность. Отсутствие доверия между участниками проекта. Чрезмерная настороженность. Скрытность. Неспособность делегировать полномочия. Руководитель не осознал синергию взаимозависимости и взаимопомощи. Все взаимодействия рассматривает только в духе «выиграл/проиграл».Исходит из предпосылок индустриальной эпохи Генри Форда: «Работники ленивы, поэтому им необходимы внешние стимулы для работы. У людей нет честолюбия, и они стараются избавиться от ответственности. Чтобы заставить людей трудиться, необходимо использовать принуждение, контроль и угрозу наказания». Манфред Кетс де Врис называет данное отклонение «параноидальным управлением».
Ниже приведена лишь небольшая часть существующих антипаттернов управления командами. Однако, перечисленные здесь грабли, на мой взгляд, являются наиболее распространенными и тяжелыми по последствиям наступания на них. Следует заметить, что на практике описанные антипаттерны чаще всего применяются не изолировано, а в той или иной композиции.
О чем?
Некоторые руководители программных проектов, в первую очередь начинающие, в работе с людьми постоянно наступают на одни и те же грабли. В компьютерной науке для подобных частонаступаемых граблей придумано название «антипаттерны» - это повторно используемые практики, которые могут давать видимость эффекта и даже временный эффект, однако, их применение наносит несоизмеримый ущерб конечному результату. Цель статьи - собрать вместе некоторые наиболее тяжелые грабли (антипаттерны), которые встречаются на пути управления командами разработки ПО, и попытаться объяснить, почему на них не стоит наступать.В какое время мы работаем?
Скажу сразу, что ответ: «с 9:00 до 18:00» - неправильный. Мы работаем в век «информатики и кибернетики», который еще называется «постиндустриальное общество». Отличительные особенности этой новой общественно-экономической формации следующие.Эпоха перемен. Все в мире стало непрерывно и стремительно изменяться. Изобилие стало причиной острейшей конкуренции. Инновации - неотъемлемый атрибут нашего времени. «Если у вас медленный доступ в Интернет, вы можете навсегда отстать от развития информационных технологий». Практика должна постоянно перестраиваться применительно к новым и новым условиям. Пример. Hewlett-Packard получает большую долю прибыли на товарах, которые год назад даже не существовали.
Глобализация. Всеобщая взаимозависимость и взаимосвязанность. Транснациональные компании, бизнес идет туда, где дешевле рабочая сила. Интернет. Конкуренция без границ. Пример.Google. За ночь любой из нас в принципе может создать многомиллионную компанию у себя в гараже. С помощью Интернета вы можете выйти на рынок, на котором более 100 млн. потребителей.
Все решают таланты. Простая мобилизация средств и усилий уже не может обеспечить прогресс. Вспомним Ф. Брукса, «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Идею богатства теперь связывают не с деньгами, а с людьми — не с финансовым капиталом, а с «человеческим». Рынок труда превращается в рынок независимых специалистов и его участникам все больше известно о возможных вариантах выбора. Работники интеллектуального труда начинают самостоятельно определять себе цену.
Интеллект - основная производственная сила постиндустриального общества. От 70 до 80% всего, что сегодня делается людьми, делается при помощи их интеллекта. В любом товаре, сделанном в США доля зарплаты - 70 процентов (в России, пока, - только 30). Но, как писал Алан Картер, «Мы, программисты, - из числа наиболее мыслящих людей в обществе», и все, что делается в разработке ПО, создается исключительно при помощи интеллекта.
Известно, что производительность программистов может отличаться в десятки раз. В индустриальную эпоху производительность ручного труда увеличилась более чем в 50 раз. Задача менеджеров XXI века - сделать воспроизводимой высокую эффективность интеллектуальной деятельности.
Наш ответ на вызов времени – это:
Проекты. Сделать то, до чего другие компании еще не додумались, сделать это как можно быстрее, иначе это сделают другие. Предложить потребителю более качественный продукт или такой продукт, потребность в котором потребитель даже не может пока осознать.
Команды. Самоорганизация и самоуправление совместной деятельностью, взаимный контроль, взаимопомощь и взаимозаменяемость, ясность общих ценностей и целей, коллективная ответственность за результаты труда, всемерное развитие и использование индивидуального и группового потенциалов.
Лидерство. Умение руководить людьми сегодня становятся ключом к конкурентному преимуществу. Это искусство достижения выдающихся результатов с помощью обычных сотрудников. Лидеры должны создавать силовые поля, магниты, которые притягивали бы таланты, а не просто служащих, стремящихся занять рабочие места. Никто больше не верит в руководителей, которые всегда правы и притворяются, что знают больше, чем мы. Стадом баранов может управлять пастух. Стае львов нужен лидер.
Заключение или Что надо программисту для счастья?
Что? В вашей компании эти методы работают? Сочувствую. Это означает, что вы наняли не тех, кого следует.Описанные подходы к управлению - наследство из нашего индустриального и аграрного прошлого, где один день был очень похож на другой. Эффективность труда зависела от согласованной работы масс. Работа не требовала большой изобретательности. Труд являлся слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Чем больше повторено стандартных действий, тем больше результат! «Нормирование», «тотальный контроль», «пряник и кнут», «человеческий ресурс – это винтик, который легко заменить», - вот главные принципы эффективного менеджмента предыдущих эпох.
В программировании нет повторяющихся задач. После третьего повторения однотипного действия программист пишет утилиту, которая это действие автоматизирует. Никто пока не знает, каким местом программист думает и как он этим местом это делает. Бессмысленно сажать за его спиной нормировщика-контролера с секундомером. Что он увидит и измерит? Не стоит заставлять программистов работать больше, устраивать сверхурочные, авралы и субботники. Работать больше, это совсем не значит - работать продуктивнее. Наоборот. Излишнее давление и суета приводят к непродуманным решениям, большому проблемному коду и многочисленным последующим дорогостоящим переработкам.
Все, кто пытается примерить методы управления фаст-фудом к разработке ПО, обречены.
Программист устроен просто. Он состоит из четырех компонентов: тело, сердце, разум и душа.
Управление проектами - статьи
Человеческий фактор
Почти все корифеи современной школы бизнеса так или иначе признают, что работа с кадрами имеет гораздо большее значение, чем, например, стратегическое планирование или выстраивание процедур управления производственными процессами. И с этим трудно поспорить, ведь, собственно, кадрам в итоге и придется заниматься разработкой бизнес-схем, стратегий, а также воплощением проектов в жизнь. Поэтому весьма важной целью представляется создание собственной корпоративной схемы организации работы с персоналом. Кроме того, еще ни один проект не провалился из-за недостатков диаграммы Гантта или слабого средства построения расписания. Зато множество проектов не было выполнено в срок либо не было выполнено вовсе из-за того, что их исполнители — обычные люди, с присущими им недостатками. В настоящее время, пожалуй, единственный путь снижения риска невыполнения проекта — выполнение всяческих формальных процедур. Единственным же по-настоящему действенным методом увеличения вероятности реализации проекта служит правильный выбор менеджера проекта. К сожалению, нередко на эту роль выбирается человек, не отвечающий требованиям занимаемой должности.Вообще, управленческую деятельность при выполнении проектных работ можно поделить на три составляющих. Важнейшая из них — точная оценка менеджером индивидуальных особенностей своих подчиненных. Не секрет, что со временем у любого менеджера появляется собственный опытный механизм выявления и подготовки лидеров подшефного ему коллектива, по тем или иным направлениям его деятельности. Кроме того, в организации формируется так называемый конвейер подготовки лидеров и ведущих специалистов, который является важнейшей составляющей мотивации сотрудников, а также базой для реализации долгосрочных планов и стратегий.
Успешный менеджер проекта расходует много времени и усилий на построение доверительных отношений с заказчиками, что может быть критичным для его благополучной реализации. Поразительно, сколько сил тратят компании на CRM в продвижении своих товаров и услуг, совершенно не обращая внимания на эти вопросы при выполнении проектов.
Многие люди, умело руководящие выполнением расписания работ, ужасаются, когда им приходится объясняться с клиентами или решать персональные проблемы членов команды.
В любом случае открытость руководства к персоналу является весьма важным аспектом нормальной работы функциональной группы внедрения проекта. Причем открытость подразумевает не только общую доступность нормативных актов предприятия, но и возможность прямого общения директоров со всем коллективом предприятия и коллектива внедрения. Это особенно важно как для проектно-ориентированных предприятий, так и исследовательско-производственных объединений. Так, еще двадцать лет назад, Кио Марита (один из создателей и директоров компании Sony) в своей книге «Сделано в Японии», четко обьяснил важность общения руководства с подчиненными любых уровней. Например, в компании Sony, вне зависимости от территориального расположения подразделения, существует неписаное правило ежедневных общих обедов, на которых присутствуют абсолютно все сотрудники представительства, включая командированных. Здесь каждый работник может пообщаться с менеджером намного более высокого уровня, чем положено по штату, и в непринужденной обстановке обсудить те или иные производственные проблемы, конфликтные ситуации и методы повышения эффективности труда и производства. Зачастую эффективные рационализаторские решения премируются руководством.
Грамотные менеджеры устанавливают оптимальные связи между членами своей команды, не вызывая столкновений приемов и стилей работы. Они определяют иерархию ответственности внутри команды, знают ее возможности и побуждают к активным действиям, развивают взаимное доверие и используют свою власть для пользы дела.
От руководителя проекта постоянно требуют докладывать о текущих результатах и давать прогноз хода работ, хотя это оказывает наименьшее влияние на конечный успех проекта. Лучшие из них знают, как рапортовать, не вдаваясь в мелочи хода проекта.
Современная организация предприятий требует смягчения жесткого деления на отделы и разделения задач.
Разработка продукта, например, в меньшей степени является плодом усилий изобретателя, а в большей — результатом творческих идей и ноу-хау слаженной команды, реализующей эти замыслы. Чтобы гарантировать максимальный коэффициент полезного действия на всех фазах инновационного цикла, рекомендуется создать соответствующие организационные предпосылки.
Задачи, выходящие за рамки одного отдела, должны обрабатываться совместной командой, тоже выходящей за рамки одного отдела. Таким образом, будет гарантировано, что обмен информацией между специализированными группами в команде проекта происходит непосредственно. Для этого необходимо собрать компетентных и способных работать в команде сотрудников (независимо от их прочих функций и отношений иерархии) из всех важнейших сфер — рынок, техника и организация. В зависимости от проблемы могут быть привлечены к работе сторонние эксперты, например, исследователи рынка, адвокаты по защите патентов.
Оптимальная величина команды для проекта даже высокой сложности составляет приблизительно 6–8 человек. В это число не входят коллективы подрядчиков и исполнителей заказных работ. Группа в 6–8 человек является функциональным, ответственным и одновременно исполнительным коллективом проекта. Создание команд, которые работали бы слаженно и задействовали ресурсы всей компании как бы извне, сводит к минимуму организационные потери при притирке и, прежде всего, притупляют «природный» конфликт между техниками и экономистами.
В любом случае при подборе функциональной команды, прежде всего, необходимо помнить, что профессиональная компетенция членов команды хотя и необходимая, но не исчерпывающая предпосылка. При этом руководители проекта являются ведущими, но ни в коем случае не «всезнайками» — выдвижение новых идей и исправление чужих ошибок лишь приветствуется. Следует понимать, что искренность и готовность к критике ускоряют процесс реализации, а нестандартное мышление членов коллектива помогает достичь ему невиданных высот.
Мотивация в функциональной группе внедрения проекта
В последнее время все чаще применяют так называемые программы мотивации. Их цель — повышение эффективности работы в коллективах. Сегодня данные программы получили особое распространение именно в проектно-ориентированных компаниях.Под программой мотивации подразумевается система мероприятий, выполняемых в течение определенного промежутка времени, направленных на стимулирование определенных сотрудников к определенного рода поведению. Программа мотивации обычно включает в себя цели (для чего необходимо стимулировать сотрудников), четкое описание категории сотрудников и проектов, к которым она применяется, срок действия, критерии, процедуры оценки и ответственные за оценку поведения для различных категорий сотрудников, систему поощрений и взысканий, ответственность за выполнение и невыполнение, бюджет программы.
Логично, что комплекс мер для разных уровней сотрудников относительно иерархической лестницы различен. В общем случае, деление производят на рядовых сотрудников, то есть тех, от кого зависит только порученная им работа, и руководящих — ответственных за выполнение проекта, и технических лидеров, от которых зависит успех проекта в целом.
Если рассматривать конкретно сферу IТ, где как уже отмечалось, наибольшее распространение, имеют проектно-ориентированные организации (построения IТ-отделов компаний в том числе), то разделение следует дифференцировать. Можно рассматривать четыре типа сотрудников, что не cлишком усложняет мотивационное проектирование, однако заметно сказывается на его эффективности. Во главу мотивационной пирамиды ставиться директор проекта, отвечающий за весь портфель проектов и распоряжающийся ресурсами. Ему подчиняется несколько руководителей проекта, отвечающих за его выполнение. Затем в пирамиде следует уровень технического руководителя, имеющего наибольший в коллективе выполняющих работников опыт (отвечает за ключевые технические решения), и замыкает пирамиду сотрудник, отвечающий за конкретную локальную задачу.
Поскольку правильная мотивация подразумевает поощрения или взыскания только за результаты порученных сотруднику работ, руководители проекта и технические лидеры должны премироваться за выполнение проекта в целом.
Таким образом, формировать их премию следует из прибыли от реализации проекта или полученной экономии затрат.
Комплекс мер для поощрения сотрудников разработать сложнее. Во-первых, рядовых исполнителей проекта намного больше, чем менеджеров, а во-вторых, их вклад не так ощутим и контролируем. Если целью программы мотивации объявлено повышение эффективности труда, то измерение действенности мотивации должно предусматривать определение соотношения результата и затрат. Если первый итоговый показатель вычисляется экономическими методами, то затраты обычно являются отражением трудоемкости выполненной задачи. Если отдел, задействованный в проекте, занимается программированием, то резонно установить пороговый минимум программных строк кода, превышение которого повлечет к выдаче премии. Понятно, что показатель количества строк кода или символов документации должен быть приведенным, например, к общему числу структурных модулей программы или количеству разделов технической документации.
Победа любой ценой
«Экспресс-Электроника»Закон Лермана гласит: «любую техническую проблему можно преодолеть, имея достаточно времени и денег». И с этим трудно не согласиться. Впрочем, следствие из этого закона не столь обнадеживающе, сколь он сам: «вам всегда будет не хватать либо времени, либо денег». И на самом деле, любой менеджер, которому хоть раз приходилось сталкиваться с выполнением проекта, знает, что существует определенное соотношение между длительностью выполнения проекта и его стоимостью. А значит, должен существовать оптимальный темп выполнения работ, позволяющий получить эффективный результат при нормальной ставке капитальных затрат.
Современная экономическая теория различает два типа затрат на выполнение проекта — прямые и косвенные, в сумме определяющие полную стоимость проекта. Прямые затраты непосредственно связаны с работами по выполнению проекта. Они учитывают затраты, которые можно спрогнозировать на момент инжиниринга хода выполнения проекта, – заработная плата исполнителей, стоимость используемых материалов и т. д. Важно понимать, что прямые затраты увеличиваются при уменьшении срока выполнения проекта, поскольку это всегда требует дополнительных ресурсов, в том числе материальных. В свою очередь, косвенные затраты, отражающие стоимость аренды используемых при проектовыполнении помещений, налогов и процентной ставки кредита, увеличиваются при «растягивании» сроков сдачи проекта. Таким образом, если отобразить кривые затрат обоих типов в одной координатной плоскости и просуммировать их геометрически, то можно найти точку оптимальной стоимости проекта, которая будет находиться на нижнем экстремуме суммарной стоимостной кривой (рис. 2).
После расчета оптимальной длительности проекта со стоимостной точки зрения, необходимо рассмотреть изменения длины критического пути сетевой схемы, и если возможно, внести соответствующие коррективы. В то же время действия, не являющиеся составляющими критического пути, могут быть продлены намеренно, так как это существенно снижает прямые затраты проекта.
Впрочем, в ряде случаев предложенная методика может оказаться и губительной для проекта. Речь идет о тех ситуациях, когда минимальный срок выполнения проекта становится решающим фактором его успешности. В первую очередь к подобным проектам относятся такие, чьей целью является производство или разработка совершенно нового продукта, появление которого ожидается и у конкурентов. Здесь вступает в действие необходимость создания предпосылок для реализации рыночной стратегии типа «снятия сливок», для многократного покрытия неоправданно высоких капвложений в разработку продукта.
Project Risk Management
Любой проект подвержен рискам, которые, по сути, представляют собой комбинацию ограничений и неуверенности. Управление рисками относится к качественной стороне проекта и включает планирование, организацию, руководство, координацию и управление деятельностью, направленной на предотвращение потерь. Поэтому оценка риска в проекте — самая трудная стадия. Легко понять, например, ограничение по времени — проект должен быть завершен к оговоренной дате. Сложнее определить лимит ресурсов, например рабочих нужной квалификации. Сюда примешивается изрядная доля неуверенности, что необходимые ресурсы вообще можно заполучить. Не в последнюю очередь в числе областей неуверенности и внутренняя политика проекта, то есть личные интересы участников.Следовательно, планирование и учет рисков является, хотя и необязательной составляющей проекта, но все же весьма желательной в общей схеме проектировочных работ. Многие заказчики, например в США, предварительно узнают, при ведении проекта использует ли исполнитель работ практику просчетов рисков. В большинстве случаев можно предпринять ряд предотвращающих действий для уменьшения возможного негативного эффекта риска. Лучше потратить деньги на это, чем после включать непредвиденное обстоятельство в план проекта.
В процессе учета и анализа рисков (PRM) можно выделить две стадии — оценка риска (Risk Assessment) и управление риском (Risk Control). При оценке рисков принимаются во внимание такие факторы, как ясность целей проекта, точность оценки затрат, соответствие требованиям конечных пользователей, разночтения в документации и, не в последнюю очередь, атмосфера в коллективе.
Цель управления рисками — предусмотреть меры, позволяющие избежать тех или иных нежелательных случайностей. Так, должны быть заранее разработаны и планы действий по тревоге. Естественно, всегда подразумевается не полная ликвидация рисков, а их снижение до обоснованного предела.
четкое структурирование стадий выполнения проекта,
Пять составляющих успешного проекта — четкое структурирование стадий выполнения проекта, диаграмма Гантта, методы определения критического пути CPM и PERT, а также соотношение «время/затраты» — являются той основой, на которой строится большинство современных проектов. Оценка рисков позволяет существенно повысить вероятность успешного и своевременного окончания работ. Роль лидера команды — менеджера проекта — также трудно переоценить, и вовсе не тривиальной задачей является поиск подходящей кандидатуры, способной возглавить большой проект. Однако все-таки следует понимать, что предложенные методы лишь инструменты оптимизации ведения проекта, и их использование, равно как и неиспользование не сможет повлиять на успешность или неуспешность проекта. Даже оставив большую часть рутинной организационной работы машинам, человеку все равно придется мыслить и творить.Как добиться успеха в безнадежных проектах
17.10.2002Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.
Все это признаки типичного безнадежного проекта [1]. Интерес к способам решения проблем, возникающих в процессе разработки проектов, не ослабевает. Основной методологией разработки в нашей организации является Rational Unified Process (RUP), поэтому представленные в статье решения ориентированы на продукты компании Rational Software. Однако тех же результатов можно достичь, используя аналогичные инструменты.
Основные черты безнадежных проектов изложены в [2]; там же рассказывается, что делает их таковыми и как их распознать еще до принятия стратегических решений. Напомним факторы, которые переводят проекты в разряд безнадежных:
Информационную систему крайне трудно разрабатывать без четкой методологии. В своих проектах мы используем адаптированную под наши нужды технику RUP. При этом артефакт Business Vision становится Концепцией Системы, документом на 5-10 страниц, описывающим основные архитектурные моменты информационной системы. Business Use Case Model в нашем понимании становится Техническим Заданием (ТЗ), документом, который согласовывается с заказчиком и описывает информационную систему с его точки зрения.
«Оптимизму» разработчиков что- то противопоставить трудно. Каждый программист учитывает время на собственно разработку модуля, не принимая во внимание коммуникации с другими членами команды и вопросы интеграции подсистем. Решение, как обычно в таких случаях, «лежит» на поверхности: необходимо привлекать к обсуждению плана проекта не только руководство, но и непосредственных разработчиков.
Главной причиной недовольства заказчика обычно является непрозрачность процесса разработки. Заказчик выдвигает требования к информационной системе, объясняет бизнес-правила, а системный аналитик, общаясь с ним, разрабатывает ТЗ. Однако «на выходе» система часто не вполне соответствует исходным запросам, особенно в случае изменения условий бизнеса. Поэтому важно сделать заказчика частью команды. В этом смысле очень привлекательна методология экстремального программирования, одним из постулатов которой является присутствие заказчика «в одной комнате с программистами». Заказчик объясняет user story (ключевые функции информационной системы), и ее реализуют за строго определенное время.
К сожалению, «идеальных» заказчиков мало и проблемы прозрачности и изменяющихся требований приходится решать иными методами. Для наглядности информации в ТЗ мы применяем графические стереотипы основных терминов и понятий системы; до написания кода приложений согласуем формы интерфейса, а текущая бизнес-модель, автоматически сформированная модулем WebPublisher из Rational Suite, всегда доступна для просмотра в формате HTML. В случае изменения бизнес-требований заказчик сообщает об этом системному аналитику, и тот исправляет модель информационной системы. Проектировщик определяет масштабы изменения и отражает их в ТП, а затем передает новую постановку задач программистам (рис. 2).
 |
Рис. 2. Технология цикла разработки |
Чтобы совещание было успешным, следует учесть ряд моментов. Тему совещания надо четко определить, подготовив список конкретных вопросов; приглашаются только нужные люди с полномочиями принятия решений; оптимальное число участников — 4–7 человек; по каждой проблеме нужно достичь хотя бы временного, «промежуточного» решения.
Разработку легче, эффективнее и самое главное дешевле вести, используя дорогих профессионалов: системных аналитиков, архитекторов, проектировщиков, кодировщиков и тестировщиков. Однако эти рекомендации применимы только для тех организаций, которые вышли на достаточно высокий уровень финансовой и информационной зрелости. В наших условиях больше подходит вариант, когда к одному «гуру» прикрепляется от одного до трех «учеников». Большинство сотрудников заинтересовано в профессиональном росте и, как следствие, в повышении самооценки и возможности успешной карьеры. Не менее важно обеспечить получение удовлетворения от сделанной работы и налаживание атмосферы сотрудничества в команде.
Как известно, среди проблем проектирования ключевое место занимает проблема отсутствия концептуальной целостности и непротиворечивости архитектуры. Поэтому важно назначить архитектора продукта, ответственного за все его стороны. Кроме того, необходимо отделить архитектуру (т.е. определение продукта в восприятии пользователя) от его разработки [1]. Однако ничто так не вредит переходу от проектирования к программированию, как оторванность ТЗ от реального кода. Системного аналитика и проектировщика нужно подключить к программированию. Это позволит добиться осведомленности системного аналитика (а, следовательно, и заказчика) и проектировщика о реальном положении дел, лучшей согласованности между архитектурой и реализацией, более действенной коммуникации. Именно так можно построить эффективную команду, а не просто группу разработчиков.
В этих аргументах есть некоторые расхождения с «постулатами» RUP, но на практике безусловное разделение функций между архитекторами и исполнителями, чьи творческие таланты и идеи подавляются, приводит к плачевному результату.
Архитекторы «витают в облаках», разрабатывая маловразумительные спецификации, а кодировщики вынуждены заполнять информационные пробелы собственным пониманием проблемы, о чем аналитик и заказчик узнают последними. Дело вовсе не в том, чтобы дать кодировщикам широкие возможности по реализации своих творческих замыслов, напротив, «собственное мнение» кодировщику противопоказано — программирование сегодня не искусство, а ремесло. Однако довести до архитекторов проблемы непосредственно кодирования необходимо; менеджер проекта должен представлять себе, как диаграммы, прекрасно выглядевшие на бумаге, реализуются в коде. Поэтому наиболее эффективно привлечение многофункциональных специалистов, имеющих знания в нескольких смежных областях. Разработка программного обеспечения более сложна, многообразна и непредсказуема, чем конвейерное производство типовых моделей.
Непонимание между заказчиком и разработчиком требует создания единого словаря терминов разрабатываемой информационной системы. У нас такой глоссарий системы представляет собой продукт совместной разработки системного аналитика и проектировщика. С учетом того, что модели ТЗ и ТП создаются с помощью CASE-инструментария Rational Rose, мы используем возможность автоматизированного управления глоссарием, который находится в отдельной модели, доступной по сети всей команде. Только один человек добавляет или модифицирует данные глоссария, остальные же автоматически получают его текущую версию при работе со своими моделями. Эта возможность обеспечивается за счет синхронизации информации в разрабатываемой модели (\\Project.mdl) и глоссария, встроенного «по ссылке» в модель, но в то же время существующего отдельно (\\Glossary.cat). Благодаря этому становится реальной параллельная работа системных аналитиков и проектировщиков при централизованном управлении глоссарием и последовательной обработке запросов на его изменение (рис. 3).
 |
Рис. 3. Работа с глоссарием |
Наше решение зависит от требований заказчика, штатной структуры компании и функциональных обязанностей служащих. При этом обеспечивается максимальная интеграция с уже существующим программным обеспечением; автоматизируются только те участки, в которых возникла необходимость и которые реально переработать за установленные сроки и в конкретных условиях, остальное же остается «как есть» и разрабатываются «переходники» для связи между «новыми» и «старыми» модулями.
Среди проблем собственно кодирования, следует выделить нежелание использовать компоненты сторонних производителей; между тем, часто дешевле купить готовый модуль, чем разработать, протестировать и внедрить собственный. При написании кода также могут использоваться готовые программные конструкции, так называемые «паттерны» (design pattern). Последняя версия Rational Rose XDE поддерживает паттерны и интегрирует их с Visual Studio .Net.
Хорошим проектным решением является стандарт на оформление программных форм, нормативы на количество и размеры информационных и управляющих элементов, характеристики цветовой гаммы и т.п. Помочь в данном случае может стандартный репозиторий программных форм. Кроме того, программный код обязательно оформлять с учетом так называемых «правил кодирования», приняв соглашение по форматированию, названиям объектов, механизмам использования памяти и обработки ошибок и т.п. Нашей организации разработать полноценный стандарт кодирования еще предстоит, поэтому пока для нужд непосредственно программирования используется репозиторий объектов. Сотрудник, ответственный за техническую поддержку репозитория, модифицирует его с учетом изменяющихся требований по функциональности и эффективности форм. Кроме того, в связи с использованием метода round-trip engineering (синхронизация между кодом и моделью в обоих направлениях) с помощью RoseDelphiLink_3_2, разработано положение о документировании программного кода, цель которого — автоматическое получение документации через шаблоны Rational SoDA. В перспективе будет использоваться инструментарий компании BoldSoft, средства которого вошли недавно и в Borland Delphi7 Architect Studio.
Ни один заказчик не станет читать ТЗ на две сотни страниц, но лучше иметь избыточную и плохо структурированную информацию, чем не иметь ее вовсе. В [3] приводится график сравнения ее разновидностей — на первом месте по эффективности стоит живое общение, а далее следуют телефонная связь, электронная почта, видео- и аудиоконференции, и, наконец, бумажная документация (рис. 4).
 |
Рис. 4. Эффективность различных видов коммуникаций |
 |
Рис. 5. Принцип работы автодокументирования |
Однако технике RUP присущи и ограничения: «вольность» при трактовке формулировок и концепций, обилие документации и проработка только этапа моделирования бизнес-процессов.
Поэтому в случае ориентации разработки на быстрый результат, относительной легкости проекта и отсутствия проблем по его сопровождению (как у Web-проектов), лучше, возможно, подходят «быстрые» методологии (например, экстремальное программирование). RUP позволяет справляться с безнадежными проектами: такой «недостаток», как обилие документации, превращается в достоинство, позволяющее четче определить роли и обязанности участников. Проекты тянут ко дну, в основном, административные проблемы, а это решается обычно «бумажным» путем.
Литература
Управление проектами - статьи
Анализ и проектирование
На следующем этапе проектирования разработчики отвечают на вопрос «Как должна быть построена система, чтобы реализовать определенные на предыдущем этапе требования». Признанным стандартом моделирования архитектуры объектно-ориентированных приложений сегодня стал язык UML. В системах проектирования на базе UML создаются диаграммы, которые в совокупности представляют единую концепцию программного продукта. Затем набор диаграмм переводится в конкретный язык программирования. Помимо разработки архитектуры новых приложений, средства проектирования позволяют создавать визуальные представления существующих систем и анализировать их внутреннюю структуру для повышения эффективности внесения изменений в такие программы. Безусловно, наиболее известным решением в области UML-проектирования остается система Rational Rose.В результате приобретения компании TogetherSoft, Borland стала обладательницей собственной серии продуктов Together для анализа и проектирования. Центральной в этом семействе является интегрированная многоязыковая среда проектирования и разработки ControlCenter, поддерживающая визуальное моделирование на UML приложений как для платформы J2EE с последующим написанием кода на Java, так и для платформы .Net на языках С#, C++ и Visual Basic .Net. Кроме базовой версии доступен экономичный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere, для интегрированной среды разработки Jbuilder и для открытой среды Eclipse.
Together ControlCenter реализует генерацию исходных кодов по последовательности UML-диаграмм. В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями — при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменится текст на языке программирования. Все это происходит в реальном времени и исключает необходимость вручную модифицировать модель или переписывать коды.
Наличие подобных возможностей наряду с соответствием стандарту UML в Aberdeen Group [4] считают ключевыми критериями выбора эффективной системы моделирования. Контроль версий осуществляется благодаря функциональной интеграции решений Together и системы StarTeam. Также поддерживается интеграция с системой конфигурационного управления Rational ClearCase. Помимо проектирования и разработки компонентных приложений для платформ J2EE и .Net, ControlCenter поддерживает визуальное XML-моделирование, моделирование бизнес-процессов, разработку Web-сервисов и баз данных.
Важной особенностью систем семейства Together является то, что они предоставляют средства автоматизированного инспектирования исходных кодов для повышения качества архитектуры и реализации программ. Сюда относятся средства аудита и оценки программ на базе метрик, дополняющие традиционные способы проверки кода вручную. Как отмечается в [5], проверка кода (code review) как важнейший инструмент повышения качества разрабатываемого продукта не теряет своей актуальности и в «быстрых» методиках. Скажем, в ХР проверка кода является непрерывным процессом, поскольку экстремальное программирование обязывает работать над исходными текстами в парах. Обычно результатом проверки кода становится рефакторинг (refactoring), т.е. изменение внутренней структуры программы с целью упрощения ее понимания и снижения затрат на модификацию.
Проверка кода является частью процесса инспектирования программных средств — оценка программного продукта, в ходе которой группа специалистов, среди которых не должно быть автора программы, проверяет требования, архитектуру или код программы с целью выявить ошибки, нарушения корпоративных стандартов и другие проблемы [2]. Что касается проверки кода, то она не только способствует тому, что программа становится более понятной и простой в сопровождении, но и позволяет повышать квалификацию новых специалистов в команде разработчиков. Определенная часть этой работы, например, оценка уровня реализации бизнес-логики программы, остается за человеком.
Но для целого ряда функций автоматизация способна значительно повысить эффективность и продуктивность процесса проверки. Например, в компании TogetherSoft четырем специалистам было поручено провести в течение 15 минут аудит небольшого фрагмента программы на Java. За это время ими было выявлено 21 нарушение, в то время как средствами ControlCenter в том же фрагменте исходного кода всего за 2 секунды было обнаружено 150 несоответствий принятым стандартам программирования на Java [5].
Аудит — статическая проверка исходного кода программы с целью нахождения несоответствий принятым в организации стандартам использования языка программирования. В ControlCenter для языков Java и С++ реализованы такие категории аудита исходного кода, как стиль кодирования, критические ошибки моделирования, документирование, именование, производительность, общие ошибки использования языка, чрезмерный объем кода, ошибки в использовании EJB и др.
Более «тонкой материей» в процессе проверки кода является оценка на базе метрик. Если аудит сосредоточен главным образом на синтаксическом анализе текста программы, то метрики позволяют оценить уровень ее объектной архитектуры. Метрики — это точные количественные данные, на основе которых оцениваются размер, сложность и зависимости в тексте программы, а реализация метрик — попытка подвести математическую основу под такую расплывчатую категорию, как качество программы. Оценка на базе метрик позволяет устранить нарушения базовых принципов объектно-ориентированной разработки и провести эффективный рефакторинг программы. Сбор и анализ метрик — крайне трудоемкая задача, поэтому оценка на базе метрик только выигрывает от автоматизации. Together обеспечивает анализ на базе метрик для таких категорий, как базовые эвристики, зависимости, связи, инкапсуляция, размер программы, наследование, соотношение комментариев и т.д., для языков программирования Java, C++, C#, Visual Basic 6 и VB.Net.
Координация и управление изменениями
В системе управления конфигурациями и изменениями сосредоточена сущность концепции ALM: именно она объединяет основные фазы жизненного цикла приложения и интегрирует продукты, эти фазы поддерживающие, поэтому управление изменениями вместе с системой StarTeam расположено в центре круговой диаграммы управления жизненным циклом «от Borland» (рис. 1).StarTeam, появившаяся у компании в результате приобретения Starbase, имеет развитую функциональность, которая помимо базовых для систем конфигурационного управления задач контроля версий включает управление изменениями, отслеживание дефектов, пересмотр файлов, управление требованиями (в интеграции с CaliberRM), управление потоком задач и управление проектом, а также дискуссионные форумы. Система рассчитана на распределенные проектные группы и поддерживает совместную работу участников, в том числе географически удаленных, через Сеть.
StarTeam предоставляет централизованный репозиторий для хранения и совместного использования членами проектной группы информационных активов проекта, которые привязываются к соответствующим инструментальным средствам и процессам жизненного цикла. Система обеспечивает доступ к актуальной информации по проекту тем членам группы, которым она предназначена, осуществляя контроль прав доступа на разных уровнях — от проекта в целом вплоть до отдельного ресурса. Система управляет потоком запросов на изменения, выставляет приоритеты и исключает дублирование, проверяет выполнение изменений и обеспечивает генерацию сообщений ответственным за изменение членам проектной команды. StarTeam предоставляет возможности управления задачами, обеспечивая назначение работ определенным группам специалистов в проектной команде. Например, завершение разработки некоторой части приложения будет отражено в подсистеме управления изменениями, затем StarTeam выдаст задание на проведение соответствующих тестов. Этот компонент системы интегрирован с MS Project. Кроме того, в StarTеam формируется база знаний о проблемах, которая используется членами команды во время проведения централизованных дискуссионных форумов.
StarTeam совместима с интерфейсом Microsoft Source Code Control и легко интегрируется с любой системой разработки, которая поддерживает этот API. Кроме того, в системе реализованы средства интеграции со средами разработки и моделирования Together, JBuilder, Delphi, C++Builder и C#Builder.
MDA
Вся эволюция программирования, основанная на стремлении снизить сложность и повысить продуктивность процессов разработки, сопровождалась повышением уровня абстракции написания программ — от машинных кодов к ассемблеру, от ассемблера к высокоуровневым языкам. Предложенный OMG подход MDA (model-driven architecture) позволяет при создании приложений сконцентрироваться на создании абстрактной бизнес-модели, практически полностью автоматизировав ее перевод в коды на базе конкретной инфраструктуры промежуточного слоя — CORBA, EJB, COM+, .Net и т.д. | |
Рис. Три этапа реализации Model-Driven Architecture |
Разработка в соответствии с принципами MDA проходит в три этапа (рис.4). На первом создается полностью независимая от среды разработки и платформы визуальная UML-модель, описывающая бизнес-логику будущего приложения (доменная модель). Для ее формирования стандарт OMG MDA предоставляет несколько базовых моделей, описывающих структуру определенной бизнес-среды, например, базовая модель Enterprise Computing с компонентной структурой и взаимодействием на основе транзакций или модель Real-Time Computing с специальными механизмами контроля ресурсов. На следующем этапе абстрактная модель «конкретизируется», преобразуясь в UML-модель приложения для определенной платформы. Модель приложения включает специфические для данной архитектуры элементы построения и интеграции прикладных систем, сохраняя семантику доменной модели. Третий этап завершает трансформацию модели в коды программы. Для автоматизации последовательного преобразования модели от этапа к этапу используются шаблоны, отображающие специфику технологической платформы и языка реализации приложения.
Формирование логики приложения на самом высоком уровне абстракции и автоматическая генерация всех элементов, связанных с платформой реализации приложения способствуют сокращению сроков проектирования, тестирования и развертывания, полностью исключая затраты времени и сил на кодирование. Последнее обстоятельство гарантирует высокое качество кода. Примеры реализации MDA — системы Compuware OptimalJ и Borland ECO.
Определение требований
Все большую актуальность приобретает выстраивание правильных взаимоотношений между ИТ и бизнесом, разработка и внедрение таких решений, которые дадут реальную отдачу за минимальное время и при этом будут завершены в запланированные сроки и в рамках выделенного бюджета. Первый шаг к достижению этого идеала — формальное определение требований к будущей системе.По определению IEEE [2], требование — это «условие или возможность, необходимые пользователю для решения той или иной проблемы или достижения той или иной цели». Управление требованиями определяется аналитиками Meta Group [3] как процесс, гарантирующий, что все специалисты, вовлеченные в проект разработки, знают об определенных требованиях к программному продукту и реализуют процессы, позволяющие эти требования удовлетворить. При всей очевидности того, какое значение имеет четкое задание требований для получения качественного конечного продукта и повышения продуктивности участников разработки, этот этап — и тем более его поддержка с помощью специальных автоматизированных средств — далеко не всегда реализуется со всей необходимой тщательностью. Разработчики часто избегают формализации требований как лишней бюрократической нагрузки, мешающей главному, по их мнению, процессу — собственно программированию. Заказчики также не всегда готовы формализовать и детализировать свои проблемы, полагая, что общей постановки задачи достаточно для того, чтобы разработчики поняли их нужды. Обе стороны заблуждаются. Формальное определение требований со стороны заказчика помогает ему прояснить свои потребности и избежать неясностей в толковании постановки задачи разработчиками. Последние, в свою очередь, получают большую свободу в выборе средств и методов реализации, когда задача понятна до деталей.
Этап определения требований — основная точка для осуществления взаимодействия между заказчиком и командой проекта. Одновременно это и ключевой этап для всего жизненного цикла, непосредственно влияющий на качество программного продукта.
Практика показывает, что чем позже будут выявлены ошибки в постановке задачи и соответственно неверно реализованные функции, тем дороже обойдется их исправление.
Процесс управления требованиями необходим, чтобы соответствовать второму, «повторяемому» уровню зрелости разработки программного обеспечения по модели СММ. Использование обычных офисных программ позволяет получить формальные описания и даже стандартизовать форматы требований для разных групп проектной команды, но не дает возможности отслеживания и совместной работы с требованиями, а также ограничивает средства обработки более сложной структуры атрибутов требований. Поэтому, начиная с третьего уровня зрелости процессов управления требований, наличие специального инструментария становится абсолютно необходимым, а наиболее высокий уровень, кроме того, потребует их тесной интеграции с другими решениями, которые используются для поддержки различных этапов жизненного цикла. Минимальный набор функций для системы управления требованиями включает средства идентификации отдельных требований, сортировку, идентификацию пересмотра в группе требований, базовый интерфейс данных. Более мощные по своим возможностям системы обеспечивают отслеживание зависимостей между требованиями, поддержку совместной работы и интеграцию со средствами моделирования, разработки и тестирования.
По данным Meta Group, 75% инсталляций систем управления требованиями принадлежит Borland, IBM Rational и Telelogic. При этом все три компании — относительные новички на этом рынке, поскольку решения по управлению требованиями были приобретены ими за последние два года. Так, система CaliberRM стала частью семейства продуктов Borland в результате покупки компании Starbase. В CaliberRM формируются шаблоны для наборов требований заказчика, которые собираются в центральном репозитории. Система предоставляет встроенную поддержку обсуждения требований различными участниками процесса. Права доступа к данным требований, привилегии и ответственность пользователей определяются в системе на ролевой основе.
CaliberRM способна поддерживать различные методы разработки, как структурные, так и приобретающие все большую популярность «быстрые» (agile) методики. В частности, имеются механизмы работы с форматами требований, принятыми в экстремальном программировании. Кроме того, предусмотрены простые средства настройки ролей, уровней управления требованиями и т.д. в зависимости от среды разработки, с которой будет работать пользователь. Поскольку CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генерации документов Word на базе заданных шаблонов.
Система обеспечивает экспорт данных в таблицы MS Access и импорт из Word, но пока не поддерживает обмен данными на базе XML Metadata Interchange. Табличное представление требований упрощает их сортировку и задание приоритетов в зависимости от затрат на реализацию и значимости. Для каждого требования реализуется независимый контроль версий. Предоставляются глоссарии для определения специфичных для отрасли, проекта или компании терминов с целью избежать нечеткости определения и двусмысленности толкования требований. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.
CaliberRM обеспечивает функциональную (на базе прикладных интерфейсов) интеграцию с другими ALM-решениями Borland — системой конфигурационного управления StarTeam и средой моделирования Together, что позволяет отслеживать влияние изменений в требованиях на исходный код и гарантировать соответствие архитектуры системы задачам заказчика. Интеграция системы со средствами тестирования компании Mercury Interactive обеспечивает быстрый выбор необходимых тестовых испытаний для проверки выполнения заданных и измененных требований, а возможность экспорта данных в систему календарного планирования MS Project — отображение требований как задач проекта.
Разработка
В течение почти всей своей 20-летней истории деятельность Borland была сосредоточена именно на создании сред разработки, причем отличительной чертой этой компании был стабильный нейтралитет в отношении платформ — Borland предлагала инструментарий как для Java (JВuilder), так и для Windows (Delphi, C++Builder). Принципиальная позиция этой «Швейцарии» в мире разработки получила логическое продолжение в выпуске новых систем для платформы .Net.Основные усилия по совершенствованию сред разработки Borland сосредотачивает сегодня на интеграции с другими этапами жизненного цикла приложений, прежде всего, с решениями по анализу и проектированию Together. Уже упоминалась редакция Together для системы JВuilder, которая обеспечивает разработку компонентных приложений на платформе J2EE. Связь со средствами моделирования программ реализована и в новой среде разработки C#Builder для платформы .Net Framework, которая имеет также возможности интеграции с системами тестирования и средствами развертывания приложений.
C#Builder — среда разработки на языках С# и Visual Basic .Net. Одно из ключевых свойств этой системы — предоставление единого интерфейса для работы с разными базами данных. В C#Builder поддерживаются драйверы доступа к данным из ADO.Net, но их возможности существенно расширены с помощью модуля Borland Data Provider (BDP). Пользователь выполняет все операции с данными и SQL-запросы с помощью общего для всех разновидностей баз данных интерфейса Data Explorer, а BDP осуществляет автоматическое преобразование типов данных .Net в типы для различных баз данных, включая Oracle 9i, IBM DB2, Microsoft SQL Server 2000, Borland InterВase. C#Builder включает широкий спектр технологий, необходимых для работы распределенных приложений: Web-сервисы, компонентные среды СОМ+ и .Net Remoting, а также CORBA и EJB, для которых используются механизмы еще одной новой разработки Borland — системы Janeva.
C#Builder поддерживает новую парадигму разработки, определяемую проектированием (design-driven development), известную также под названием МDA (model-driven architecture). Спецификации MDA разработаны консорциумом OMG [6], а Borland одной из первых реализовала MDA в конкретном инструментарии. Речь идет о системе Enterprise Core Objects (ECO), которая позволяет без программирования получить работающую программу для .Nеt непосредственно по UML-модели, созданной средствами Together или импортированной из другой системы моделирования с помощью механизмов XMI. На C# пишется только пользовательский интерфейс. Усилия разработчиков могут быть сосредоточены на бизнес-логике и ее воплощении в модели, а программу на C# они даже не видят.
Развертывание
У того, кто ведет разработку на Java, есть широкие возможности выбора сервера приложений для развертывания готовой системы, в частности, Borland предлагает сервер приложений Enterprise Server: AppServer Edition для J2ЕЕ-приложений и Web-сервисов; VisiBroker Eition для распределенных приложений в гетерогенной среде, требовательных к времени отклика и ориентированных на инфраструктуру CORBA; Web Edition для Web-приложений.Для платформы .Net выбор среды развертывания ограничен, и, хотя компьютерный мир все более склоняется к мысли, что война между J2EE и .Net не имеет смысла — каждая из платформ найдет свою нишу применения. Компании, ведущие свой бизнес в сфере финансов или телекоммуникаций, уже сделали значительные инвестиции в приложения на базе J2EE и CORBA, поскольку эти среды гарантируют масштабируемость, безопасность и высокую производительность транзакций. С другой стороны, в тех же организациях может возникнуть интерес к использованию .Net на уровне фронт-офиса. Вполне жизненна ситуация, когда новые приложения для .Net должны внедряться в корпоративную инфраструктуру, давно и успешно использующую технологии J2EE и CORBA. Интеграция двух сред с помощью Web-сервисов не эффективна, если речь идет о компонентах одной прикладной системы, поскольку Web-сервисы больше рассчитаны на взаимодействие слабо связанных приложений и не обеспечивают быстрого и надежного транспорта для передачи данных. Развитие протокола SOAP в сторону обеспечения более высокой производительности и защищенности передачи не изменит его сути, которая не позволяет реализовать на базе Web-сервисов тесную интеграцию, необходимую для многих приложений и поддерживаемую CORBA. Предлагаются и технологии специальных «мостов» между двумя платформами, но для них, как правило, требуются дополнительные аппаратные и программные ресурсы. Кроме того, такие мосты порождают точки потери производительности и отказа системы.
Для Borland отсутствие приверженности отдельно взятой платформе или стеку протоколов — почти религиозный принцип.
Очередной важный шаг на этом пути состоит в выпуске продукта, обеспечивающего прозрачную совместимость приложений для .Net с инфраструктурами J2EE и CORBA. Речь идет о системе Janeva.
Janeva предоставляет клиентским и серверным программам для .NET возможность обращаться к гетерогенным серверным компонентам J2EE и CORBA, причем совершенно прозрачно для разработчика этих программ и не требуя использования дополнительных аппаратных или программных ресурсов (см. рис. 3). Janeva включает компиляторы Java-to-C# и CORBA IDL-to-C#, которые автоматически генерируют коммуникационные элементы — стабы (stubs) и сборки (assemblies) на языке C#. Тем самым обеспечивается возможность обращения к .Net из Java-программ и объектов CORBA. Кроме того, Janeva предоставляет библиотеки времени выполнения, которые вызываются .Net-приложением для преобразования удаленных вызовов этой платформы в вызовы по IIOP (Internet Intеr-ORB Protоcol) — производительному, масштабируемому и защищенному протоколу для связи распределенных компонентов в среде CORBA. Таким образом, пользователь Janeva продолжает работать в привычной среде .Net, используя интерфейсы, процедуры определения свойств и вызова методов и типы данных, и при этом получает доступ к объектам CORBA и компонентам EJB. В результате совместимость двух платформ достигается минимальными усилиями и практически без риска для проекта. Janeva поддерживает Microsoft Common Language Runtime, поэтому может быть использована для любого языка программирования, совместимого с CLR, включая C#, J#, Visual Basic .Net и Visual C++ .Net.
 |
Рис. 3. Интеграция платформ средствами Janeva |
Тестирование и профилирование
Чем позже будут обнаружены ошибки и уязвимые места программы, тем дороже обойдется их исправление, поэтому наиболее оптимальное время разрешения проблем — разработка (рис. 2).Основные виды тестирования включают модульное тестирование (проверка отдельных подсистем), функциональное тестирование (выявление ошибок кодирования), регрессионное тестирование (поиск дополнительных ошибок, возникающих при изменении кода), выявление возможностей приложения сохранять работоспособность в экстремальных условиях, нагрузочное тестирование (проверка масштабируемости приложения по числу пользователей и размеру базы данных), контроль производительности с использованием средств профилирования рабочих параметров прикладной системы в реальном времени.
Серия соответствующих инструментальных средств появилась в составе пакета поддержки жизненного цикла от Borland в результате покупки компании Optimizeit. В семейство продуктов контроля производительности входят Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace. Первые две системы позволяют до развертывания системы выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и Microsoft .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, а Optimizeit Profiler — в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности с наименьшими затратами. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-приложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.
По сравнению с нагрузочным тестированием, средства профилирования обеспечивают более высокий уровень детализации испытаний. В ряде случаев диагностики систем нагрузочного тестирования достаточно, чтобы выявить причину замедления работы, например, появление дополнительного сервера или увеличение размера кэша.
Но, как правило, требуется дальнейшее тестирование с использованием средств контроля производительности, поэтому значительное преимущество разработчики и тестировщики могут получить от интеграции этих категорий инструментальных систем. Такая интеграция позволяет проводить испытания приложения в условиях эмуляции рабочей нагрузки и при выявлении узких мест, переходить к профилированию с целью определения точной причины возникшей проблемы. При этом система нагрузочного тестирования ограничивает область поиска, и разработчик может более направленно проводить профилирование, экономя время на сбор и анализ данных. Кроме того, интеграция со средствами профилирования стимулирует проведение нагрузочных испытаний в ходе разработки, а не после того, как приложение собрано полностью.
Средства профилирования семейства Borland Optimizeit интегрированы с системой нагрузочного тестирования LoadRunner от Mercury Interactive. Кроме того, в среду разработки JВuilder интегрирован продукт Mercury ТestDirector для управления скриптами тестирования.
В круге разработки
Наталья Дубова18.09.2003
С ростом сложности архитектуры программных систем растет трудоемкость их разработки и развертывания, усложняются сценарии интеграции, растут расходы на сопровождение. Традиционная интегрированная среда разработки предоставляет базовые инструменты — редакторы кода, компиляторы, средства разработки пользовательского интерфейса и отладчики, однако за ее пределами остаются ключевые этапы жизненного цикла приложений.
Для удовлетворения общих требований к разработке — снижения затрат путем повышения продуктивности труда разработчиков и уменьшения сложности разработки, не в ущерб качеству конечного продукта — традиционно используются интегрированные среды разработки (integration development environment, IDE), предоставляющие базовые инструменты. Однако за их пределами остаются ключевые этапы жизненного цикла приложений, такие как определение требований, моделирование, тестирование, развертывание и управление изменениями. Поддерживающие эти этапы инструменты, как правило, изолированы друг от друга. В результате группы специалистов, отвечающие за разные задачи в проекте — бизнес-аналитики, архитекторы, программисты, тестировщики — работают разрозненно. Как отмечают в Meta Group [1], подобное состояние вполне соответствует традиционной методологии разработки, когда отдельные процессы идут последовательно друг за другом, но отнюдь не отвечает современным требованиям повышения продуктивности и сокращения затрат. Метод «водопада», как правило, удлиняет время реализации программного проекта, приводит к превышению бюджета и не способствует созданию продукта, отвечающего ожиданиям заказчика. Это своего рода производственный конвейер, рассчитанный на массовый выпуск однотипной продукции.
Разработка программного обеспечения — это цикличный процесс создания уникального продукта, который совершенствуется от версии к версии; разные, не всегда последовательные этапы могут влиять друг на друга. По существу, созданию программного продукта больше соответствует не модель управления проектом с четким началом и концом, а модель управления всем жизненным циклом продукта.
Цикличному ходу разработки больше подходят итеративные методики, подразумевающие постоянное сотрудничество между разными функциональными группами в команде программного проекта и конечными пользователями и тесную взаимосвязь между разными этапами жизненного цикла приложения. Однако для эффективной реализации итеративных принципов нужны интегрированные среды совсем иного качества. Концепцию такой среды предлагает, в частности, компания Borland, которая в результате развития собственных разработок и приобретения целого ряда компаний представила пакет интегрированных систем, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM).
Виды интеграции
Концепцию управления жизненным циклом приложения невозможно реализовать без интеграции инструментальных средств, используемых на разных этапах. Стратегическая задача Borland на ближайшие несколько лет — обеспечить полную прозрачность и отслеживаемость всех процессов разработки в течение жизненного цикла; она решается путем интеграции всех систем в полное ALM-решение [7]. Уже сегодня многие системы Borland имеют развитые возможности взаимосвязи не только друг с другом, но и с системами других поставщиков. Так, совместная работа системы проектирования Together с системой согласования требований CaliberRM позволяет рассматривать в процессе проектирования только те функции, которые предусмотрены на этапе определения требований. Интеграция Together Edition for Jbuilder и IDE Jbuilder обеспечивает непосредственное отображение изменений UML-модели в тексте программы. Аналогичные возможности существуют для среды IBM WebSphere. Система StarTeam управляет этими изменениями, а новые редакции инструментов Borland для платформы .Net позволяют использовать в качестве среды разработки не только C#Builder, но и Visual Studio .Net.В Borland выделяют три уровня интеграции. Большинство реализованных сегодня возможностей взаимосвязи систем основано на принципах «функциональной» (touch-point) интеграции, которая позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системе проектирования Together и системах разработки C#Builder и Visual Studio .Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечивает единого рабочего пространства, вынуждает пользователя переключать окна и подчас приводит к дублированию процессов управления структурой проекта.
Более перспективны высокие уровни интеграции. «Встроенная» (embedded) интеграция обеспечивает работу с окном одной системы, находясь при этом в другой. Например, не выходя из среды разработки Jbuilder можно просматривать графики производительности, которые создает система испытаний Optimizeit. И наконец, самый высокий уровень интеграции — «синергетический» (synergistic), позволяющий прозрачно сочетать функции двух различных продуктов, так чтобы разработчики даже не замечали, что работают с разными системами. Для большинства решений Borland и других поставщиков синергетическая интеграция — дело будущего, однако ее принципы уже реализованы с помощью технологий Janeva. Janeva обеспечивает взаимное конвертирование между платформами J2EE и .Net, так что программные продукты для .Net могут напрямую использовать компоненты на Java, при этом от разработчиков таких приложений не требуется знаний в области объектных технологий CORBA и EJB.
и развертывания приложений, испытавший определенный
По прогнозам IDC [8], рынок средств разработки и развертывания приложений, испытавший определенный кризис в 2002 году, в ближайшее пятилетие ожидает устойчивый рост в среднем на 6,3% в год. Определяющим фактором для развития этой положительной тенденции является стремление компаний-разработчиков повысить продуктивность своей работы, сократить сроки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу на сделанные инвестиции. Инструментом для достижения этих целей становится использование сред разработки, позволяющих снизить сложность процессов создания программных продуктов, увеличить их эффективность, уменьшить затраты на разработку и максимально использовать потенциал новых технологий. Аналитики сходятся на том, что основное направление развития инструментальных средств — их сквозная интеграция, переход от сред к интегрированным пакетам, объединяющим возможности определения требований, моделирования, разработки, тестирования, управления изменениями и развертывания приложений. В ближайшие годы такие пакеты поддержки жизненного цикла, помимо перечисленных возможностей будут включать в себя средства управления потоками работ и проектами. Рынок таких инструментальных средств ожидает глобальная консолидация, обещающая принести значительные выгоды разработчикам.Литература
IDC, March 2003.
В методологии Rational Unified Process (RUP), предложенной компанией Rational Software, определяются пять уровней зрелости управления требованиями:
Чтобы соответствовать первому уровню, достаточно взять стандартный тестовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие информационные модели в жизненном цикле разработки.
«Живое» программирование
Требования рынка заставляют ускорять циклы разработки, но не позволяют снижать качество. Необходимость делать все быстро подчас вынуждает отказываться от следования строго документированным процессам разработки, однако отсутствие четкой организации труда отрицательно сказывается на продуктивности команды и, в итоге, на конечном результате их работы. Поиск компромисса между сложными формальными процессами и облегченными методами быстрой разработки привел к появлению методологии разработки под названием agile («проворный», «быстрый», «живой»). Принципы данного подхода сформулированы в Agile Manifesto (www.agilemanifesto.org), который был написан в феврале 2001 года семнадцатью представителями ряда «нетрадиционных» направлений в программировании, включая XP [1], Feature Driven Development, Crystal, Adaptive Software Development, SCRUM.В новом подходе на первый план выходят креативные возможности ярких индивидуальностей в коллективе программистов. При этом стимулируется максимальное использование потенциала совместной разработки в сочетании с минимумом ограничений, накладываемых формальными методами и процессами. Постоянное взаимодействие с заказчиками предпочитается строгому следованию формальным спецификациям, и работа организуется таким образом, чтобы быстро реагировать на изменения в требованиях, а не пунктуально реализовывать изначально заданный план. Процесс создания программного обеспечения по принципам agile должен обладать рядом ключевых характеристик [2].
Поэтому итеративность подразумевает непрерывное взаимодействие с заказчиком.
Литература
Жизненный цикл программного продукта
 | |
Рис. 1. Жизненный цикл приложений и его реализация с помощью продуктов Borland |
Процесс создания программы включает в себя пять основных этапов (см. рис. 1).
Определение требований. Формальное задание действий, которые по замыслу заказчика должна выполнять система. Этот этап — основная точка связи между разработчиками и бизнес-пользователями будущей программы. Здесь формируется документ, который описывает формальные требования к системе и который должен стать эталоном для всего цикла разработки. Наличие такого документа помогает избежать ситуаций в ходе реализации проекта, порождающих лишние затраты и способных привести к созданию не того продукта, на который рассчитывал заказчик. Кроме того, формальное описание требований может использоваться в качестве шаблона для заключительных испытаний готовой системы.
Анализ и проектирование. Этап создания архитектуры системы, в ходе которого могут уточняться и изменяться начальные требования. Здесь важна связь этапов проектирования и этапа определения требований, выражаемая в постоянном обмене мнениями между бизнес-аналитиками и системными архитекторами. На данном этапе применяются средства, поддерживающие формальные методики проектирования программ.
Разработка. Собственно процесс написания программы. Связь этого этапа с этапом проектирования позволяет архитекторам разъяснять разработчикам концепцию архитектуры системы, а разработчикам — объяснять архитекторам принципы реализации архитектуры. Процесс разработки обеспечен наиболее разнообразной инструментальной поддержкой: среды программирования, средства быстрой разработки приложений, системы разработки на базе компонентов и т.д.
Тестирование и профилирование. Испытания разрабатываемой программы проводятся по мере готовности промежуточных версий. Взаимосвязь этого этапа с этапами проектирования и разработки позволяет подготавливать тесты на основе точных знаний о структуре и тонкостях реализации программы.
Развертывание. Выбор сервера приложений для развертывания прикладной системы и поддержки ее работы основывается на том, какую базовую платформу предпочитает заказчик. Для прикладных систем компонентной архитектуры возможна альтернатива — J2EE или .Net, но все большую актуальность приобретают средства интеграции этих платформ. По окончании развертывания системы может возникнуть необходимость в ее доработке, поэтому жизненный цикл замыкается на этап определения требований.
Цементирует все этапы в жизненном цикле процесс управления изменениями, который обеспечивает координацию действий между членами различных групп единой команды проекта. Здесь применяются системы управления конфигурацией программного обеспечения (software configuration management, SCM), в чьи функции входит централизованное хранение данных по проекту, контроль версий, управление внесением изменений в проект и т.д.
Управление проектами - статьи
Лирическое вступление
Управление требованиями начинается на самых ранних этапах работы над проектом и не заканчивается даже после его завершения (актом сдачи Заказчику), продолжаясь и далее — на этапе сопровождения.Еще когда проект существует лишь в виде идеи "а хорошо было бы сделать Нечто", уже подразумевается, что сие Нечто должно удовлетворять целому набору специфических — далеко не очевидных, однако крайне ответственных и от этого не менее расплывчатых — требований.
Далее это зародившееся Нечто развивается, разукрашивается для Заказчика-Инвестора, обрастая все новыми и более четко очерченными (опять-таки) требованиями — и вырастает в Ого-го-что, пока не получит "путевку в жизнь" в виде финансирования и четко определенных сроков.
Но очень скоро наше Ого-го-что на своем тернистом пути сталкивается с суровой реальностью, приносящей все новые и новые открытия из области требований: некорректность формулировки, принципиальная невыполнимость, противоречивость, непредвиденные дополнительные ограничения и т.д., и т.п.
Выскочившее из передряг с требованиями, наше детище имеет вид "изрядно общипанного, но непобежденного" Чего-то — готового и даже работающего.
Теперь ему приходится отдуваться за все неосторожные посулы и обещания в бытность свою Ого-го-чем. И работать, работать, работать — прежде чем заслужить название Кое-что стоящее и действительно полезное, удовлетворяющее набору соответствующих требований (ставших — как-то незаметно — общепринятыми и очевидными).
…И так до тех пор, пока какое-нибудь новое требование своими убийственными ограничениями не превратит наше детище в Ничто.
Но это — лирика эволюции требований. Пора приступить к физике их структуры и свойств.
Простейший случай диаграмм
Итак, в простейшем случае на диаграмме имеем область всех мыслимых и "немыслимых" требований — наш аналог универсального множества в математике.В рамках этого универсального множества всех требований выделяем две большие области: область компетенции и состоятельности Заказчика и область компетенции и состоятельности Разработчика.
Рис. 1. Простейший случай диаграммы (вертикальное измерение — уровень компетенции)
Таким образом, есть Заказчик и Разработчик, у каждого из них — своя область компетенции и состоятельности. Чем дальше в сторону информационных технологий смещаемся, тем шире область компетенции и состоятельности Разработчика. Соответственно, чем дальше в противоположную сторону (сторону технологий из предметной области) — тем меньше специалисты разработчика показывают сообразительности и готовых наработок.
С другой стороны, чем более мощные информационные технологии предлагаются Заказчику, тем меньше у него находится соответствующих задач и тем меньше сотрудников, способных разобраться как в самих задачах, так и в предлагаемых методах автоматизации их решения.
Диалог между представителями Заказчика и Разработчика становится конструктивным только тогда, когда области их компетентности и состоятельности начинают пересекаться.
Рис. 2. Возможность конструктивного диалога
Другими словами, информационное образование экспертов Заказчика должно позволять им формулировать свои требования пусть на ломаном, но все-таки "человеческом" языке, с одной стороны. А с другой — иметь элементарные представления об автоматизации для необходимой оценки и критики предлагаемых Разработчиком методов.
В свою очередь, опыт аналитиков Разработчика должен достичь такого уровня, чтобы они имели возможность разобраться в плохо структурированных лекциях экспертов Заказчика, состоящих на 80% из изложения частных случаев и исключений, каждый из которых просто "вопиит гласом велиим" о высочайшем уровне и исключительности данного эксперта в его области деятельности.
Но серьезное сотрудничество начинается только тогда, когда на пересечении этих двух областей, которое можно назвать областью взаимопонимания, накапливается некая "критическая масса" требований. Именно эти требования и являются основным материалом для переговоров и обоснования целесообразности самых ранних этапов разработки проекта.
Рис. 3. Возможность полноценного сотрудничества
Замечательно, что этими требованиями, как правило, не может пренебречь даже высшее руководство — как с одной, так и с другой стороны. Как правило, эти требования в обязательном порядке попадают в официальные документы и именно на них "высокие договаривающиеся стороны" своими широкими руководящими жестами ставят две черты: порог рациональной автоматизации и порог рациональной формализации предметной области Заказчика.
Рис. 4. "Высокие договаривающиеся стороны" принимают решение и проводят две красные черты
Эти две руководящие директивные черты отрезают две небольшие, но очень интересные области:
Примером требования из первой области может служить пожелание системного администратора Заказчика: получить систему автоматического архивирования базы данных корпорации на какое-нибудь нестандартное устройство со своим специфическим программным обеспечением по его управлению (какой-нибудь древний стример или новейший CD-RW, оборудованный механическим чейнджером).
Пример для второй области — система автоматического ценообразования для работы дизайнеров или парикмахеров, основанная на эстетических признаках.
Как всегда, сроки — сжаты, бюджет — ограничен. А потому от руководства дается однозначная установка: никаких новшеств, никаких изысканий, реализуем только четко очерченную область требований — просчитать сроки и бюджет.
Рис. 5. Результат встречи "в верхах"
Итак, сроки и бюджет скрупулезно подсчитаны, скорректированы и утверждены на высшем уровне.
Приступаем к воплощению… и с ужасом обнаруживаем: для реализации требования В необходима реализация требований, оставшихся за пределами внимания руководства,— А или C.
Рис. 6. Первые неожиданности: обнаружение новых, не учтенных в документах, но обязательных требований: B или C
В экстренном порядке собирается совещание, на котором руководство Разработчика (наконец-то) хоть немного прислушивается к мнению непосредственных исполнителей и на котором за бурными дебатами прячется основная цель: решить, кто же будет расплачиваться за промах. Руководство ли, вынужденное оплатить реализацию одного из требований A или C, — или же непосредственные исполнители, вынужденные реализовать все те же требования A или C, но (!) без дополнительных финансовых и человеческих ресурсов (в лучшем случае будет дана отсрочка по времени, потому что, как правило, все делается за счет "авралов" и "переработок").
Итак, приходим к пониманию, что существует еще одна область (рис. 7). Область требований, удовлетворение которых обязательно для реализации проекта в целом и, в частности, для реализации задокументированных и утвержденных требований. Ограничение ресурсов на реализацию этих требований или попытка обойтись вообще без их реализации ведет прямиком к завалу проекта.
Рис. 7. Область контекста реализации
Как только руководство принимает решение — требования из этой области не реализовывать — исполнители встают перед необходимостью делать это за свой счет. В результате наблюдается явление откачки средств и ресурсов из среды исполнителей. Это может выразиться в переработках, задействовании личных наработок или скрытого аутсорсинга исполнителей.
В любом случае результатом будут напряженные отношения между высшим руководством и исполнителями, грозящие перерасти сначала в скрытый, а потом и в явный конфликт. В случае если трудовые отношения построены по принципу "от конечного результата", пострадавшей стороной (то есть стороной, несущей потери) окажется непосредственный исполнитель.
В случае же отношений с повременной оплатой все финансовые потери ложатся на плечи руководства Разработчика.
И в том, и в другом случае Заказчику извне ситуация с развитием проекта кажется неопределенной, но, тем не менее, не предвещающей больших тревог — хотя именно в это время закладывается мина замедленного действия под успех проекта в частности и сотрудничество вообще. Тогда как в случае проявления инициативы со стороны Заказчика в сторону переговоров с целью увеличения сметы проекта катастрофические процессы могут быть погашены.
Проще говоря, рассчитывать на конструктивную деятельность со стороны своего руководства исполнителям Разработчика не приходится. Провести переговоры и добиться разумного и обоснованного увеличения бюджета — дело немыслимое, а проявление инициативы в этом направлении со стороны руководства Разработчика вообще принято считать дурным тоном.
С другой стороны, предложение со стороны Заказчика — увеличить бюджет проекта — помимо того что дает возможность решить проблему, еще и работает в сторону повышения имиджа не только Заказчика, но и Разработчика.
Однако на практике мы нередко наблюдаем весьма печальную и уродливую картину. Руководство Разработчика, зажатое реальными и весьма серьезными проблемами по реализации упущенных требований с одной стороны и мнимыми, но весьма болезненными проблемами по преодолению имиджевого стереотипа поведения с другой, все-таки вынуждено действовать. События развиваются по плану, который, может, и кажется счастливой находкой — но на деле лишь оттягивает момент кризиса, приводя к еще более тяжелой ситуации.
На переговорах Руководство разработчика подает сложившуюся ситуацию в очень выгодном (но только при поверхностном взгляде) свете: во время работы над проектом оказалось, что в общем ключе работ, не изменяя идеологии, возможно получить намного более привлекательный для Заказчика продукт, чем предполагалось изначально. Для этого необходимо всего лишь незначительно увеличить бюджет, но (!) прямо на текущей стадии разработки проекта.
Очевидными плодами такого подхода будут:
Есть простой признак, позволяющий Заказчику распознать такую ситуацию. Предложения об улучшениях поступают от Разработчика в конце временной цепочки его состояний: спад активности — неопределенность — бурная внутренняя деятельность — предложение чего-то лучшего. Вот уж действительно, лучшее — враг хорошего.
Напротив, если предложения об улучшении явились результатом ровной работы аналитиков Разработчика, да еще и при болезненном для Заказчика вскрытии его внутренних проблем,— тогда это может служить поводом к доверительной оценке таких предложений.
Существует еще одна область требований, реализация которых необходима для поддержания естественной и полноценной работы системы в соответствии со взаимно понятными и задокументированными требованиями (рис. 8). Изначально, требования из этой области не были замечены аналитиками Разработчика и считались в равной мере как очевидными, так и обязательными, с точки зрения экспертов Заказчика.
Если проигнорировать реализацию этих Требований, то Заказчик получит Систему, в которой функционирование автоматической части должно поддерживаться большим объемом окружающего ручного труда. Грубо говоря, придется заводить штат сотрудников, специалистов Предметной Области, работающих на Систему.
Рис. 8. Область контекста использования/функционирования
Авторам пришлось внедрять сторонний продукт, в котором был реализован автоматический выбор варианта делопроизводства в зависимости от текущего состояния счета клиента.
При этом велся строгий учет самих платежных документов и даты их прихода. Главным упущением аналитиков Разработчика оказалась реализация системы как автомата, реагирующего на наличие определенного платежного документа, а не на общий баланс по счету. Надо было видеть мучения делопроизводителей, вынужденных в угоду системе редактировать пересчитанные вручную суммы по соответствующим документам, а то и вводить дополнительные фиктивные документы…
Да простит меня читатель за случившееся отступление от темы статьи: формальная модель для классификации требований. Прорвались наболевшие наработки по родственному, но все-таки другому направлению — "Как гарантированно завалить проект" (конструктивное название должно быть таким "Риски ошибок в руководстве проектом: какими они бывают и как их избежать"). Возможно, это действительно станет названием следующей статьи, пока же приведенные язвительные примеры послужат лишь подтверждением тому, что за видимой сухостью и формальностью предлагаемой диаграммы кроются болезненные вопросы, сплошь и рядом возникающие в реальных, "живых" проектах. А для обсуждения подобных наболевших вопросов ой как нужна хорошая их визуализация!
Но вернемся к нашей диаграмме и выделенной там области… и зададимся вопросом: "А почему, собственно, область поддерживающих требований должна иметь именно такой вид?" Почему не так, как на рис. 9?
Другой интересный вопрос: а какой смысл в двух различных подобластях данной области? Чем, по сути, отличаются требования A и C? Но об этом чуть далее.
Рис. 9. Та же область контекста реализации — но при более глубоком рассмотрении
А по перовому вопросу очевидно, что диаграмма на приведенном рисунке является просто проявлением более глубокого подхода и дает более интересные результаты, обсуждение которых следовало бы вынести за пределы данной ознакомительной статьи. Мы же ограничимся упрощенным вариантом (рис. 7) и пойдем далее.
Итак, имеем две зеркальные — как по расположению на диаграмме, так и по своим проявлениям в процессе разработки,— области:
Рис. 10. Семантика горизонтального измерения — стандартизация или уникальность разработки
Теперь настало время "показать семантику второго измерения". Проще говоря, ответить на поставленный ранее вопрос: а чем, собственно, отличается левая подобласть от симметричной ей правой? Если для полноценной работы Заказчика в соответствии с требованием E необходима реализация одного из поддерживающих требований D или F (рис. 9), то чем они между собой отличаются и что общего у них с зеркальными им требованиями A и C?
Внимательный читатель уже заметил две стрелочки в верхней и нижней части рисунка, подписи которых имеют простой смысл: чем левее на рисунке расположена точка, обозначающая требования, тем больше это требование опирается на широко известные и общепринятые методы решения, стандартное и распространенное оборудование, соответствующее программное обеспечение и т.д. А чем правее — тем больше особенностей в методах решения (вплоть до ноу-хау и патентов), тем больше специального оборудования и\или специального ПО.
И не случайно стрелочка, указывающая стремление использовать стандартные методы, расположена в верхней части, соответствующей стремлениям Разработчика. Именно от него зачастую звучат размашистые предложения в стиле: да, для решения задач такой серьезной и представительной организации, как Заказчик, ну просто необходимы: СУБД — не меньше и не дешевле Oracle 9, CRM-системы — не ниже самого "Сибел-системз", а для решения задач коммуникации без приобретения спутника с антеннами вообще не обойтись.
В ответ на такие предложения со стороны Заказчика активно выдвигаются возражения, что подобная мощь (читай — такие большие расходы) ему абсолютно ни к чему, что вполне достаточно существующей базы и что сотрудники Заказчика успешно справляются со своими задачами чуть ли не с калькулятором и на бумаге …
Существует лишь несколько задач, реально нуждающихся в автоматизации. Именно они являются особенностью деятельности Заказчика, их решение должно дать Заказчику конкурентные преимущества и т.д.
Требования к проекту. Классификация — первый шаг к пониманию
Наталья Чернявская, Юрий Чернявский,При всем том, что сами понятия общеизвестны, их набор далеко не полон, а предложенная схема далека от совершенства,— статья имеет в себе элемент теоретической разработки. Тем не менее, в "реальных полевых условиях" этот материал может оказаться весьма полезным.
Относительно свободная форма изложения, принятая
Относительно свободная форма изложения, принятая авторами, допускает введение новых терминов и соответствующих им понятий, так сказать, по ходу изложения материала, не обременяя читателя отдельно вынесенными определениями или описаниями. Но это только там, где авторы надеются на опыт и интуицию читателя. Например, с самого начала используется термин требования к проекту (или, коротко, требования), обозначающий "то, что под этим понимают компетентные люди".Но есть термины, с которыми подобные вольности недопустимы. В статье вводится понятие область требований. В российских стандартах существует термин предметная область, а в украинских — предметна сфера, однако область требований обозначает нечто принципиально другое.
Почему именно "область", а не класс, к примеру, или группа? Тут две причины:
Области требований могут частично перекрываться, равно как одна из них может полностью содержать другую, отражая тем самым какое-либо из свойств принадлежащих им требований. Области требований очень похожи на диаграммы Венна из теории множеств. И чем в большей степени каждое отдельное требование будет обладать свойствами атомарности и отличимости (обязательные свойства для элемента множества), тем больше математических результатов из теории множеств можно будет применить.
Предлагаемый метод построения диаграмм областей является инструментом аналитика для процедуры начальной классификации требований. В процессе выделения существенных в данном конкретном случае областей, определения их взаимосвязей относительно включения-пересечения и распределения имеющихся требований по соответствующим областям аналитик приходит ко все более точному и глубокому пониманию сути самих требований.
По ходу изложения материала диаграмма будет эволюционировать от вспомогательного и совсем не обязательного инструмента визуализации простых и очевидных понятий до самостоятельного, мощного механизма, несущего глубокую семантику и, при необходимости, являющегося прочной базой для дальнейшей формализации и применения математических методов.
Управление проектами - статьи
Малыш, хочешь быть архитектором, когда вырастешь?
За последнее десять лет стало очень популярно словосочетание "архитектор программного обеспечения". Лично мне такой термин использовать очень трудно. Дело в том, что моя жена - инженер-строитель. А отношения между архитекторами и инженерами-строителями несколько.... натянуты. Инженеры полагают, что архитекторам ничего не стоит нарисовать целый ворох симпатичных рисуночков, а потом инженеры должны в поте лица вычислять, сможет такая симпатичная конструкция держаться вертикально, или сразу развалится. Именно поэтому я всегда старался избегать термина "архитектор". Сами судите, если моя собственная жена не станет относиться ко мне с профессиональным уважением, то чего мне ждать от остальных?В области программирования термин "архитектор" имеет множество значений. (Впрочем, в области программирования любой термин имеет множество значений.) Однако, как правило, здесь присутствует некий подтекст: "Я уже не просто какой-то там программист, я - архитектор", что можно понять как "Теперь я архитектор, и мне не пристало заниматься программированием". Вопрос только в том, действительно ли нужно отказываться от тривиального программирования, если собираешься стать техническим лидером.
Такой вопрос обычно вызывает бурю эмоций. Сколько раз я видел, как люди не на шутку сердились при мысли, что как архитекторы они уже не играют столь важной роли. "В ХР нет места опытным архитекторам!" - такой вопль я слышу довольно часто.
Все это напоминает положение дел с проектированием в целом. Я не думаю, что при использовании методологии ХР исчезает необходимость в умении хорошо проектировать. Более того, именно благодаря основоположникам ХР - Кенту Беку, Бобу Мартину, и конечно же, Уорду Каннингэму - я, в свое время, узнал, что такое настоящее проектирование. Однако сейчас многим может показаться, что эти люди перестали играть роль технических лидеров (в общепринятом понимании).
Для примера можно взять одного из технических лидеров компании "ThoughtWorks", по имени Дэйв Райс (Dave Rice).
Дэйв уже давно работает в компании и заслужил неофициальную мантию технического лидера в проекте, над которым работает около пятидесяти человек. Что же означает его лидерство? В первую очередь, то, что он проводит большую часть времени с программистами. Он помогает тем, кому это необходимо, и старается быть рядом на случай, если его помощь понадобится. Интересно отметить, где располагается его рабочее место. Как заслуженный сотрудник компании, он мог бы выбрать любое помещение по своему желанию. Какое-то время назад он сидел в офисе с Кара (Cara), который отвечал за выпуск системы. Тем не менее, вот уже несколько месяцев, как Дэйв перебрался в комнату к программистам (в том самом стиле "war room", который превозносит ХР). Для него очень важно находиться вместе с разработчиками, потому что в этом случае он знает, что происходит, и всегда может протянуть руку помощи тем, кто находится в затруднении.
Те, кто уже знаком с методологией ХР, поймут, что я описал имеющееся там понятие "тренера" ("coach"). Это еще один пример игры словами, которую так любят в ХР. Технический лидер команды называется "тренером". Подтекст понятен каждому: в ХР лидер учит программистов и помогает им принимать решения. Чтобы быть тренером, нужны не только отличные технические знания, но и хорошие качества человеческой натуры. Как заметил Джек Боллс (Jack Bolles) на конференции ХР 2000, для знатоков-одиночек скоро вообще не останется места. Ключ к успеху - обучение и взаимопомощь.
Позже, на обеде, который состоялся после конференции, Дэйв и я разговаривали с человеком, который критиковал ХР. Мы начали обсуждать все более подробно, и к удивлению, выяснили, насколько похожи наши подходы. Все мы предпочитали адаптивные, итеративные разработки. Все соглашались с важностью тестирования. Мы с Дэйвом никак не могли понять, откуда же тогда такое неприятие ХР? И тут наш оппонент сказал замечательную фразу: "последнее, что я допущу у себя на работе, это чтобы мои программисты делали рефакторинг и совали нос в проектирование".После этого все стало ясно. Итог нашим концептуальным разногласиям подвел Дэйв, когда сказал мне напоследок: "Интересно, зачем брать на работу программистов, если ты им не доверяешь?" В ХР самое ценное, что может сделать опытный разработчик - это передать свои знания младшим коллегам. Вместо архитектора, который один уполномочен принимать все важные решения, у вас есть тренер, который учит, как нужно принимать такие решения. Как говорит Уорд Каннингэм, таким образом опытный разработчик распространяет свои знания, и приносит проекту гораздо больше пользы, чем любой герой-одиночка.
Наращивание архитектуры
Что мы называем архитектурой программного продукта? С моей точки зрения, термин "архитектура" передает идею основных элементов системы, тех ее частей, которые трудно изменить. Они являются фундаментом, на котором можно построить все остальное.Какую роль играет архитектура в эволюционном проектировании? Критики ХР считают, что эта методология вообще не признает работы над архитектурой, что вся суть ХР - сразу садиться за написание кода, и уповать на то, что рефакторинг решит все проблемы с проектированием. Смешно сказать, но они правы, и, может быть, в этом заключается некоторая слабость ХР. Всем известно, что самые агрессивные приверженцы ХР - Кент Бек (Kent Beck), Рон Джеффриз (Ron Jeffries) и Боб Мартин (Bob Martin) - прикладывают очень много сил, чтобы вообще избежать любого предварительного проектирования архитектуры. Не добавляйте в систему базу данных, пока она вам действительно не понадобилась. Работайте поначалу с файлами, а база данных появится в следующей итерации, в результате рефакторинга.
Я заслужил репутацию трусливого ХР-шника, и в этом качестве вынужден не согласиться с подходом моих более смелых коллег. Мне кажется, что лучше начать с общего наброска архитектуры системы - подумать о том, как разделить приложение на уровни, как построить взаимодействие с базой данных (если она вам понадобится), какой подход применить к управлению веб-сервером.
По сути своей, многое из таких ранних архитектурных построений - просто паттерны, которые приходят к нам с опытом. С течением времени количество освоенных паттернов растет, и у вас должно появиться свое разумно обоснованное мнение на то, как их использовать. Однако ключевое отличие здесь будет в том, что ранние архитектурные решения вовсе не высечены в камне, и что в случае ошибки, команде не нужно будет собирать всю свою смелость, чтобы ее исправить. Кто-то рассказал мне, как в одном проекте, уже перед самой поставкой, решили, что им больше не нужен EJB. Ну, и убрали его из системы. Конечно, это потребовало порядочного рефакторинга, но использование практик ХР позволило не только сделать такую операцию осуществимой, это сделало ее целесообразной.
Интересно, а если перевернуть все наоборот? Если бы вы вначале решили не использовать EJB, не было бы сложнее в последний момент внести его в систему? Действительно ли не стоит начинать делать систему с EJB, пока вы окончательно не убедитесь, что без этого не обойтись? Этот вопрос затрагивает сразу несколько факторов. Разумеется, работать без такого сложного компонента легче и быстрее. Однако иногда легче что-то выбросить из системы, чем вставить.
Итак, я бы все же посоветовал начать работу с приблизительной оценки архитектуры системы. Если вы видите большое количество данных и множество различных пользователей, смело включайте в архитектуру базу данных. Если вы должны работать со сложной бизнес-логикой, используйте модель предметной области. Однако не забывайте об уважении к богам YAGNI, и в сомнительных случаях отдавайте предпочтение более простым решениям. Кроме того, всегда будьте готовы выбросить кусок архитектуры, если видите, что он не приносит ничего полезного.
Нарушает ли рефакторинг принцип YAGNI?
Эта тема сравнительно недавно всплыла в списке рассылки, посвященном XP, и коль скоро мы заговорили о роли проектирования, нам стоит ее обсудить.Дело в том, что процесс рефакторинга требует времени, но не добавляет новой функциональности. С другой стороны, принцип YAGNI гласит, что надо проектировать только для текущей функциональности, а не для того, что понадобится в будущем. Не сталкиваемся ли мы здесь с противоречием?
Принцип YAGNI состоит в том, чтобы не делать систему более сложной, чем того требует реализация текущих задач. Это является частью практики "Простой дизайн". Рефакторинг же необходим для поддержания системы в максимально простом состоянии. Его нужно проводить сразу же, как только вы обнаружите, что можете что-либо упростить.
Простой дизайн одновременно задействует практики ХР и сам по себе является основополагающей практикой. Только при условии тестирования, непрерывной интеграции и рефакторинга, можно говорить об эффективном использовании простого дизайна. Но в то же время, простой дизайн абсолютно необходим для сглаживания кривой стоимости изменений. Любая излишне сложная конструкция затруднит внесение изменений в систему по всем направлениям, за исключением того из них, ради которого эта сложность в нее вносилась. Однако редко удается предсказать такое направление, поэтому лучше будет стремиться к простым решениям. И в тоже время, мало кому удается сделать все максимально просто с первого раза, так что вам придется заниматься рефакторингом, чтобы приблизиться к цели.
О метафоре
Ну вот, теперь я могу признаться публично - я до сих пор не могу понять, что же это за штука такая, эта метафора. Я видел, как она работает (в проекте С3 она сработала просто великолепно), однако это вовсе не означает, что я понимаю, как это сделать, не говоря уже о том, чтобы объяснять это другим.Метафора - одна из практик ХР. Она строится на системе имен, подходе, разработанном Уордом Каннингэмом (Ward Cunningham). Суть этого подхода в том, что вы определяете некий набор имен, которые служат словарем для описания предметной области проекта. В дальнейшем система имен из этого набора служит для именования классов и методов системы.
Что касается меня, то я строю систему имен с помощью концептуальной модели предметной области. Я делаю это вместе со специалистами в этой области, и использую UML (а раньше - его предшественников). Весь мой опыт показывает, что такая работа должна вестись очень осторожно. Вы должны использовать минимальный набор понятий и не допускать, чтобы в их числе в модель прокрались сложные технические термины. Если вам удалось это сделать, то у вас в руках находится основа для построения словаря предметной области, который будет понятен как специалистам, так и разработчикам системы, и с помощью которого те и другие будут общаться друг с другом. Конечно, эта модель не совсем совпадает с классами, которые появятся при проектировании, однако ее вполне достаточно для создания терминологической базы.
По правде говоря, я не вижу причин, по которым такой словарь нельзя было бы сделать метафорическим, как в проекте C3, где построение платежной ведомости представили в виде фабричной линии сборки. С другой стороны, я не понимаю, почему нельзя определять систему имен, исходя из словаря предметной области, и уж тем более я не собираюсь отказываться от своего способа определять систему имен, который меня вполне устраивает.
Часто критики ХР указывают на то, что для работы над проектом необходима хотя бы приблизительная архитектура системы. На что приверженцы этой методологии отвечают: "Так это и есть метафора". На самом деле, я до сих пор не слышал, чтобы кто-нибудь внятно объяснил, что же это такое, метафора. Мне кажется, что такой пробел все же нужно как-то ликвидировать.
Обратимость решений
На конференции XP 2002 Энрико Цинанотто (Enrico Zaninotto) прочитал интереснейший доклад, в котором указал на связь между гибкими методологиями и "облегченным" процессом производства в промышленности (lean manufacturing). С его точки зрения, одним из основных положений обоих методов является уменьшение сложности процесса путем повышения его обратимости.Вообще, необратимость принимаемых решений вполне можно считать основной причиной сложности процесса разработки ПО. Судите сами: если однажды принятое решение можно легко изменить, то его правильность становится менее важной. А это делает жизнь много проще. При эволюционном стиле проектирования дизайнеры должны стараться принимать легко обратимые решения. И вместо того, чтобы мучительно отыскивать единственно правильное решение, нужно или постараться отложить его принятие на потом (когда у вас будет больше необходимой информации), или же принять такое решение, которое в будущем можно изменить без особых усилий.
Стремление к выработке обратимых решений является основной причиной, по которой гибкие методологии настоятельно рекомендуют держать весь код в системах управления исходным кодом (source code control systems). Разумеется, это не гарантирует обратимость решений, особенно если они долгосрочные. Однако это придает команде некоторую уверенность в такой возможности, даже если она используется очень редко.
Кроме того, обратимый дизайн подразумевает наличие процесса, при котором все ошибки быстро становятся очевидными. С этой точки зрения очень хорош итеративный подход, когда заказчик воочию наблюдает развитие разрабатываемой системы. И если вдруг окажется, что в спецификации вкралась ошибка, поправить ее можно будет сразу же, еще до того, как цена исправлений станет слишком высока.
Тот же подход очень полезен и в проектировании. Проектные решения должны выстраиваться так, чтобы проблемные моменты тестировались и оценивались как можно раньше. Кроме того, очень полезно проводить эксперименты, чтобы понять, насколько сложно будет внести изменения в будущем (даже если вы не собираетесь ничего менять сейчас). Наилучший способ - поэкспериментировать на прототипе, сделанном на каком-то ответвлении системы. Такой метод раннего прототипирования для оценки сложности будущих изменений в системе уже был успешно опробован несколькими командами.
Основополагающие практики ХР
В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. А как мы уже выяснили, использование эволюционного проектирования не может привести ни к чему хорошему из-за обилия сиюминутных проектировочных решений и энтропии программного продукта.В основе этого утверждения лежит кривая стоимости изменений в программном продукте. Согласно этой кривой, по мере развития проекта стоимость внесения изменений экспоненциально возрастает. Как правило, в ней используются понятия "фазы развития проекта" (как говорится, "изменение, которое на стадии анализа стоит 1 доллар, после поставки системы будет стоить многие тысячи"). В этом есть некая доля иронии, поскольку в большинстве проектов процесс разработки вообще не определен, и там просто нет стадии анализа, а экспоненциальная зависимость остается в силе. Получается, что если экспоненциальная кривая верна, то эволюционное проектирование вообще нельзя использовать в работе. Отсюда же следует, что нельзя делать ошибки в предварительном проектировании - затраты на их исправление будут определяться все той же зависимостью.
В основе XP лежит предположение, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. Именно это является основным предметом споров вокруг XP. Многие начинают критиковать использование, не разобравшись в том, как его нужно достигать с помощью осуществления. Зачастую тому виной собственный опыт критикующего, который упустил в разработках те практики, которые позволяют осуществлять другие. В результате, раз обжегшись, такие люди при упоминании об ХР и на воду дуют.
У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Непрерывная интеграция необходима для синхронной работы всех разработчиков, так чтобы любой человек мог вносить в систему свои изменения и не беспокоиться об интеграции с остальными членами команды. Взятые вместе, эти две практики могут оказывать существенное влияние на кривую стоимости изменений в программном продукте. Я получил еще одно подтверждение этому в компании "ThoughtWorks". Даже применение всего двух практик, тестирования и непрерывной интеграции, существенно сказалось на результатах. Можно даже усомниться, действительно ли нужно (как это принято считать в ХР) следовать всем практикам, чтобы получить заметный результат.
Подобный эффект имеет и рефакторинг. Те, кто делают рефакторинг в той строгой манере, что принята в ХР, отмечают значительное повышение его эффективности по сравнению с более бессистемной реструктуризацией. Именно это я и ощутил, когда Кент наконец-то научил меня, как правильно делать рефакторинг. В конце концов, это так меня впечатлило, что я даже написал об этом целую книгу.
Джим Хайсмит (Jim Highsmith) в своем великолепном изложении методологии XP
использует аналогию с обычными весами. На одной чаше лежит предварительное проектирование, на другой - рефакторинг. В более традиционных подходах к разработке ПО перевешивает предварительное проектирование, так как предполагается, что передумать вы не можете. Если же стоимость изменений снизится, то часть проектирования можно делать и на более поздних стадиях работы, в виде рефакторинга. Это вовсе не означает отказа от предварительного проектирования. Однако теперь можно говорить о существовании баланса между двумя подходами к проектированию, из которых можно выбрать наиболее подходящий. Что касается меня, то иногда мне кажется, что до знакомства с рефакторингом я работал, как однорукий калека.
Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. Впрочем, мы еще не выяснили, где же у этих весов точка равновесия. Лично я уверен, что не смотря на поверхностное впечатление, методология ХР - это не просто тестирование, кодирование и рефакторинг. В ней найдется место и для предварительного проектирования. Частично оно производится еще до написания первой строчки кода, но большая его часть приходится на то время, которое предшествует реализации конкретной задачи в течение итерации. Впрочем, такая ситуация представляет собой новое соотношение сил между предварительным проектированием и рефакторингом.
Паттерны и ХР
Пример JUnit постоянно наводит меня на размышление о паттернах. Вообще, отношение, существующее между ХР и паттернами, довольно интересно и часто обсуждается. Так, Джошуа Кериевски считает, что ХР отводит паттернам недопустимо маленькую роль. Его аргументация настолько красноречива, что я воздержусь от пересказа. Однако хочу заметить: многим кажется, что использование паттернов противоречит принципам ХР.Суть в том, что часто паттерны используются чересчур активно. Известна история о программисте, который, прочитав в первый раз книгу Банды Четырех
(издана на русском языке в издательстве "Питер" под названием "Паттерны проектирования" - прим. переводчиков), ухитрился использовать 16 паттернов в 32 строчках кода. Помню замечательный вечер, подогретый всего-навсего одним стаканчиком солода, когда мы с Кентом набрасывали статью под названием "Не паттерны проектирования: 23 дешевых трюка", где рассказали о таких вещах, как использование оператора "if" вместо паттерна "стратегия". В каждой шутке есть доля правды. Паттерны нередко используются там, где без них вполне можно было бы обойтись, однако это не делает хуже саму идею. Весь вопрос в том, как вы их используете.
Согласно одной из существующих теорий, стремясь к простому дизайну, вы придете именно к паттернам. Для некоторых видов рефакторинга это происходит совершенно явно, однако и без рефакторинга, принимая простые проектные решения, вы начинаете использовать паттерны, даже если до этого вы ничего о них не знали. Может быть, это и так, но так уж ли хорош этот путь? Конечно же, лучше заранее представлять себе, с чем вы столкнетесь, и иметь при себе книгу, чтобы не изобретать все самому. Каждый раз, когда я чувствую, что на подходе ситуация, когда можно использовать паттерн, я достаю с полки книгу Банды Четырех. Для меня само словосочетание "эффективный дизайн" свидетельствует о том, что использование паттерна оправдано. В конце концов, назначение паттернов состоит как раз в облегчении создания простого дизайна системы.
Точно так же и Джошуа предлагает уделять больше внимания вопросу, как можно упростить постепенный переход к использованию паттернов. С этой точки зрения, паттерны в ХР используются несколько непривычным образом, однако это совершенно не означает, что при этом их значение как-то принижается.
Читая некоторые списки рассылки, я прихожу к выводу, что многие вообще видят в ХР некое отрицание паттернов. И это притом, что большинство создателей этой методологии были, в свое время, в числе лидеров движения за использование паттернов! Не знаю, как для всех остальных, но для меня паттерны до сих пор совершенно необходимы. Методология ХР может служить процессом разработки, но паттерны - это основа искусства проектирования, искусства, без которого не обойтись, каким бы процессом вы не пользовались. Опять-таки, различные процессы могут использовать паттерны по-разному. Так, в ХР считается, что не нужно использовать паттерн до тех пор, пока в нем действительно не окажется необходимости, а также что нужно приходить к использованию паттерна постепенно, путем упрощения реализации. Тем не менее, знание паттернов было и остается совершенно необходимым.
Мои советы тем, кто работает по методологии ХР и использует паттерны:
Мне кажется, что в методологию ХР стоило бы включить отдельным пунктом изучение паттернов. Боюсь, что мне не под силу придумать, как это можно внести в практики ХР, но у Кента это наверняка получится.
Преимущества простого дизайна
В ХР очень популярны два лозунга: "Do the Simplest Thing that Could Possibly Work" ("Ищите самое простое решение, которое может сработать") и YAGNI ("You Aren't Going to Need It" - "Это вам не понадобится"). Оба они олицетворяют собой одну из практик ХР под названием Простой дизайн.По принципу YAGNI, вы не должны заниматься написанием кода сегодня, если он понадобится для того свойства программы, которое вы будете реализовывать только завтра. На первый взгляд в этом нет ничего сложного. Сложности начинаются, когда речь заходит о таких вещах, как программные каркасы для создания приложений, компоненты для повторного использования и гибкий дизайн. Надо сказать, что спроектировать их довольно сложно. Вы заранее добавляете к общей стоимости работ стоимость и такого проектирования и рассчитываете впоследствии вернуть эти деньги. При этом наличие заблаговременно встроенной в систему гибкости считается признаком хорошего проектирования.
Тем не менее, ХР не советует заниматься созданием гибких компонентов и каркасов до того, как понадобится именно эта функциональность. Лучше, если эти структуры будут наращиваться по мере необходимости. Если сегодня мне нужен класс Money, который обрабатывает сложение, а не умножение, то сегодня я буду встраивать в этот класс только сложение. Даже если я абсолютно уверен, что умножение понадобится мне уже в следующей итерации, и я знаю как очень просто и быстро это сделать сейчас, все равно я должен оставить это на следующую итерацию - когда в нем появится реальная необходимость.
Такое поведение оправдано с экономической точки зрения. Занимаясь работой, которая понадобится только завтра, я тем самым расходую силы и время, предназначенные для задач, которые должны были быть сделаны сегодня. План выпуска программы четко указывает, над чем мне нужно работать в настоящий момент. Если я отклоняюсь от него, чтобы поработать над тем, что понадобится в будущем, я нарушаю свое соглашение с заказчиком.
Кроме того, появляется риск не успеть сделать все, записанное в требованиях для текущей итерации. И даже в том случае, если такой опасности нет, и у вас появилось свободное время, то решать чем вам заняться - прерогатива заказчика, который может попросить заняться вовсе не умножением.
Таким образом, возможные препятствия экономического характера осложняются еще и тем, что мы можем ошибаться. Даже если мы абсолютно уверены в том, как работает эта функция, мы все равно можем ошибиться, особенно если у нас еще нет подробных требований заказчика. А чем раньше мы используем в работе над проектом ошибочные решения, тем хуже. Приверженцы методологии ХР считают, что в такой ситуации гораздо легче принять неправильное решение (и я полностью с ними согласен).
Другая причина, по которой простой дизайн лучше сложного, это отказ от принципа "блуждающего огонька". Сложную конструкцию гораздо труднее понять, чем простую. Именно поэтому любая модификация системы делает ее все более сложной. Это, опять-таки, ведет к увеличению стоимость работ в период между тем временем, когда дизайн системы стал более сложным, и временем, когда это действительно стало необходимо.
Такой стиль работы многим кажется абсурдным, и надо сказать, что они правы. Правы при одном условии - абсурд получится, если эту практику начать применять в обычном процессе разработки, а все остальные практики ХР игнорировать. Если же изменить существующий баланс между эволюционным и предварительным проектированием, то YAGNI становится очень полезным принципом (тогда и только тогда).
Подведем итог. Вам не нужно расходовать силы на то, чтобы внести в систему новую функциональность, если она не понадобится до следующей итерации. Даже если это практически ничего не стоит, вам не нужно это делать, так как это увеличит общую стоимость модификации. Однако для того, чтобы осознанно применять такой принцип на деле, вам нужно использовать ХР или другую подобную методологию, которая снижает стоимость изменений.
Проектирование это или нет?
Одна из сложностей эволюционного подхода к проектированию состоит в том, что иногда бывает очень сложно сказать, происходит ли проектирование вообще. Смешивая написание кода и проектирование, нельзя забывать о том, что можно писать код и без всякого дизайна - и тогда эволюционное проектирование не работает.Если вы сами находитесь в команде разработчиков, то сразу почувствуете, на каком уровне находится проектирование - достаточно посмотреть на код. Если он становится с каждым днем все сложнее, если с ним все тяжелее работать, можно говорить об отсутствии или недостаточном качестве дизайна системы. Однако, к сожалению, все это субъективные ощущения. У нас нет никаких официальных метрик, с помощью которых можно было бы определить качество дизайна.
Но если качество дизайна трудно определить даже техническим специалистам, то что же говорить о нетехнической части команды! Если вы, к примеру, менеджер или заказчик, как вам узнать, насколько хорошо была спроектирована система? А знать это вам нужно, потому что плохо спроектированную систему будет гораздо сложнее и дороже изменять в будущем. Однозначного ответа на этот вопрос нет, но что-то посоветовать все-таки можно:
Проектирование предварительное и проектирование эволюционное
В этой статье я опишу два стиля проектирования, принятых в разработке программного обеспечения. Наверное, наиболее привычным является эволюционное проектирование. Определение "эволюционный" указывает на то, что во время реализации системы ее дизайн растет вместе с ней. Проектирование, в этом случае, является частью процесса программирования, поэтому в ходе развития системы дизайн меняется.В большинстве случаев, эволюционное проектирование - это нечто ужасное. В конце концов, все равно вместо дизайна системы вы получаете просто набор из специфических решений, каждое из которых затрудняет дальнейшие изменения в программном коде. Часто это вообще нельзя считать дизайном (и, уж конечно, такой дизайн никак нельзя назвать хорошим). Как говорит Кент, дизайн существует для того, чтобы дать возможность оперативно вносить в систему любые изменения. Если дизайн плох, то такая возможность исчезает. В результате вы будете иметь дело с энтропией программного продукта, и со временем и без того плохой дизайн системы станет еще хуже. Теперь вам будет не только сложнее вносить в систему изменения, но и отыскивать и исправлять ошибки, которые начинают множиться с катастрофической быстротой. Все это - кошмар разработок в стиле "code and fix", когда с течением времени исправление ошибок обходится все дороже и дороже.
Предварительное проектирование - полная противоположность эволюционному. Оно построено на идеях, заимствованных из другой области инженерной деятельности. Если вам надо построить собачью будку, то вы сами в состоянии сколотить несколько досок, чтобы получить удовлетворительное подобие желаемого. Если же вы решите построить небоскреб, то прежний способ не подойдет - небоскреб рухнет, прежде чем вы соорудите его хотя бы наполовину. Чтобы этого не случилось, вам нужно начинать с чертежей, которые разрабатывают в инжиниринговых компаниях (вроде той, в которой работает моя жена). Проектируя, она вычисляет все необходимые данные, иногда путем математического анализа, но чаще всего - с помощью "Строительных норм и правил".
Эти "Нормы" представляют собой правила, по которым и создаются проектные конструкции. Все они основаны на опыте реальных работающих решений (ну, и небольшом количестве математики). После того, как работы по проектированию закончены, инжиниринговая компания передает проектные чертежи другой компании, которая занимается строительством.
Приблизительно так же обстоит дело и с предварительным проектированием при разработке ПО. Проектировщики заранее продумывают все основные вопросы. При этом они не пишут программный код, поскольку не создают программный продукт, а только разрабатывают его дизайн. В своей работе они могут использовать такие техники, как UML, что позволяет им абстрагироваться от некоторых подробностей разработок, относящихся непосредственно к программированию. Как только проектный план готов, его можно передавать в другой отдел (или даже в другую компанию), где будут вестись работы по непосредственному созданию системы. Поскольку проектировщики работают на некотором уровне абстракции, им удается избежать принятия ряда тактических решений, ведущих к энтропии программного продукта. Программисты же могут руководствоваться проектным планом и (если они ему следуют) создавать качественно выстроенную систему.
Такой подход к разработке ПО не нов - им активно пользуется множество людей, начиная с 70 годов. По многим показателям он гораздо лучше, чем эволюционное проектирование в стиле "code and fix", однако и у него есть существенные недостатки. Один из главных недостатков заключается в том, что невозможно заранее продумать все вопросы, с которыми придется столкнуться во время кодирования системы. Таким образом, в ходе работ непременно возникнет ситуация, когда у программистов появятся вопросы относительно спроектированного дизайна. А что, если проектировщики, закончив свою часть работы, уже переключились на другой проект? Тогда программисты начинают самостоятельно решать сложившуюся проблему, отступая от уже принятых проектных решений, и внося при этом в программный продукт долю энтропии.
И даже если проектировщик еще работает над проектом и может помочь, все равно ему потребуется довольно много времени, чтобы выяснить ситуацию, внести изменения в диаграммы и уже затем менять код. А при разработке, как правило, вопрос времени всегда стоит остро. Отсюда энтропия (опять-таки).
Кроме того, существует еще и проблема культур. Проектировщиками становятся благодаря высокому мастерству и большому опыту в программировании. Однако, став проектировщиком, программист настолько поглощается новой работой, что просто не имеет физической возможности заниматься написанием программного кода. При этом инструментарий и материалы программных разработок постоянно меняются. А когда вы перестаете сами писать код, вы не только теряете возможность отслеживать новшества в этой области. Вы теряете уважение тех, кто продолжает заниматься написанием программного кода.
Противостояние между разработчиками и проектировщиками мы находим и в области строительства, однако там оно выражено не так ярко, как в сфере программирования. И это не случайно. В области строительства разница в навыках тех, кто проектирует и тех, кто строит, достаточно очевидна. В программировании это не так. Любой программист, работающий с дизайном высокого уровня, должен быть очень хорошим специалистом (достаточно хорошим для того, чтобы задать проектировщику нужные вопросы относительно проектных решений, которые тот предлагает, особенно в тех случаях, когда проектировщик не так хорошо осведомлен об особенностях платформы, для которой ведется разработка системы).
Однако такие проблемы все же можно как-то урегулировать. Может быть, можно что-то сделать с напряженностью в отношениях между людьми. Может быть, можно найти таких проектировщиков, которые могли бы разбираться в большинстве вопросов, и такой дисциплинированный процесс разработки, который позволял бы вносить изменения в диаграммы. Однако остается еще одна проблема: изменяющиеся требования. Именно изменяющиеся требования являются проблемой номер один и главной головной болью во всех проектах, над которыми я работал.
Бороться с изменяющимися требованиями можно по-разному. Один из возможных путей - делать дизайн достаточно гибким, чтобы при изменениях в требованиях его можно было легко менять. Однако для этого требуется заранее знать, какого типа изменения следует ожидать. Да, при проектировании системы можно попытаться угадать те области, в которых наиболее вероятны изменения, и учесть их в дизайне. В этом случае вы, действительно, облегчите себе работу с ожидаемыми изменениями в требованиях, но ничуть не облегчите (а возможно, только ухудшите) ситуацию с изменениями неожиданными. Кроме того, чтобы заранее определить те области, в которых наиболее вероятны изменения, вы должны прекрасно понимать требования, что по моим наблюдениям, очень непросто.
Впрочем, не все проблемы с изменениями в требованиях возникают из-за их непонимания. Множество людей напряженно работает над разработкой технических требований к системе в надежде, что это убережет их от дальнейших поправок при проектировании. Но и так вы далеко не всегда сможете решить проблему. Многие изменения в требованиях диктуются изменениями в экономике и том виде бизнеса, для которого предназначается система. Такие изменения предугадать невозможно, сколько бы вы не сидели над разработкой требований.
После всего этого можно подумать, что предварительное проектирование вообще невозможно. Но это не так. Да, есть серьезные трудности. Однако я вовсе не склонен полагать, что предварительное проектирование хуже эволюционного в его обычной манере "code and fix". Сам я предпочитаю предварительное проектирование, но тем не менее, прекрасно представляю себе все сложности, которые с ним связаны и пытаюсь найти новые пути их преодоления.
Проектирования больше нет?
Мартин Фаулер, Chief Scientist, ThoughtWorksПеревод: , http://maxkir.com/
Original text at martinfowler.com
Тем, кто успел кратко познакомиться с принципами Extreme Programming (ХР), порой кажется, что в этой методологии нет места процессу проектирования программных продуктов. При этом высмеиваются не только "Большое и Подробное Предварительное Проектирование", но и такие техники как UML и гибкие каркасы приложений. Даже значение паттернов либо принижается, либо напрочь отрицается. На самом же деле, в ХР много проектирования, но подается оно по-другому, нежели в обычных устоявшихся процессах разработки ПО. Методология XP оживила эволюционное проектирование новыми техниками, благодаря которым его теперь можно считать вполне жизнеспособной стратегией. Кроме того, в ХР перед проектировщиком ставятся новые трудные задачи, требующие немалого мастерства. Во-первых, это необходимость проектировать максимально простым образом, во-вторых, рефакторинг, и наконец, использование паттернов в эволюционном стиле.
(Эта статья была написана для моего доклада на конференции XP 2000 и опубликована в ее материалах.)
Последнее обновление текста - май 2004 г.
Методология Extreme Programming (XP) бросила вызов многим устоявшимся представлениям о разработке программного обеспечения. Пожалуй, наиболее противоречивой идеей является отказ от предварительного проектирования в пользу более эволюционного подхода. Для тех, кто всячески чернит ХР, это возврат к разработкам типа "code and fix" ("пишем и правим"). Для приверженцев новой методологии, это отказ от техник проектирования (например, UML), их принципов и паттернов. Незачем беспокоиться о проектировании, считают они. Достаточно внимательно "вслушиваться" в свой код, и проектирование образуется само собой.
Что касается меня, то я нахожусь непосредственно в эпицентре этих споров. Большая часть моей карьеры была посвящена графическим языкам моделирования - UML (Унифицированный язык моделирования) и его предшественникам, а также паттернам. Более того, я писал книги про UML и про паттерны. Раз я теперь принимаю ХР, не значит ли это, что я отрекаюсь от всего, что писал до сих пор?
Не буду испытывать ваше терпение, и заставлять вас ждать, затаив дыхание, ответа на этот драматический вопрос. Краткий ответ - нет. Подробный ответ содержится в оставшейся части этой статьи.
"Простой дизайн" - что же это за зверь такой?
Итак, мы хотим, чтобы наш программный код был максимально прост. С этим никто не спорит. В конце концов, кому нужно, чтобы код был сложный и запутанный? Осталось только понять, что мы разумеем под словом "простой".В книге Extreme Programming Explained Кент приводит четыре критерия простой системы. Вот они в порядке убывания важности:
Успешное тестирование системы - довольно простой критерий. Отсутствие дублирования кода тоже вполне четкое требование, хотя большинство разработчиков нужно учить, как этого достичь. Самое сложное скрывается в словах "раскрывает изначальные замыслы". Действительно, что же это значит?
Основное достоинство программного кода, в данном случае - его ясность. ХР всячески подчеркивает, что хороший код - это код, который можно легко прочесть. Скажите ХР-шнику, что он пишет "заумный код", и будьте уверены, что обругали этого человека. Но понимание замыслов программиста, написавшего код, зависит также и от опыта и ума того, кто этот код пытается прочесть.
В своем докладе на конференции XP 2000, Джош Кериевски (Josh Kerievsky) приводит хороший пример на данную тему. Он подвергает анализу, возможно, самый открытый из всех кодов ХР - JUnit. JUnit использует декораторы (паттерн Decorator), для того, чтобы дополнить тестовые сценарии дополнительным поведением, таким как синхронизация доступа и установка начальных предусловий для групп тестов. Так как подобное поведение реализуется в отдельных классах-декораторах, код тестов становится проще, чем если бы эта функциональность присутствовала в них самих.
Однако в данном случае нужно задать себе вопрос: а понятнее ли будет код, полученный в результате этих операций? С моей точки зрения да, но я-то знаком с паттерном Decorator. Для тех, кто не имеет о нем ясного представления, этот код может показаться довольно сложным.
Аналогично этому, в JUnit используются методы-вставки (pluggable methods), которые, по моим наблюдениям, большинство программистов расценивают как что угодно, но только не как простое и понятное решение. Получается, что структура JUnit является простой для опытных проектировщиков, но сложной для менее опытных программистов?
Я думаю, что одним из самых очевидных и полезных советов, которые только можно дать, это избегать повторов в коде, как провозглашается в ХР ("Once and Only Once") и в книге
Pragmatic Programmer's
(принцип DRY - Don't Repeat Yourself). Следуйте этому принципу, вы уйдете далеко вперед. Но это далеко не все, что необходимо для простого дизайна. А создать простой дизайн - это весьма сложная задача.
Недавно мне пришлось работать над системой с весьма заумным дизайном. После проведенного мной рефакторинга дизайн лишился некоторой гибкости (за ненадобностью). Однако, как заметил один из разработчиков, "гораздо проще делать рефакторинг системы со сложным дизайном, чем рефакторинг системы, у которой дизайна вообще нет". Лучше всего быть немного проще, чем требуется, но нет ничего ужасного в том, чтобы быть немного сложнее.
А самый лучший совет, который я слышал по этому поводу, исходил из уст "Дядюшки Боба" (Роберта Мартина). Заключается он в следующем: не стоит сушить голову над вопросом, как сделать дизайн максимально простым. В конце концов, позже вы сможете (и должны, и будете) заняться рефакторингом. В конце работы над проектом желание делать рефакторинг гораздо важнее, чем точное понимание того, какое решение является самым простым.
Так что же, проектирования больше нет?
Ни в коем случае. Однако изменилась сама суть проектирования. Проектирование в ХР требует от человека следующих качеств:Такой вот впечатляющий список требований. Впрочем, стать хорошим проектировщиком всегда было непросто. В данном случае, ХР не облегчает жизнь, по крайней мере, не мне. Однако я полагаю, что методология ХР позволяет нам по-новому взглянуть на проблему эффективности проектирования, потому что именно она снова сделала эволюционное проектирование разумной стратегией программных разработок. А я большой фанат эволюции. Если бы не она, на каком дереве я бы сейчас сидел?
UML и XP
Мне задают довольно много вопросов относительно моей приверженности методологии ХР, причем чаще всего люди интересуются - как я могу сочетать ее с верностью UML. Разве они не исключают друг друга?Да, в ХР и UML есть несколько взаимоисключающих аспектов. Так, в ХР существенно снижается значение диаграмм. Не смотря на то, что официальная позиция ХР по этому поводу гласит: "используйте их, если это помогает вам в работе", но существует и неофициальный подтекст: "настоящий ХР-шник не рисует диаграмм". Это подчеркивается еще и тем фактом, что таким людям, как Кент, неудобно использовать диаграммы. Я, например, никогда не видел, чтобы Кент по своей воле рисовал диаграмму программного продукта, неважно даже на языке UML, или каком другом.
Я думаю, что такая ситуация возникает по другим причинам. Во-первых, одни люди считают, что диаграммы полезны, а другие придерживаются противоположного мнения. Фокус в том, что те, которые так считают, полагают, что те, которые так не считают, должны изменить свое мнение, и наоборот. Вместо этого, мы должны просто принять тот факт, что одни люди будут использовать в работе диаграммы, а другие не будут.
Во-вторых, диаграммы программных продуктов обычно ассоциируются с тяжелыми процессами разработки. В таких процессах большая часть времени уходит на построение диаграмм, что не очень помогает в работе, а иногда даже вредит. Именно поэтому я считаю, что людей нужно учить, как использовать диаграммы правильно и избегать различных ловушек, а не просто говорить "рисуй диаграмму, если тебе без нее совсем не обойтись, бедняга", как это обычно делают ярые ХР-шники.
Вот мои советы тем, кто хочет правильно использовать диаграммы:
Во-первых, пока рисуете диаграмму, не забывайте, для чего вы это делаете. Основное ее достоинство - коммуникация с людьми. Чтобы коммуникация была эффективной, нужно отображать на диаграмме только важные аспекты, не обращая внимания на все второстепенные. Такая избирательность - основа правильной работы с UML.
Не надо отображать на диаграмме каждый класс - только самые важные. У классов не нужно задавать каждый атрибут или операцию - только самые важные. Не надо рисовать диаграммы последовательности для всех вариантов использования и сценариев - ну, и так далее. Самая распространенная проблема с использованием диаграмм это то, что их пытаются сделать максимально всеобъемлющими. Однако самый лучший источник всеобъемлющей информации - это программный код, так как именно его легче всего синхронизировать с кодом. Для диаграммы же всеобъемлимость - враг удобопонятности.
Чаще всего диаграммы используются для того, чтобы проанализировать проектные решения еще до написания кода. Нередко при этом возникает чувство, что в ХР этого делать нельзя. Это совсем не так. Многие полагают, что перед разработкой сложной задачи стоит ненадолго собраться всей командой для ее предварительного проектирования. Тем не менее, когда проводите такие собрания, не забывайте, что:
Последний пункт стоит раскрыть подробнее. Когда вы занимаетесь предварительным проектированием, вы неизбежно обнаруживаете, что некоторые ваши решения неправильны. Причем обнаруживается это уже при кодировании. Разумеется, это не проблема, если вы после этого вносите соответствующие изменения. Проблемы начинаются тогда, когда вы полагаете, что с проектированием покончено, и не учитываете полученные сведения, сохраняя неверный дизайн.
Изменения в дизайне вовсе необязательно подразумевает изменения в диаграммах. Абсолютно разумным будет просто-напросто выбросить диаграмму, после того, как она помогла вам найти нужное решение. Нарисовав диаграмму, вы решили стоявшую перед вами проблему, и этого совершенно достаточно. Диаграмма и не должна существовать как некий постоянный артефакт. Надо сказать, что лучшие UML-диаграммы такими артефактами как раз не являются.
Многие ХР-шники используют CRC-карточки. Это не противоречит UML. Лично я все время задействую некую смесь из CRC и UML, и вообще, пользуюсь любыми техниками, которые облегчают мне выполнение текущей задачи.
Кроме того, UML-диаграммы используются в качестве документации по проекту. Как правило, в своей обычной форме это модель, редактируемая при помощи некоторого CASE-инструмента. Идея здесь состоит в том, что ведение такой документации облегчает работу. На самом деле, чаще всего она вообще не нужна, поскольку:
Итак, если вы хотите иметь текущую документацию по проекту, учитывайте все вышеперечисленные проблемы:
И, наконец, последний аспект использования UML для документации - передача проекта в другие руки (например, от одной группы разработчиков другой). Согласно методологии ХР, создание документации - такая же задача, как и все остальные, а значит, ее приоритет должен быть определен заказчиком. В этой ситуации может пригодиться UML, разумеется, при условии избирательности диаграмм, которые создавались с целью облегчения коммуникации. Помните, что программный код - это основной репозиторий подробной информации, а диаграммы служат для обобщенного представления основных аспектов системы.
Задачи, плохо поддающиеся рефакторингу
Можно ли вносить в систему все проектные решения путем рефакторинга, или же все-таки существуют некоторые вещи, которые настолько всепроникающи, что добавить их впоследствии будет очень и очень сложно? В настоящий момент ортодоксы ХР утверждают, что все можно добавить позже, а именно тогда, когда оно понадобится. Поэтому принцип YAGNI может быть применен в любой ситуации. Я все же, сомневаюсь, нет ли здесь исключений из правила. Возьмем, к примеру, поддержку нескольких языков (локализацию). Может быть, если работать над ней с самого начала, можно избежать мучений по поводу того, как ее внести в систему на более поздних стадиях разработки?Я могу легко назвать еще несколько вещей, которые попадут в ту же категорию. Однако в действительности у нас еще очень мало информации. Если вам нужно внести в систему что-то новое (например, локализацию), то непосредственно перед добавлением вы сможете адекватно оценить, каких усилий это потребует. Вы не сможете оценить это, если будете вкладывать усилия в локализацию на итерациях, предшествующих той, в которой она понадобится. Вы также не сможете адекватно оценить, какие усилия вам понадобятся, чтобы исправить ошибку, которую вы вполне могли допустить в начале работы (в таком случае, вам опять-таки понадобится рефакторинг).
Принцип YAGNI частично оправдывается тем, что очень многие из таких потенциально необходимых задач, в конце концов, оказываются вовсе не так уж необходимы. По крайней мере, не в том виде, в котором вы ожидали. Вам потребуется гораздо меньше усилий на то, чтобы не выполнять пока такие задачи, чем на исправление ошибочных решений и рефакторинг.
Кроме того, всегда стоит учитывать знание проблемы. Если вам уже приходилось несколько раз заниматься локализацией, то вы наверняка будете применять в работе некие паттерны, а значит, у вас больше шансов сделать все правильно с самого начала. Если вы опытный специалист, то, наверное, будет лучше разработать некие предварительные структуры (чего никак нельзя порекомендовать новичкам).
Я бы сказал, что те, кто знает, как это делается, могут сами судить о затратах, которые нужны для выполнения такой задачи. Однако, если вы никогда раньше не занимались такими проблемами, вы не только не можете верно оценить задачу, но и скорее всего, будете допускать ошибки в ее решении. В таком случае, лучше будет внести нужные дополнения в систему позже. Если же вы так и поступили, а теперь испытываете массу трудностей, то поверьте, вам было бы куда тяжелее, начни вы работать над этой задачей с самого начала. Теперь ваша команда уже более опытна, вы лучше понимаете предметную область и требования к системе. Часто, оглядываясь назад, вам будет казаться, что раньше это было бы сделать намного проще. Смею вас уверить, все могло быть гораздо сложнее, если бы начали работать над этим в начале проекта.
Эта проблема связана с вопросом порядка выполнения требований пользователя (user stories). В книге Planning XP
мы с Кентом ясно обозначили наши разногласия. Кент считает, что единственным фактором, определяющим порядок работ над задачами, должна быть их важность для заказчика. Теперь на такую же точке зрения встал и Рон Джеффриз, который раньше придерживался другого мнения. Я, все же, не могу с ними согласиться. Мне кажется, что должен существовать некий баланс между важностью задачи и техническим риском. Так, если использовать наш пример, то я стал бы заниматься локализацией раньше, чем это потребовалось бы, именно чтобы снизить риск. Впрочем, это было бы оправдано, только если локализация должна была бы присутствовать уже в первом выпуске системы. Выпустить программу как можно раньше - одна из жизненно важных задач. Все, что не нужно в первом выпуске, нужно вносить в систему после него. Впечатление, которое производит на заказчика работающий программный код, просто неописуемо. Первый выпуск программы заставляет его сосредоточиться на проекте, повышает уровень доверия к разработчикам, и кроме того, является мощным источником новых сведений. Делайте все от вас зависящее, чтобы этот день наступил как можно быстрее.Даже если вы знаете, что затратите больше усилий, если внесете новую функциональность позже, все равно лучше будет сделать это после первого выпуска системы.
(Недавно опубликованная статья Джима Шо
(Jim Shore) описывает некоторые ситуации, включая добавление в систему локализации и поддержки транзакций. Оказалось, что описанные здесь потенциальные проблемы вовсе не являются непреодолимым барьером).
Желание проектировать
До сих пор я обращал внимание, в основном, на технические аспекты проектирования. Однако при этом очень легко выпустить из поля зрения другой столь же важный аспект - человеческий фактор.Для того, чтобы принципы эволюционного проектирования сработали, нужна еще одна сила. И сила эта может исходить только от людей - какого-нибудь члена команды, для которого чрезвычайно важно, чтобы уровень дизайна всегда оставался на высоте.
Причем совсем необязательно, чтобы такое желание исходило от всех членов команды (хотя, конечно, это было бы замечательно). Обычно в команде есть один или два человека, которые берут на себя труд сводить воедино все элементы проектирования и следить за общим качеством дизайна системы. Вообще, это одна из тех задач, которые традиционно относится к сфере деятельности "архитектора".
В эту задачу входит постоянный присмотр за программным кодом системы. Если вдруг будет замечено, что какие-то модули становятся запутанными, необходимо тут же принимать меры по исправлению этой ситуации, пока она не вышла из-под контроля. При этом "хранителю дизайна" совсем не нужно все делать самому - ему достаточно убедиться, что эту проблему решил кто-то другой.
Вообще, основной причиной неудачи эволюционного подхода к проектированию является именно недостаток желания проектировать. Даже если вам хорошо понятны и знакомы все те принципы, о которых я говорю в этой статье, без желания проектировать у вас ничего не получится.
Управление проектами - статьи
Архитектура
Как бы ни было организовано в проекте владение кодом, в любом случае, вся разработка должна подчиняться некоторому более общему замыслу, подходу. Можно выделить как минимум три таких подхода:Глоссарий
Вроде бы мелочь. Но однажды может оказаться, что участники разных команд говорят «на разных языках». С одной стороны, это ведет к тому, что появляются различные названия для одних и тех же элементов в пользовательском интерфейсе приложения, в коде, в структуре данных. С другой – это приводит к разночтению требований и ошибкам в логике приложения. Еще более актуальным наличие глоссария становится тогда, когда участники проектных команд действительно говорят на разных языках.В каждом конкретном проекте этот список может быть расширен. Сюда могут попасть, например, проектные риски, всевозможные статистические отчеты, методики, справочники, инструкции и многое многое другое. Все эти документы могут стать наполнением вашего внутрикорпоративного информационного портала.
Инструментарий
Этот пункт касается решений, связанных с выбором и конфигурацией средств коллективной разработки.Исходный код
Промежуточный плод совместных усилий и, собственно, самое важное из того, для чего нужны такие совместные усилия. Как бы ни были далеки друг от друга участники команды, они неизбежно пересекутся здесь. Поэтому так важно планировать и организовывать процесс командного внесения изменений в код. Существует несколько подходов к этому вопросу:о том, какую информацию сделать
Электронная почта
Многими людьми именно этот способ общения считается наиболее предпочтительным. Да, у этого способа есть несколько очевидных преимуществ: письма имеют достаточно официальный статус, долговременно хранятся на сервере, копия письма может быть отправлена руководителю. Электронная почта прекрасно подходит для передачи объемных сообщений, для одновременной рассылки информации нескольким участникам и для сообщения окончательных решений. Однако зачастую эти преимущества могут превратиться в недостатки: письмо не требует мгновенного ответа, поэтому письма часто откладываются, после чего про них забывают вовсе. Письма часто объемны, поэтому многие читают их «по диагонали». Письма достаточно официальны, поэтому в них не будет сиюминутных мелких деталей, из письма часто трудно почувствовать настрой команды и действительное состояние дел. В этом смысле письма похожи на проектную документацию, с той лишь разницей, что документация читается по необходимости, а письма приходят сами.Методология разработки
Это один из тех вопросов, по которым людям может быть сложнее всего договориться. Когда для одного наилучшим подходом будет казаться экстремальное программирование, другой будет поднимать вопрос о недостатке документации и протестовать против изменения требований. Здесь у каждого найдется свой личный опыт и собственное видение ситуации. Споры могут продолжаться вечно. Мое мнение – право окончательного решения по таким вопросам должно быть только у одного человека. Авторитет этого человека должен быть достаточно высоким.Недоверие
Люди склонны не доверять тем, кого мало знают. Если два человека ни разу не видели друг друга в лицо, они будут стараться оградить каждый свою часть работы от взаимного вмешательства. Банально, отлаживая код, разработчик будет предполагать что ошибка - в коде другого разработчика. А если уж там будет ошибка, реакция будет куда более болезненная, чем если эта ошибка будет сделана человеком, с которым разработчик работает непосредственно. Люди, работающие в одном помещении, в целом мягче относятся к просчетам других людей, и критика их приобретает гораздо более спокойную форму, чем в случае с иногородними или иностранными коллегами. Вот почему еще так важно организовать сотрудникам хотя бы одну личную встречу.Области коллективного владения
Здесь речь пойдет о тех областях, в которых участники проекта ежедневно пересекаются друг с другом – их общее поле деятельности и точки приложения усилий.Общий сетевой ресурс
Самый минимум того, что нужно иметь проектной команде для того, чтобы хоть как-то обмениваться данными.Ощущение, что все лучше, чем на самом деле
Возникает оттого, что проблемы команд часто остаются их внутренними проблемами, а наружу выносятся только положительные стороны и достижения. Чтобы понять действительное состояние дел в команде, необходимо погрузиться в ее ежедневную деятельность, провести внутри нее какое-то время. Другими словами, войти в доверие. Однако когда разработка ведется несколькими удаленными командами, у руководителя не всегда хватает времени на то, чтобы уделить им равное внимание. Если руководитель посещает удаленный офис раз в год и проводит в нем 3 дня – сложно сказать, правильные ли выводы он сделает из своего визита. Проводя в команде хотя бы неделю раз в 3-4 месяца, узнать можно гораздо больше.Ответственность команд
Логичное следствие из предыдущего пункта. Если в проекте участвует несколько команд, нужно знать, какая команда за что отвечает и кто является контактным лицом от каждой команды.Пересекая границы: специфика разработки ПО распределенной командой
,Эта статья написана на основе опыта работы в нескольких проектах по разработке ПО, где участники проектной команды были в большей или меньшей степени удалены друг от друга: начиная от варианта «одна команда в двух офисах в одном городе», и заканчивая вариантом «3 команды в разных странах – из них одна на другом континенте». Как появляются такие проекты? В малых компаниях ценность конкретного специалиста для проекта часто выше, чем возможные расходы на коммуникацию, и его местожительство не берется в расчет. В крупных компаниях, наоборот, появляется большой объем работ, не требующих высокой квалификации, и задачи реализуются с привлечением субподрядчиков, в том числе из других стран. Проблемы возникают при этом очень похожие, и современные средства коммуникации не всегда оказываются панацеей.
В этой статье я постараюсь перечислить несколько ключевых аспектов разработки ПО распределенной командой и описать решения, которые помогли или не помогли более эффективному взаимодействию внутри или между командами.
Планы и бизнес-цели
Имеются в виду высокоуровневые планы и высокоуровневые бизнес цели. Отвечают на вопросы, соответственно, «к какому сроку» и «зачем». Высокоуровневые планы содержат даты, когда наличие разработанной функциональности становится критичным для бизнеса заказчика, бизнес-цели объясняют, ради чего, собственно, все работы ведутся. Для технического специалиста эти знания по важности стоят после требований, но позволяют реализовывать последние гораздо более осмысленно и эффективно.Проблемные участки
Здесь я перечислю те проблемы, которые при разработке глобальной командой встречались мне чаще других.Процедура внесения изменений в исходный код (Check-in)
При совместном написании кода одним из наиболее критичных моментов становится внесение сделанных изменений в репозиторий исходного кода. Необходимо четко определить условия, при выполнении которых допустимо внесение изменений в код (код компилируется, модульные тесты выполняются и т.д.).При наличии разницы во времени между несколькими командами полезным может оказаться такой регламент, когда каждая команда может вносить изменения только в определенное время, например в течение определенного часа, раз в сутки. Однако этот подход имеет и существенный недостаток: изменения, накопленные за день перестают быть атомарными, внесение изменений регулярно откладывается, если в определенный регламентом промежуток времени разработчик не готов гарантировать выполнение условий для Check-In. Более удачным решением может стать регламент, запрещающий вносить изменения в некоторый период времени и разрешающий это во все остальное время.
Простейший web-ресурс с фото и краткой информацией о каждом участнике проекта
Казалось бы, мелочь, но позволяет создать у участников проекта хотя бы какое-то ощущение общности. Видя свои фото в одном месте, люди начинают верить, что они работают в одном проекте. Чем больше конкретных деталей один человек знает о другом, тем менее абстрактным он ему кажется, тем легче этим людям общаться друг с другом. Кроме всего, такой сайт – еще и удобное место для того, чтобы указать позицию, зону ответственности и контактную информацию каждого из участников.Система хранения документов
Обеспечивает коллективный доступ к проектной документации и позволяет хранить версии документов. Если исходный код почти всегда помещается в систему управления версиями, то документы часто хранятся просто на общем сетевом ресурсе. Тем не менее, использование системы управления версиями для хранения документации не менее полезно, чем для хранения кода. Кстати, ничто не мешает использовать для хранения кода и документации один и тот же репозиторий, не приобретая дополнительной системы.Система контроля версий
Наличие такой системы я рассматриваю как обязательное условие профессиональной разработки ПО. Говорить о преимуществах такой системы я не буду – эта информация есть в обилии в других источниках. Скажу только о том, что выбор конфигурации системы контроля версий оказывает существенное влияние на процесс разработки в целом. С одной стороны, использование только локально доступной системы контроля версий (свой собственный репозиторий у каждой локальной команды) имеет определенные преимущества – нет необходимости согласовывать время внесения изменений, нет задержек, связанных с плохой работой сети при интеграции со средствами разработки. С другой стороны, решение об использовании локального репозитория требует наличия модульной архитектуры разрабатываемой системы и увеличивает интеграционные риски.Системы учета заданий и ошибок (Tasktracking, Bugtracking systems)
В процессе разработки ПО одним из важнейших средств коммуникации становится именно система учета ошибок (заданий). Значение таких систем часто недооценивают. Тем не менее, такая система позволяет собрать всю информацию об ошибке (задании) в одном месте. Хранение вместе с описанием ошибки всего хода ее обсуждения и всех связанных файлов дает прекрасную возможность исправить ошибку, не прибегая больше ни каким источникам информации, и, при необходимости, просмотреть всю историю принятия решений. Надо помнить, что ошибки часто исправляются участниками, пришедшими в проект намного позже момента их обнаружения. Иногда старые ошибки открываются заново спустя значительное время после того, как были исправлены в первый раз.Skype, Icq и другие системы мгновенного обмена сообщениями
Я отвожу этому способу общения ведущую роль даже в тех проектах, где участники располагаются в одном офисе. По моему опыту, большая часть общения в проектах происходит именно с помощью этих средств. Это не во всех случаях так же эффективно, как телефонный звонок, не так официально, как электронное письмо, но это то средство, которое всегда «под рукой» и при этом позволяет общаться «асинхронно», т.е. задавать вопрос тогда, когда он появился, и отвечать тогда, когда есть момент. В случае, когда телефонная связь между командами является слишком дорогой, это вообще первое средство. Я думаю, дело еще и в том, что этот способ общения наиболее похож на живой разговор двух людей, эффективнее которого, по-моему, только телепатия.Способы коммуникации
В отличие от предыдущего пункта, который описывает, о чем можно узнать, если знать, где это лежит, данный пункт касается непосредственно способов прямого общения двух и более участников проектных команд.Структура команды
Людям нужно знать, кто какие позиции занимает в проекте и за что отвечает – для того, чтобы задавать друг другу вопросы, чтобы просить о выполнении некоторых работ или сообщать о проблемах. Должны быть известны и способы связи – телефон, адрес электронной почты, имя (номер) в системе обмена мгновенными сообщениями. Не считайте, что все и так всех знают – когда-нибудь обязательно выяснится, что это не так.Текущая сборка (Build)
Ежедневная сборка – это процесс, дающий команде уверенность, сигнализируя об успешности или не успешности интеграции отдельных модулей. Это - ориентир команды. Очень важно иметь каждый день актуальную версию разрабатываемого приложения и убеждаться, что она работоспособна и проходит тесты. Соответственно, когда проект не собирается из-за ошибки одного из разработчиков, это сказывается на работе всех остальных. Это может пугать, но это позволяет каждому разработчику в полной мере ощутить свое участие в создании конечного продукта, почувствовать командный дух и персональную ответственность за результаты труда.Телефон
При всем удобстве систем мгновенного обмена сообщениями, иногда наступает момент, когда проще сказать в двух словах, чем описывать в нескольких предложениях. Телефон, из всех средств удаленного общения - еще и самый лучший способ заставить другого человека тебе ответить (телефонный звонок сложнее всего проигнорировать). Казалось бы, зачем описывать преимущества способа связи, которому уже больше века? Тем не менее, в условиях высоких цен за междугородние и международные разговоры, телефонная связь может показаться излишеством. Стоит, однако, хорошо подумать, прежде чем отказаться от такого высокоэффективного средства.Требования
Зафиксированные в каком бы то ни было виде, требования позволяют каждому участнику проекта четко понимать, что ему нужно сделать, а значит и позволяют делать прогнозы относительно сроков выполнения задач. В условиях распределенной команды, зафиксированные требования – часто вообще единственный способ добиться какого-либо результата. Несмотря на кажущуюся банальность этих утверждений, удивительно, насколько часто этим пренебрегают, поручая людям делать что-то неопределенное.Треккеры
Имеются в виду все средства учета задач, требований, ошибок и т.д. Как я уже говорил, система учета ошибок является одним из важнейших средств коммуникации проектной команды. Соответственно, такое средство должно у проектной команды быть.Управляющая информация
В любом проекте самым надежным каналом связи всегда будет канал «управляющий центр – подчиненные подразделения» («Руководитель – исполнители»). Если отсутствие связи между участниками команды еще можно себе представить, то отсутствие связи с руководителем означает, что проект скорее мертв, чем жив. Наряду с управляющим воздействием, по этим каналам можно распространять и информацию, рассчитывая на то, что она действительно дойдет до всех членов команды.Известно, что любой специалист гораздо лучше выполняет свою работу, если знает, что конкретно нужно сделать, к какому сроку, зачем это нужно сделать и почему это нужно сделать именно так, а не иначе. Соответственно, общедоступной в проекте должна быть следующая информация:
Видеоконференция
Видеоконференция – это когда несколько человек смотрят друг друга по телевизору и не более того, по крайней мере, в условиях отсутствия сверхбыстрых каналов передачи видеосигнала. Не могу сказать по своему опыту, чтобы видеоконференция могла помочь решить хотя бы один по-настоящему сложный вопрос. Так как видеоконференция обычно устраивается для одновременного общения многих людей, некоторые люди в таких условиях предпочитают хранить молчание, особенно, если обсуждение вопроса для них невыгодно. При этом, молчать по другую сторону экрана - гораздо легче, чем сидя за одним столом. Для многих людей видеоконференция – непривычный способ общения, поэтому, несмотря на кажущуюся схожесть с живым разговором, она может казаться людям менее удобной, чем переписка по электронной почте или обмен сообщениями.возникают не только от физической
Проблемы, собственно, возникают не только от физической удаленности. Даже два программиста, сидящие за соседними компьютерами, могут работать над одним проектом и совершенно не интересоваться друг другом. Если два человека находятся в двух разных комнатах одного офиса – иногда это почти то же самое, как если бы они жили на разных планетах, если только считать, что между планетами имеется Интернет-связь. Тем не менее, у этих людей есть шанс встретиться на общей кухне, и это уже лучше, чем ничего. Если они встречаются на совещании, раз в неделю – почти хорошо, они уже наверняка будут знать друг друга по имени. Другое дело, что даже такие нечастые личные встречи для многих команд – роскошь. Иногда люди работают вместе годами и знают друг о друге только имя, номер Icq и адрес электронной почты. Думая об эффективности работы в таких условиях, ключевое внимание, по моему мнению, следует уделить следующим аспектам:Живой контакт
И все-таки, ничего не заменит личного общения людей. По своему опыту знаю, что к человеку начинаешь относиться совсем по-другому, если видел его лично. В условиях распределенной команды сделайте все возможное, чтобы участники встретились хотя бы раз. Даже одна командировка может дать отличный импульс к более успешному взаимодействию сотрудников.Знания о разрабатываемой системе
Это те знания, которые участники команды разделяют между собой. Сюда относятся как знания об архитектуре и исходном коде, так и то общее представление о разрабатываемой системе, из которого архитектура и код материализуются. Проектная документация – спецификации, руководства и пр. - лишь частичное, пусть и упорядоченное отражение этих знаний. В отличие от управляющей информации, такие знания более естественно распространяются в горизонтальной плоскости, от одного участника к другому. Так или иначе, стоит подумать о том, как сделать этот обмен эффективнее. Рассмотрим несколько возможных подходов.Я бы предпочел создавать документы только по мере необходимости, всегда обсуждая этот вопрос с группой разработки.
Управление проектами - статьи
Особенности экономики производства крупных программных продуктов
При экономическом анализе и обосновании проектов сложных комплексов программ возможны два сценария:создание и весь жизненный цикл комплекса программ ориентируется на массовое тиражирование и распространение их на рынке среди заранее не известных пользователей, в различных сферах и внешней среде применения; при этом отсутствует конкретный внешний потребитель-заказчик, который определяет и диктует основные требования к программному продукту, выделяет ресурсы и финансирует проект;
Эти сценарии принципиально различаются методами
экономического анализа и обоснования экономических характеристик продукта. Первый сценарий базируется на маркетинговых исследованиях рынка программных продуктов и на стремлении поставщика занять на рынке достаточно выгодное место. Для этого ему необходимо определить наличие на рынке всей гаммы близких по назначению и функциям продуктов, оценить их эффективность, стоимость и применяемость, а также возможную конкурентоспособность предполагаемого к разработке программного продукта для потенциальных пользователей и их возможное число. Следует оценить рентабельность затрат на создание и обеспечение всего ЖЦ нового программного продукта, выявить факторы, функциональные, экономические и конструктивные показатели качества, которые способны привлечь достаточное число покупателей и оправдать затраты на предстоящую разработку. Для этого разработчикам необходимо проводить оценки возможной конкурентоспособности предполагаемой продукции на рынке по величине соотношения:
возможной эффективности
(ценности, достоинств) последующего применения программного продукта и способности удовлетворить потребности пользователей при их приобретении и использовании;
При выборе поставщика и продукции покупатель обычно стремится максимизировать это соотношение как за счет поиска продуктов с наибольшими эффективностью и качеством, так и за счет минимальной стоимости покупаемого продукта. В этом сценарии при организации производства вся ответственность за цели, функции и показатели качества продукта ложатся на его производителей, и особую роль при экономических оценках должны играть специалисты по маркетинговому анализу предполагаемого распространения продукта на рынке. Они должны оценивать: конъюнктуру и риск успешного продвижения создаваемого продукта на рынок, сроки и график выполнения этапов жизненного цикла, достаточность ресурсов для реализации проекта и длительность развития, модификаций и распространения версий программного продукта. Для этого им нужны, в частности, прогнозы экономических характеристик производства предполагаемого продукта. Такие проекты обычно относительно невелики по объему и срокам реализации первой версии программного продукта, однако могут предполагать длительный жизненный цикл и множество модификаций для адаптации к нуждам и среде пользователей.
Второй сценарий предполагает наличие определенного заказчика-потребителя конкретного программного продукта, который должен соответствовать его функциональным, техническим и экономическим требованиям. Заказчик может выбирать конкурентоспособного поставщика-разработчика и оценивать его возможность реализовать проект с необходимым качеством с учетом ограничений требуемого бюджета, сроков и других ресурсов. При этом результаты разработки не обязательно подлежат широкому тиражированию, они могут не поступать на рынок; маркетинговые исследования для таких продуктов являются второстепенными и предварительно могут не проводиться.
Однако для заказчика и разработчиков при заключении контракта необходимо достаточно достоверное прогнозирование требований к программному продукту и экономическое обоснование необходимых ресурсов
по трудоемкости, стоимости, срокам и другим показателям.
Заказчик заинтересован в получении продукта высокого качества при минимальных затратах, а разработчик желает получить максимальную оплату за созданный продукт и достаточные ресурсы на его производство. Противоположность интересов поставщика и потребителя при оценке экономических характеристик, стоимости и других ресурсов проекта, требует поиска компромисса, при котором производитель программного продукта не продешевит, а заказчик не переплатит за конкретные выполненные работы и весь проект. Поэтому оба партнера заинтересованы в достоверном экономическом прогнозировании и обосновании процессов проектирования и производства программного продукта.
Во многих случаях эффективность систем новой техники и программных продуктов в процессе производства приходится прогнозировать в условиях неопределенности целей, требований к функциям, различных факторов и характеристик заказываемых систем и продуктов. Зачастую бывают недостаточно известны перспективы внедрения, распространения и применения объектов производства – новых программных продуктов. Значительные неопределенности содержатся также в экономических характеристиках производственных технологий, а также инструментальных средств автоматизации проектирования и изготовления комплексов программ. Положение усугубляется трудностью поэтапного определения качества компонентов и его прогнозирования в процессе производства, что непосредственно отражается на экономических характеристиках реализации продукта в целом.
Методы и достоверность экономического анализа производства и
жизненного цикла крупных комплексов программ можно разделить на две части, существенно различающиеся свойствами производственных процессов, экономическими характеристиками и влияющими на них факторами. В первой части ЖЦ производятся: системный анализ, проектирование, разработка, тестирование и испытания первой (базовой) версии программного продукта. Номенклатура работ, их трудоемкость, длительность и другие характеристики на этих этапах ЖЦ существенно зависят от свойств создаваемого продукта, требуемых показателей качества, внешней и технологической среды разработки.
Изучение подобных зависимостей для различных прототипов программных продуктов позволяет достаточно достоверно прогнозировать состав и основные экономические характеристики производства, планы и графики работ для вновь создаваемых продуктов.
Вторая часть ЖЦ, отражающая применение, сопровождение и развитие версий программного продукта, связана не только с экономическими характеристиками продукта и среды производства. При этом экономические характеристики производства зависят от интенсивности изменений версий, сложности и стоимости каждой модификации программного продукта. Совокупность версий сложных программных продуктов обычно характеризуются длительной непрерывной эксплуатацией, продолжительность которой значительно превышает длительность производства первой версии. После того как программный продукт создан и испытан, в ряде случаев он становится недоступным для разработчиков и применяется неизменным до внедрения очередной версии при модификации системы. В процессе сопровождения программы могут подвергаться эпизодическим корректировкам, которые должны регистрироваться, накапливаться и передаваться пользователям экземпляров системы. Необходимо обеспечивать адекватность документации каждой версии эксплуатируемого продукта в любой момент времени.
Номенклатура работ на этапах сопровождения более или менее стабильная, а их трудоемкость и длительность могут сильно варьироваться и зависят от массовости и других факторов распространения и применения конкретного программного продукта. Успех продукта у пользователей и на рынке, а также экономические характеристики процесса развития версий
трудно предсказать, и определяющими становятся потребительские характеристики и качество продукта, а его экономические особенности с позиции производства отходят на второй план. Вследствие этого трудно прогнозировать экономические характеристики, трудоемкость и необходимое число специалистов, поддерживающих этапы производства модификаций программного продукта. Это затрудняет обобщение экономических характеристик производства для различных версий продуктов и прогнозирование на их основе аналогичных характеристик новой разработки.
В результате их приходится проводить итерационно на базе накопления опыта и анализа экономических характеристик модификаций конкретных типов и версий программных продуктов.
Наиболее сильно на экономические характеристики производства программных продуктов (кроме требуемых функций) влияют их масштаб – размер, а также требования к качеству. Оценка размера будущего программного продукта необходима, поскольку она является частью одной из наиболее важных задач проекта: возможности реализации требований заказчика и потребителей при доступных ресурсах. Нереальные ожидания, основанные на неточных экономических оценках проектирования и производства, представляют собой одну из частых причин провала проектов. Измерение размера, оценка и составление графика производства программного продукта сложным образом переплетаются в процессе планирования проекта. Довольно сложно создать реальный график (учитывающий обязанности исполнителей, их зависимости, перекрытие действий, а также дату поставки продукта) без информации о размере трудозатрат, требуемых для выполнения каждой частной задачи и создания компонентов. Таким образом, измерение размера (сложности) компонентов и комплекса в целом должно предшествовать оценке полных экономических характеристик проекта, а эта оценка, в свою очередь, должна предшествовать составлению производственного графика работ.
Качество продуктов характеризуется многими показателями, состав которых зависит от класса, функций и конкретного назначения комплекса программ. По мере повышения требований к качеству затраты на производство увеличиваются все более высокими темпами. Одновременно расширяется диапазон неопределенности достигаемого качества при допустимых затратах. В результате для сложных программных продуктов всегда есть риск проявления неустраненных ошибок и недостаточной достоверности оценок качества. Специфицирование требований и оценивание характеристик качества программного продукта — ключевой фактор обеспечения их адекватного применения.
Это может быть достигнуто на основе выделения, определения и реализации подходящих характеристик с учетом целей использования и функциональных задач комплекса программ с использованием стандартизированных или формализованных метрик [, , ]. Задача состоит в создании, выборе и прогнозировании наиболее адекватных экономических критериев
для обобщенного описания эффективности производства, стоимости создания и использования сложных комплексов программ в зависимости от их назначения, области применения, требуемого качества и других факторов.
Для сложных продуктов с высокими требованиями к качеству проектирование, развитие и применение систем обеспечения и контроля качества должно сопровождать весь жизненный цикл основной продукции — комплексов программ. Включение комплексов программ в контур систем управления производством промышленной продукции или динамическими объектами приводит к необходимости обеспечения ими высокого качества решения задач, безопасности и надежности их функционирования не ниже, чем у аппаратных компонентов соответствующих систем. Поэтому комплексы программ должны тщательно тестироваться и проходить контрольные испытания для определения уровня качества, безопасности и надежности их применения, что может требовать особенно больших затрат ресурсов.
Проблемы анализа экономики производства программных продуктов
Экономические характеристики реальных завершенных разработок, собираются, накапливаются и обрабатываются с начала 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:Оформление разработанных материалов в виде веб-сайта
Описание разработанного процесса сопровождения оформляется в виде веб-сайта, доступного в качестве справочно-методического материала для всех участников процесса сопровождения. Сайт вводится в действие до начала внедрения процесса сопровождения.Оформление методических материалов в виде веб-сайта позволяет облегчить процесс внедрения процесса сопровождения в организации за счет того, что:
Сведения об авторах:
Все авторы работают в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК в г. Москва.
Реализация стандарта ГОСТ Р ИСО/МЭК
Галахов И.В., Лапыгин Д.В., Позин Б.А., Шкляева Н.А.Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем"
Роль артефактов в процессе адаптации
В СТАНДАРТЕ представлены два вида артефактов, используемых в задачах процесса сопровождения - входные и выходные. На основании СТАНДАРТА можно выделить ряд документов(артефактов), рекомендуемых к использованию в процессе сопровождения, например, "концепция сопровождения", "программное средство", "исходные программы", "уведомление о завершении переноса" и т.п.При внедрении процесса сопровождения в организации обычно не используются точные названия артефактов СТАНДАРТА, а производится разметка требований и рекомендаций стандарта для набора артефактов, определенного на основе артефактов RUP . Например, кроме артефакта "результаты тестирования" также используются артефакты "сводная оценка результатов тестирования", "модель тестирования", "тестовый скрипт" и т.п.
Разделение артефактов на "входные" и "выходные" находит развитие в концепции RUP , согласно которой каждый артефакт может играть роль "входного" или "выходного" в разных задачах. При этом также уделяется внимание состоянию артефакта, поскольку каждый артефакт может иметь несколько степеней готовности, начиная от момента создания первой версии артефакта до момента завершения изменений артефакта.
Для удобства оценки готовности артефакта и облегчении его создания (в том числе автоматизированного) каждый артефакт снабжается шаблоном, на основании которого он может быть разработан. В процессе адаптации шаблоны артефактов структурируют информацию, создаваемую и используемую в процессе сопровождения ПС.
Ролевые функции и организационная структура
При внедрении процесса сопровождения программных средств в организации на основе СТАНДАРТА одна из основных задач, требующих решения - определение функциональных ролей, ответственных за выполнение задач процесса сопровождения. Описание процесса сопровождения в терминах функциональных ролей позволяет не зависеть от существующей организационной структуры, которая может меняться .При этом привязка организационной структуры к ролевым функциям осуществляется выпуском организационно-распорядительных документов определяющих, кто какие ролевые функции выполняет. Например, можно использовать таблицу, где в каждой строке в правом столбце указан сотрудник, а в левом - одна или более ролей, которые он выполняет. Изменение организационной структуры не влияет на процесс сопровождения и требует лишь выпуска распоряжения, корректирующего распределение ролевых функций среди персонала.
Рисунок 2 - Привязка организационной структуры к ролевым функциям процесса.
В СТАНДАРТЕ ролевые функции в явном виде не вводятся, хотя в тексте использованы термины "заказчик", "разработчик", "сопроводитель", "поставщик", к которым относятся требования по сопровождению ПС. Поэтому при адаптации СТАНДАРТА рекомендуется использовать за основу ролевую структуру, существующую в RUP, дополнив ее функциональными требованиями к ролям из СТАНДАРТА. Например, требования к "сопроводителю" обычно распределяются между такими ролями как "менеджер по сопровождению", "менеджер по управлению требованиями" и "менеджер по конфигурационному управлению".
Технология адаптации
Внедрение процесса сопровождения на основе СТАНДАРТА требует значительных усилий как в нормативно - методологической, так и организационно - технологической плоскости, поскольку универсальность стандарта оборачивается необходимостью проработки деталей для реализации основных положений стандарта в соответствии с потребностями и условиями деятельности заказчика.Основное правило, используемое при адаптации СТАНДАРТА для внедрения процесса сопровождения у заказчика - все положения стандарта используются без изменений. Они могут быть дополнены, детализированы или просто могут не использоваться, но если используются, то в том виде, как это определено в стандарте.
При проведении адаптации СТАНДАРТА проводится обследование организации, завершающееся анализом и разработкой структуры процесса сопровождения, после чего проводится автоматизация процесса сопровождения и его ввод в действие. При этом выполняются следующие шаги:
МЭК 12207 определяет архитектуру верхнего
Стандарт ГОСТ Р ИСО/ МЭК 12207 определяет архитектуру верхнего уровня жизненного цикла программных средств (ЖЦ ПС) и может быть использован для организации работ по одному или нескольким процессам ЖЦ ПС. Вместе с ГОСТ Р ИСО/МЭК ТО 15271-2002 "Руководство по применению ГОСТ Р ИСО/МЭК 12207" стандарт ГОСТ Р ИСО/МЭК 12207 предоставляет возможности для адаптации к широкому кругу задач на основе расширения рекомендаций стандарта путем ввода новых процессов, работ, задач или других объектов ЖЦ ПС, не рассматриваемых в стандарте. В качестве примера можно сослаться на раздел 4 приложения " D " к ГОСТ Р ИСО/МЭК ТО 15271-2002 - "Пример сопровождения".В последнее время все большим интересом у наших заказчиков пользуется процесс сопровождения ПС. До недавнего времени при его внедрении на основе стандарта ГОСТ Р ИСО/МЭК 12207 детализацию основных положений процесса сопровождения приходилось выполнять на основе различных международных источников и собственного опыта. Новый СТАНДАРТ детализирует процесс сопровождения, установленный в ГОСТ Р ИСО/МЭК 12207, и содержит рекомендации по планированию и выполнению процесса сопровождения, контролю и надзору за ним, его оценке и завершению. СТАНДАРТ устанавливает основную структуру процесса сопровождения ПС, но не определяет подробности реализации или выполнения работ и задач, входящих в данный процесс.
СТАНДАРТ предназначен для организаций, сопровождающих ПС или отвечающих за разработку и качество ПС, и детализирует требования к:
СТАНДАРТ не предназначен для готовых программных продуктов, если они не входят в состав ПС в качестве его элементов. Далее будет представлена методика постановки процесса сопровождения на основе СТАНДАРТА и технологии RUP , используемой для адаптации процесса сопровождения к потребностям конкретной организации.
Взаимодействие с другими процессами ЖЦ ПС
Процесс сопровождения выполняется на всех стадиях ЖЦ ПС, поэтому важную роль играет правильное определение его взаимодействия с остальными процессами ЖЦ ПС. В частности, многие задачи, которые требуется выполнять в процессе сопровождения, относятся к другим процессам. Обычно это вспомогательные процессы ЖЦ ПС такие как управление конфигурацией и обеспечение качества. В этом случае возможны два варианта определения таких задач:
Рисунок 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 — способность поддерживать интегрированный документооборот в проектной группе, благодаря тесной интеграции с серверными продуктами компании.
Современные инструменты проектного менеджмента
«Экспресс-Электроника»Сегодня на российском рынке автоматизированных систем управления проектами наиболее активны несколько игроков: лидер мирового рынка ПО данного класса — 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 может проявить себя в строительно-монтажных и промышленных организациях.
Управление проектами - статьи
Быстрое документирование плюс обсуждение
Если разработчики активно обсуждают проект в ходе разработки, то документирование можно сделать менее формальным.Самый замечательный трюк, позволяющий упростить документацию, это просто-напросто сфотографировать доску, на которой вы вели техническую дискуссию.
Есть и другой способ - нарисовать на бумаге архитектуру системы, диаграммы классов и т.п., а потом отсканировать рисунок и поместить его на веб. Рисовать вручную все еще гораздо быстрее, нежели с помощью примитивных программ для рисования на вебе.
Можно еще снять на видео, как два дизайнера обсуждают фрагмент архитектуры системы. Чтобы сделать это хорошо, нужно заранее позаботиться о правильном освещении и о том, чтобы обсуждение длилось не более 15 минут (видеокассету с часовой дискуссией никто не станет смотреть до конца).
Кроме того, можно написать несколько страниц текста с вкраплениями небольших фрагментов диаграммы: несколько классов модели предметной области или часть диаграммы последовательности. Лучшие описания архитектуры системы, которые мне доводилось видеть, никогда не описывали всю модель целиком. Скорее, это были небольшие группы классов, которые иллюстрировали текстовые описания дизайна системы.
Наконец, документация должна быть только "приблизительным" описанием. А именно "достаточным для того, чтобы можно было понять, у кого что спрашивать (или где посмотреть это в коде), если возникнут вопросы".
Четвертое измерение или Как обмануть Железный Треугольник
Алистэр КоубернHumans and Technology, 4-ое октября 2003
Перевод: , сайт maxkir.com
Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.
Конечно, процесс имеет огромное значение для проекта. При этом хороший процесс не может гарантировать, что задача будет выполнена качественно и во время, а хорошая команда программистов способна справиться с задачей, даже если процесс будет тяжелым и неуклюжим. И, тем не менее, если процесс плохой, это всегда чрезвычайно мешает работе.
Как обмануть Железный Треугольник
Когда речь заходит о руководстве проектами, мы постоянно сталкиваемся с пресловутым Железным Треугольником
В этом треугольнике три вершины, которые описывают параметры проекта: объем работ, время и ресурсы. Можете жестко задать любые две из них, но не все три. Третья величина фиксироваться не должна. В противном случае проект окажется перегружен ограничениями.
Я прямо-таки вижу, как мой читатель глубокомысленно кивает - да, конечно, мы уже знакомы с этим треугольником.
И, несмотря на это некоторые из нас все же обнаруживают, что участвуют в проектах, где все три вершины "железного треугольника" уже заданы. Например, нам говорят, что мы должны разработать определенную функциональность за 18 месяцев с бюджетом 15 миллионов. Один из моих друзей постоянно получает задания, типа "у тебя есть четыре человека и три месяца, чтобы разработать вот такую функциональность". И, пусть с небольшими поправками, мы это делаем!
Секрет в том, что существует еще одна вершина, которую пока еще не оценили по достоинству: процесс разработки.
К сожалению, в большинстве организаций процесс разработки настолько неэффективен, что можно без особого труда увеличить продуктивность работы команды на 30%, всего лишь упростив его. Так мы сэкономим время и ресурсы, что даст нам возможность завершить проект (почти) в срок и (почти) уложиться в бюджет.
Вторая часть этого "секрета" состоит в том, что это ни для кого не секрет. Руководители проектов знали и использовали его на протяжении десятилетий. Я не уверен, что этот факт описывали в литературе, но старожилы часто рассказывали мне, как они давным-давно использовали то, что сейчас называется "гибкими методологиями", чтобы выполнить невыполнимый проект в срок.
Как же обмануть Железный Треугольник?
Я нередко называю гибкие методологии "законным обманом, который приводит к победе". В любой организации есть устоявшиеся стереотипы поведения, которые только мешают работе, и на поверку оказываются совершенно лишними. Просто есть условности, о пользе которых никто не задумывается.Вот три устоявшихся стереотипа, которые я стараюсь изменить:
Давайте заменим эти правила на другие:
Эти три постулата можно доказать двояко. Во-первых, книгами, в которых говорится об том же, с точки зрения теории и практики разработки ПО. Во-вторых, словами руководителей успешных проектов, которые уже многие годы применяют эти правила и подтверждают их своим личным опытом.
Моя статья слишком мала, чтобы описать все стратегические и тактические приемы, которые они используют. К тому же, об этом можно прочесть в нескольких книгах: "Managing the Design Factory", "Skunk Works", "Theory of Constraints", "Lean Software Development", "Agile Software Development", и "Agile Management for Software Engineering.
Я же пока ограничусь констатацией факта: когда я вижу, что проект перегружен, то начинаю с этих трех стратегий. Впрочем, не только я, но и другие опытные руководители. Давайте теперь обратимся к их опыту.
Одновременная разработка
Итак, два приема мы уже усвоили, теперь дело за третьим - одновременной разработкой приложения.Сначала люди, которые занимаются требованиями и работают вместе с программистами, получают ровно столько требований к системе, сколько нужно команде архитекторов, чтобы приступить к ее дизайну. Лучше всего, если один человек является одновременно и архитектором, и программистом. В худшем случае - это разные люди, которые работают бок о бок. В обоих случаях, если программирование начинается вскоре после выбора архитектуры системы, работающий (или не работающий) код даст самую верную информацию о слабых сторонах дизайна и о том, какие его части необходимо исправить сразу же, на ранних стадиях работы.
Некоторым такой стиль работы может показаться странным и даже неправильным, но я сам бывал поражен тем, что большинство команд программистов так или иначе сами приходят к использованию этой стратегии. Причина проста: им было понятно, что в противном случае их ожидает полный провал, неважно, что там полагается делать согласно официально принятому в компании процессу. Вспомните ваш последний успешный проект (или несколько проектов), и посмотрите, не использовали ли ваши программисты в разной степени эту же тактику.
Масштаб пересечения различных видов деятельности зависит от вполне конкретных вещей: "узких мест" процесса разработки, свободного времени сотрудников, нестабильности отдельных частей работы и т.п. Я обнаружил, что в разных проектах мы использовали совершенно разные стратегии одновременной разработки, в зависимости от вышеперечисленных факторов. Однако я всегда ищу, какие еще виды работ можно выполнять одновременно.
Пусть все люди работают в одном помещении
Когда люди работают в одной комнате, они постоянно находятся в пределах слышимости: можно случайно услышать информацию, которая пригодится в работе, можно задать вопрос и тут же получить на него ответ, можно услышать, как кто-то дает кому-то неправильный ответ и поправить его. При этом каждый раз экономятся время и деньги. Время, потому что иначе все отложилось бы на потом, деньги - потому что многие из неправильных и спорных вещей оказались бы задокументированы, и впоследствии пришлось бы работать уже над исправлением документации.Некоторые из тех, кого перевели на работу в общее помещение, грустят о мирной и тихой обстановке личного офиса. Однако, как заметил один из таких людей в личной беседе: "Мне очень нравился мой личный кабинет, но если честно, еще никогда в жизни я не работал так продуктивно, как в одной комнате со своими коллегами".
Конечно, существует несколько основных правил работы в общих помещениях. Первое гласит: вся команда должна работать над одним проектом, чтобы информация, которой обмениваются люди, была полезна в работе. (Впрочем, из этого правила, как из любого другого, есть исключения. Некоторые маленькие компании с небольшой, но хорошо сработавшейся командой выигрывают даже оттого, что слышат и корректируют информацию, касающуюся разных проектов.)
Согласно второму правилу, человеку нужно иметь личное место для работы, где он бы мог, в случае необходимости, укрыться от шума. Возвращение в общую комнату означает, что он снова готов работать над общими проблемами проекта.
Разумеется, это идет вразрез с утверждением, что общее помещение для работы есть безусловное благо. Однако бывает так, что какого-то человека буквально перегружают вопросами и проблемами, и ему приходится искать себе спокойное место, где он мог бы укрыться на время от коллег. Я описал подобную ситуацию в другой статье, под названием "Тихая гавань".
Сколько это может продолжаться?
Мой коллега Джефф Пэттон (Jeff Patton), который сам использует все вышеизложенные правила, согласен с моими гипотетическими вычислениями: благодаря этим стратегическим уловкам можно сразу же сделать работу на 30% эффективнее. И тут же задал вопрос - можно ли повышать эффективность процесса разработок бесконечно, или же это единоразовая отдача?Сначала мы полагали, что команда может обмануть "железный треугольник" только один раз. Однако, читая о повышении эффективности работ на Тойоте (Ohno, 1988), я пришел к выводу, что они занимались этим много раз на протяжении нескольких десятилетий.
Это заставляет меня думать, что мы можем обманывать "железный треугольник", по меньшей мере, немалое число раз, прежде чем он снова обретет свою неумолимую твердость. Ведь в большинстве организаций есть огромный простор для улучшений процесса работы.
"Тихая гавань и сходные стратегии управления проектами"
Интересная статья, описывающая знакомую многим ситуацию: лидером проекта является самый знающий и опытный программист, который отвечает за разработку основной функциональности системы.Разумеется, все остальные задают ему вопросы, просят помочь с решением проблемы и т.п. Времени на реализацию своих собственных задач у него просто не остается. Выполнение проекта оказывается под угрозой, нужно срочно что-то предпринимать. При этом начальство не хочет отказываться от стратегии "все работают в одном помещении", потому что она уже хорошо себя зарекомендовала.
Лидер проекта пробует работать в смежном с основной комнатой помещении, но этот компромисс не срабатывает, потому что все программисты опять толпятся у него. Пробуют ввести "приемные часы", но эта стратегия (популярная в академических учреждениях) тут вообще не работает.
Тогда, в качестве последнего средства (сроки поджимают), лидера проекта решают на время перевести в комнату в том же здании, но тремя этажами выше. И - о чудо - за оставшиеся дни он успевает доделать все возложенные на него задачи (потому что ему никто не мешает сконцентрироваться на работе). Оставшаяся без "мозгового центра" команда справляется сама, медленнее, но все-таки справляется.
После выпуска продукта лидер проекта возвращается в общую комнату и работает там в прежнем режиме - отвечая на вопросы и разрабатывая свою часть проекта.
Вывод прост, как все гениальное: в экстремальной ситуации, когда человеку необходимо сконцентрироваться только на своей задаче, он может покидать общую комнату и укрываться на время в "тихой гавани". После он может опять посвятить себя работе в команде.
Что для этого необходимо? Во-первых, понимание и поддержка менеджмента, который пойдет на дополнительные расходы (оставшаяся команда будет работать медленнее) и заботы (отдельное помещение, коммуникация), станет вникать в особенности методологии и реализации проекта. Во-вторых, "препятствие" между общей комнатой и "тихой гаванью" должно быть "непреодолимо". В смежной комнате будет всегда толпиться народ, и никакой "тихой гавани" не получится, а вот подниматься тремя этажами выше мало кому захочется. Впрочем, некоторые фирмы, использующие подобные стратегии, "отсаживали" команды разработчиков даже в отдельные здания - даже в сравнительно небольшой статье Алистэр старается охватить проблему максимально широко, приводит много интересных примеров и библиографию.
Здесь мы приводим лишь краткий пересказ статьи. Полностью ее можно прочитать на сайте Алистэра Коуберна: ("Cone of Silence and Related Project Management Strategies").
Но, несмотря на эту поправку, общая стратегия работы в одном помещении хорошо зарекомендовала себя как в реальных, так и в исследовательских проектах.
Временные рамки
И, наконец, я должен упомянуть определение временных рамок ("timeboxing"), замечательно эффективную стратегию, о которой я пока не говорил, потому что она, как правило, "обманом" не считается.Термин "временные рамки" имеет два разных значения, хотя в обоих случаях подразумевается определение промежутка времени, в течение которого разрабатывается некая функциональность программы. Его величина может варьироваться от одного дня до месяца (чаще всего используются промежутки длиной в неделю, две недели и месяц).
Однако есть и разница: в первом случае, требования "замораживаются" до истечения временного промежутка. Соответственно, в этих условиях команда может спокойно заниматься разработкой функциональности. Такой смысл термину "временные рамки" принято придавать в методологии Scrum (Schwaber, 2001). В другом случае, требования могут свободно меняться когда угодно, подразумевая, разумеется, что те, кто вносят изменения, имеют на это весьма веские причины. Именно так понимают этот термин приверженцы "экстремального программирования".
В тяжелой, враждебной обстановке, когда требования меняются слишком поздно, и команда не может на них отреагировать, надо переходить на "замкнутые временные рамки". Если же обстановка остается дружеской, то команда может воспользоваться преимуществом небольших оптимизаций и позволять менять требования во время фиксированного временного промежутка.
Одно из важнейших правил увеличения эффективности проекта, которое касается механизма "временных рамок", гласит:
Лучше урезать запланированную функциональность системы, но уложиться в сроки, чем тянуть (и тянуть, и тянуть) сроки, чтобы успеть завершить разработку функциональности.
На это существует ровно три причины:
Первое даст команде ощущение уверенности, отчего со временем люди станут работать еще более эффективно. Второе поможет хорошо управлять проектом и планировать работу. И, наконец, последнее станет настоящим двигателем процесса разработки. Я сам с удивлением слушаю рассказы руководителей проектов о том, как ускорился процесс разработки лишь потому, что люди поняли необходимость принятия временно удовлетворительных решений.
Управление проектами - статьи
Классификация подходов, методов и технологий.
В настоящий момент существует значительное количество работ, посвященных проблемам, методам и технологиям реинжиниринга ИС. Эти работы охватывают данную проблематику с различных точек зрения, рассматривая и исследуя в различной степени как проблемы концептуального уровня (иногда даже философского характера), так и конкретные методы, и инструментальные средства, предназначенные для реинжиниринга ИС.Несмотря на наличие множества различных решений, их исследование и комплексное применение на практике бывает затруднено. Причинами возникающих трудностей следует считать:
Следует признать, что на множестве существующих решений (подходов, методов и технологий) отсутствует их систематизация, обеспечивающая позиционирование и определяющая взаимосвязь решений на различных уровнях рассмотрения задач реинжиниринга, в том числе, уровнях методологии и инструментальных средств.
В сложившейся ситуации целесообразным видится определение классификации, определяющей структуризацию на множестве существующих подходов, методов и технологий реинжиниринга ИС.
Так, классифицируя существующие подходы, методы и технологии, можно выделить следующие уровни рассмотрения и исследования аспектов, соотносимых с деятельностью по реинжинирингу ИС (см Рис. 4).
Рис 4. Уровни рассмотрения и исследования аспектов, соотносимых с реинжинирингом ИС.
Первый уровень включает исследования, направленные на достижение концептуального понимания деятельности по реинжинирингу ИС.
Для каждого из процессов описывается его область применения, поток входящих в него работ (шагов процесса), определяются связи с другими процессами оценки. Следует признать, что потенциально эти процессы могут быть интегрированы в любой процесс разработки. Однако стоит заметить, что оценка унаследованных систем является лишь одной из задач по реинжинирингу ИС.
Еще одним примером процесса, направленного на решение локальной задачи, является итеративный процесс, определяющий следующую последовательность шагов, которые должны быть выполнены при планировании проектов реинжиниринга ИС [37]:
На третьем уровне рассматриваются (исследуются и разрабатываются) методы, каждый из которых направлен на решение некоторой локальной задачи, возникающей в процессе реинжиниринга ИС, например, выполнения определенного шага процесса. По сути, эти методы воплощают собой некоторые вполне конкретные решения, с которыми соотносится определенная область применения. Как правило, в проектах по реинжинирингу применятся некоторая комбинация таких методов, при этом каждый из них может стать частью методологии реинжиниринга ИС, но в отдельности таковой не является. Более того, объединение этих методов так же нельзя рассматривать в качестве методологии, поскольку между ними не определены связи, обеспечивающие их интегральную целостность.
Другими словами отсутствуют системообразующие факторы, делающие набор методов целостным образованием – системой.
С некоторой условностью все методы реинжиниринга ИС можно разделить на два класса.
Методы, относящиеся к первому классу, определены на концептуальном уровне и в целом не зависят от какой-то одной программной технологии. Так, в [2] дается обзор методов модернизации и миграции унаследованных систем. Среди всего множества рассматриваемых методов к первому классу относятся метод репликации баз данных и основанный на объектно-ориентированном подходе метод построения оболочек для компонентов унаследованной системы (object – oriented wrapping), методы «белого» и «черного» ящика модернизации системы. Другими представителями данного класса являются: методы оценки вариантов реинжиниринга ИС [9, 11, 33], метод планирования миграции программных средств [8], методы извлечения знаний о существующей системе [3, 4, 17], методы трансформации (реконструкции) архитектуры ИС [3, 7, 19, 21], методы автоматизации реинжиниринга программ [6, 23] и т.д. В целом следует считать, что область применения таких методов, как правило, характеризуется некоторым классом программных технологий. А для применения в реальных проектах каждый из них адаптируется с учетом используемых в проекте технологий и инструментальных средств.
Отдельным направлением исследований, относящимся к данному классу и получившим развитие в последние годы, является исследование и разработка образцов реинжиниринга ИС [26-30, 36]. Каждый из образцов реинжиниринга ИС нацелен на решение некоторой типовой задачи (проблемы), которая сопровождает деятельность по реинжинирингу ИС. Не смотря на некоторые отличия, авторы в целом придерживаются единого подхода к описанию таких образцов. Так, в [26] определяется следующий шаблон описания.
Стоит заметить, что хотя последний из разделов шаблона «привязывает» шаблон к определенной среде реализации, языкам программирования, все же каждый из образцов представляет некоторое концептуальное решение проблемы. Подробную информацию об образцах реинжиниринга можно найти в книге «Object-Oriented Reengineering Patterns» [27].
В отличие от первого класса, методы второго изначально ориентированы на использование определенных программных технологий. Ко второму классу относятся так же адаптации методов из первого класса. Здесь методы в наибольшей степени приспособлены к их непосредственному (прямому) применению в конкретных проектах. Примерами методов данного класса следует считать [2]: методы интеграции с использованием CGI, методы интеграции на основе технологии XML, метод построения оболочек для компонентов унаследованной системы с использованием технологии CORBA.
И наконец, четвертый уровень включает исследование и разработку инструментальных программных средств, автоматизирующих применение подходов, методов и технологий, рассматриваемых на предыдущих уровнях. Следует признать, что в настоящий момент таких средств существует большое количество, среди которого выделяются средства [3, 4, 6, 23, 31, 32, 35]:
Полезная классификация инструментальных средств дается в [31]. В рамках этой классификации выделяются такие типы средств, как
В этой же работе авторами приводятся характеристики инструментальных средств реинжиниринга ИС. Для каждого из них специфицируется имя программного продукта; требования к аппаратной и программной платформе; координаты компаний – поставщиков; поддерживаемые языки программирования, СУБД, платформы; принадлежность к тому или иному типу средств.
Осуществляя классификацию и исследование существующих подходов, методов и технологий реинжиниринга ИС, дополнительно к уже выделенным уровням, следует добавить еще два, являющихся по своей природе интегральными. Это уровень методологии и уровень технологии реинжиниринга ИС. Первый из них обеспечивает целостное рассмотрение и применение подходов и методов без учета среды их реализации, специфики конкретных проектов. Это соответствует интеграции первых трех уровней, причем на третьем уровне в сферу рассмотрения, в первую очередь, попадают методы первого класса. Уровень технологии обеспечивает адаптацию (конкретизацию) методологии реинжиниринга ИС с учетом среды реализации, специфики конкретных проектов посредством применения методов и инструментальных средств, соответствующих третьему и четвертому уровням. При этом в отличие от методологии, на третьем уровне, прежде всего, рассматриваются методы второго класса.
Следует признать, в процессе проводимых авторами настоящей статьи исследований не было обнаружено целостных методологий и технологий реинжиниринга ИС, соответствующих уровню проработки и области охвата RUP [24, 25]. В наибольшей степени эту проблема исследуется в [1, 8, 15, 33]. В тоже время, в [1] предлагается лишь каркас, определяющий основной ход работ, в [8] даются рекомендации по выполнению основных видов деятельности по реинжинирингу. В [33] определяются лишь процессы оценки унаследованных систем, а в [15] основное внимание уделяется вопросам технического характера, при этом основной акцент сделан на решение проблем интеграции систем, в то время как методы анализа унаследованной системы практически не рассматриваются.
Представленный подход к классификации обеспечивает систематизацию на множестве существующих подходов, методов и технологий реинжиниринга ИС. В качестве его основных областей применения следует рассматривать:
В завершении данного раздела стоит отметить, что возможны и другие полезные подходы к систематизации методов и технологий реинжиниринга ИС. Так, предлагаемые и исследуемые различными авторами процессы реинжиниринга, как правило, охватывают систему в целом, в то время как методы могут соотноситься с некоторыми ее составляющими, с отдельными шагами процесса. Последний факт обуславливает возможность классификация многих методов:
Основное содержание реинжиниринга ИС и его место в ЖЦ ИС.
Следующим шагом на пути исследования подходов, методов и технологий реинжиниринга ИС следует считать определение основного содержания деятельности по реинжинирингу ИС, места реинжиниринга в ЖЦ ИС.Так, в [1] авторы придерживаются следующей позиции при определении границ деятельности по реинжинирингу, и, как следствие, места реинжиниринга в ЖЦ ИС.
Утверждается, что реинжиниринг ИС занимает промежуточное местоположение по отношению к разработке и сопровождению ИС. При этом сопровождение ИС рассматривается как деятельность, предусматривающая выполнение изменений, направленных на коррекцию, усовершенствование и адаптацию ИС, а разработка ИС как деятельность, включающая реализацию новых возможностей, добавление новой функциональности, осуществление таких существенных улучшений, как переход на использование новых компьютеров, внедрение новых информационных технологий. Авторами правомерно утверждается, что реинжиниринг характеризуется деятельностью, как по сопровождению, так и по разработке ИС. При этом эти два вида деятельности в контексте реинжиниринга ИС могут существенно перекрываться.
В отличие от [1], работа [2] посвящена вопросам модернизации унаследованных информационных систем. В ней делается обзор различных методик модернизации унаследованных систем, определяется роль модернизации систем в процессе управлениях их эволюцией. Утверждается, что коммерческий рынок предлагает разнообразные решения проблемы модернизации унаследованных систем, которая становится все более актуальной. В сложившейся ситуации понимание преимуществ и слабых мест каждой такой методики является чрезвычайно важным, поскольку обуславливает выбор правильного решения, и как следствие успех деятельности по модернизации системы.
В контексте исследований, связанных с эволюцией ИС, авторами выделяются деятельности по сопровождению, модернизации и замещению ИС.
Определяется, что сопровождение представляет собой инкрементальный итеративный процесс, в рамках которого выполняются малые изменения в системе, не затрагивающие структурной организации системы (архитектуры системы).
В отличие от сопровождения модернизация характеризуется как деятельность, которая предусматривает значительные изменения существующей системы (в том числе в ее структуре), но не ее утилизацию или замещение новой системой.
И, наконец, замещение рассматривается как процесс, который заключается во внедрении новой системы, способной полностью заменить существующую ИС. Замещение обычно применяется к системам, которые недокументированны, устарели или не расширяемы, расходятся с требованиями бизнеса и для которых модернизация невозможна или экономически не выгодна.
Определяя место этих видов деятельности в контексте ЖЦ ИС, авторы рассматривают следующую последовательность их выполнения (см Рис. 1).
Рис. 1 Жизненный цикл ИС.
Первоначально, осуществляется разработка (построение) ИС. Далее выполняется деятельность по ее сопровождению. В процессе сопровождения возникает необходимость в реструктуризации системы и как следствие выполняется деятельность по ее модернизации. После этого снова осуществляется деятельность по сопровождению системы. В тот момент, когда ИС перестает удовлетворять заказчика, осуществляется ее замещение на новую систему и последовательность выполняемых видов деятельности повторяется. Безусловно, в реальной жизни может возникать и другая последовательность, когда, сразу, не прибегая к модернизации, осуществляется замещение одной ИС другой. Однако общий подход к последовательности выполнения сопровождения, модернизации и замещения останется неизменным.
Приводимые в [2] виды деятельности основаны на таксономии, вводимой в [16]. В отличие от предыдущей работы, в [16] в качестве базового понятия используется именно «реинжиниринг», а вводимая таксономия рассматривается как множество видов деятельности, соотносимых с реинжинирингом ИС. При этом применительно к унаследованным ИС выделяются соответственно деятельности по их оценке, сопровождению, трансформации, замещению, а так же смешанные стратегии, предусматривающие совместное выполнение перечисленных ранее видов деятельности.
Обеспечивая концептуальное понимание процесса реинжиниринга ИС, в ряде работ [1, 9] определяются основные виды деятельности (фазы) соотносимые с этим процессом.
Так, в [1] рассматриваются следующие основные фазы:
Другой подход к определению деятельности по реинжинирингу базируется на так называемой модели «подковы» [9, 21].
В основу данной модели положены следующие процессы (виды деятельности), соотносимые с реинжинирингом ИС:
Эти три основных процесса соединяются в модели в виде «подковы» (см Рис. 2).
Рис.2 Модель «подковы».
Первый процесс (Architecture Recovery) предусматривает восстановление архитектуры существующей системы посредством извлечения на основании исходного кода характеризующих ее артефактов. Полученная архитектура анализируется на предмет соответствия требованиям к изменяемости, надежности, защищенности и так далее.
Второй процесс (Architecture Transformation) заключается в трансформации (реинжиниринге) восстановленной архитектуры к желаемой новой архитектуре. Полученная в результате трансформации новая архитектура оценивается с позиции ее качества с учетом накладываемых на нее организационных и экономических ограничений.
И, наконец, третий процесс (Architecture-based Development) включает деятельность по разработке системы, соответствующей новой архитектуре. Здесь решаются вопросы декомпозиции элементов системы по пакетам, осуществляется выбор стратегий взаимодействия элементов/компонентов системы.
В рамках данного процесса так же обеспечивается интеграция в новую систему артефактов унаследованной системы, например, посредством переписывания части унаследованного кода и/или применения технологии построения оболочек для компонентов унаследованной системы.
С моделью «подкова» соотносится три уровня, на каждом из которых может осуществляться трансформация существующей системы.
Представление на уровне структуры кода (Code-Structure Representation) включает программный код, а так же такие артефакты, как абстрактные синтаксические деревья и графы потоков (flow graphs), получаемые на основании выполнения различного рода аналитических операций (например, разбора кода). Текстуальный перевод, а так же перевод на основе синтаксических деревьев являются примерами трансформации системы на этом уровне.
В отличие от предыдущего уровня, представление на уровне функциональности системы (Function-Level Representation) предусматривает определение связей между функциями программ (например, последовательности вызовов), данными (как частный случай, связей между сущностями данных, соотношений данных и функций) и файлами (к примеру, распределение функций и данных по файлам). Трансформация системы на данном уровне осуществляется на основании пересмотра функциональности системы и заключается, например, в переходе от функционального подхода к объектному подходу к анализу и проектированию, в переходе от реляционной БД к объектной БД.
На архитектурном уровне артефакты предыдущих уровней, объединяются в подсистемы в терминах архитектурных компонентов архитектуры ИС. Трансформация системы на этом уровне предусматривает коренные изменения в структуре программы, в том числе в части применения основных образцов взаимодействия компонентов: типов программных компонентов, используемых соединителей (connectors), вариантов декомпозиции функциональности, образцов управления и обмена данными времени выполнения.
Согласно модели «подкова» трансформация системы, в зависимости от ситуации, может осуществляться на каждом из представленных уровней, при этом более низкий уровень поддерживает трансформацию на более высоком уровне.
Следует признать, что модель «подкова» находит широкое применение в рамках деятельности, связанной с реинжинирингом ИС. Так, в [20] на ее основе определяются требования и основной каркас для интеграции инструментальных средств реинжиниринга на архитектурном уровне и уровне программного кода. С учетом соотносимых с ней процессов и уровней представления, осуществляется расширение модели CORUM (Common Object-based Reengineering Unified Model). Эта модель, в свою очередь, разрабатывалась:
В контексте вводимых расширений в этой же работе для модели «подкова» определяется семантическая модель, обеспечивающая на основании формулируемых унифицирующих свойств семантическую связь между архитектурным уровнем и уровнем программного кода.
Подход, предложенный в [34-36], очень близок к подходу, основанному на модели «подкова». Характеризуя жизненный цикл реинжиниринга ИС, авторы определяют следующие шаги процесса реинжиниринга:
В отличие от предыдущих работ, в [10, 13] деятельность по реинжинирингу рассматривается в качестве одной из форм деятельности по эволюции унаследованных ИС, когда, требуется более сильнодействующее «лекарство» для «лечения» ИС, нежели серия локальных инкрементальных изменений [13].
Так, в [13] описывается каркас (enterprise framework), характеризующий:
Авторами подчеркивается, что помимо технических вопросов, связанных с эволюцией унаследованных ИС, существует так же множество организационных вопросов. Например, «Как планировать эволюцию большой сложной системы, включая ее реинжиниринг?», «Какие существуют критичные факторы успеха эволюции системы?», «Как оценить, что люди, осуществляющие эволюцию системы, на правильном пути?». Кроме этого, важным является необходимость учета стратегических, организационных, и других аспектов бизнеса, влияющих на эволюцию унаследованной ИС.
Поэтому основной целью создания каркаса (enterprise framework) следует считать необходимость оценки среды, в рамках которой осуществляется эволюция унаследованной ИС, необходимость обеспечения понимания широкого спектра вопросов, как технического, так и управленческого характера, которые соотносятся с эволюцией унаследованных ИС. Важнейшим здесь становится выявление факторов, определяющих успех деятельности по эволюции ИС, а так же разработка согласованного множества технических и управленческих инструкций (действий), требуемых для эффективного планирования, оценки и управления инициативами по эволюции систем.
Отражая применительно к эволюции системы пространство проблем и пространство решений, предлагаемый в [13] каркас включает такие элементы, как организация, проект, унаследованная система, инженерия систем и программных средств, технологии, целевая система. Между этими элементами определяется связь. При этом для каждого из них приводится список вопросов (checklists), позволяющий охарактеризовать (исследовать и оценить) интересующий элемент.
Следует признать, что положенная в основу каркаса концепция является расширением концепции разработки ИС с учетом деятельности по внедрению, повседневных операций и деятельности по сопровождению.
Каркас может быть использован для выполнения следующих видов деятельности:
Общий подход к использованию каркаса представлен на Рис. 3.
Рис. 3 Общий подход к использованию каркаса.
В рамках подхода выделяются две значительные составляющие: основная фаза и фаза эволюции. Основная фаза сфокусирована на таких элементах, как организация, проект и унаследованная система. Фаза эволюции концентрируется на целевой системе, инженерии систем и программных средств, технологиях, используемых для построения целевой системы. Другими словами первая фаза сфокусирована на пространстве проблем, а вторая на пространстве решений.
В [10] авторами предлагается комплексный, основанный на рассмотренном ранее каркасе, подход к эволюции систем, который определяется в контексте унаследованных систем и современных программных технологий.
В основу подхода положены следующие положения (принципы):
Определяя различие между сопровождением программных средств и эволюцией систем в части реинжиниринга ИС, авторы рассматривают сопровождение как «мелкозернистую», «краткосрочную» деятельность, направленную на планирование и внесение локализованных изменений.
При сопровождении структура (архитектура) системы остается относительно неизменной, а требуемая «порция» вносимых за определенный промежуток изменений, как правило, связана с изменением какого-либо одного требования к системе. Такие изменения, обычно, не сопровождаются существенным изменением значений характеристик и атрибутов качества программных средств.
В отличие от сопровождения, эволюция систем рассматривается как «крупнозернистая», «высокоуровневая», форма изменений на уровне структуры (архитектуры) системы. Вносимые в процессе эволюции изменения, приводят к изменениям значений атрибутов качества, что, как правило, существенно упрощает сопровождение систем. Для этого при внесении изменений в структуру системы могут использоваться стратегии «снизу вверх» и «сверху вниз», применение которых основано на ревизии программного кода, восстановлении описания архитектуры унаследованной системы, проектировании новой структуры, новой формы документации и т.д.
Авторами подчеркивается, что эволюция позволяет адаптировать систему сразу с учетом большого количества выдвигаемых к ней требований (включая приобретение новых возможностей), что в конечном итоге увеличивает стратегическую и экономическую значимость программных средств. При этом акцент смещается от понимания программ к пониманию систем, от сопровождения к эволюции и миграции, от стратегий «снизу вверх» к стратегиям «сверху вниз».
В отличие от рассмотренных ранее работ, в [15] основное внимание уделяется исследованию и решению технических проблем, связанных с миграцией унаследованных систем. Характеризуя понятие «миграция ИС» в данной работе выделяются отдельно эволюция, сопровождение и миграция ИС. Основываясь на том факте, что объектом эволюции и сопровождения является унаследованная ИС, а объектом миграции как унаследованная, так и новая (целевая) системы, авторы разделяют миграцию и другие процессы ЖЦ ИС. При этом миграция рассматривается как деятельность, которая начинается с унаследованной ИС и заканчивается сопоставимой целевой ИС.
В основу предлагаемого авторами подхода положена декомпозиция структуры системы на компоненты пользовательского интерфейса, компоненты – приложения и компоненты управления базами данных. При этом в качестве основных инкрементально выполняемых шагов миграции выступают:
Понятие «реинжиниринга ИС», его содержание и место в ЖЦ ИС.
Существует ряд работ [1, 2, 5, 9, 10, 13, 15, 16, 20, 34-36], в которых в различной степени определяется соотносимая с реинжинирингом ИС деятельность, выявляется и исследуется место реинжиниринга в ЖЦ ИС.Понятие «реинжиниринга ИС».
Сразу следует признать, что в настоящий момент понятие «реинжиниринг ИС» не является повсеместно устоявшимся. Как следствие довольно часто возникает определенная терминологическая путаница. Авторами исследуются одни и те же проблемы, подходы, методы и технологии их решения, однако в качестве базовых понятий, наряду с «реинжинирингом ИС» [1, 9, 16, 20] употребляются «эволюция ИС» [10, 13], «миграция ИС» [15], «модернизация ИС» [2], «реструктуризация ИС» [5].Нельзя отрицать, что деятельность по миграции ИС имеет определенную специфику (окраску) по отношению к деятельности по модернизации ИС. Однако, принимая во внимание определение реинжиниринга ИС, приводимое в [1]:
«Реинжиниринг представляет собой систематическую трансформацию существующей системы с целью улучшения ее характеристик качества, поддерживаемой ею функциональности, понижения стоимости ее сопровождения, вероятности возникновения значимых для заказчика рисков, уменьшения сроков работ по сопровождению системы»,
становится очевидным, что и миграция, и модернизация ИС являются частью деятельности по реинжинирингу ИС. Как результат, подходы, методы и технологии миграции, модернизации, эволюции ИС, следует считать частью методологического и инструментально - технологического обеспечения процесса реинжиниринга ИС.
Такой взгляд на реинжиниринг ИС согласуется с таксономией, вводимой в ряде работ [34, 36, 38-40]. В этих работах авторами делается попытка выстроить систему понятий, соотносимых с данным видом деятельности. Так, в [38] реинжиниринг ИС определяется как «исследование (изучение, обследование) и перестройка исходной системы с целью ее воссоздания в новой форме с последующей реализацией этой новой формы. Далее, в контексте деятельности по реинжинирингу вводятся и определяются такие важные понятия, как
Перечисленные понятия раскрывают понятие «реинжиниринг ИС», а соотносимая с ними деятельность рассматривается либо как одна из форм реинжиниринга ИС, либо как подпроцесс процесса реинжиниринга. Определения этих и других понятий приводятся в приложении к данной статье в глоссарии понятий и терминов. При этом в тех случаях, когда проявлялись отличия в определении того или иного понятия, в глоссарий включались альтернативные варианты определения, а при необходимости, и поясняющие определение комментарии.
А. Глоссарий понятий и терминов.
Реинжиниринг бизнес-процессов (Business Process Reengineering) Фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность [40]. Рационализация имен данных (Data name rationalization (DNR)) Унификация именования данных, являющаяся специальным случаем реинжиниринга данных. Заключается во введении унифицирующих соглашений по именованию во всех программных системах [40]. Реинжиниринг данных (Data Reengineering) Выполнение всех функций реинжиниринга, соотносимых с исходным кодом, но применительно к файлам данных [40]. Восстановление результатов проектирования (Design recovery) Подмножество обратного инжиниринга, в котором знание проблемной области, внешняя информация, логические выводы или нечеткие суждения принимаются во внимание при обследовании исходной системы. Целью восстановления результатов проектирования является выявление значимых высокоуровневых абстракций, в дополнение к тем, которые были получены в процессе непосредственного исследования (изучения) системы [38]. Прямой инжиниринг (Forward engineering) Традиционный процесс перехода от высокоуровневых абстракций и логического, независящего от реализации проектирования к физической реализации системы [38]. Представляет собой переход от требований к высокоуровневому проектированию, и далее к низкоуровневому проектированию и реализации [36]. Представляет собой множество видов деятельности по инжинирингу системы, на вход которым для производства новой целевой системы поступают продукты и артефакты, производные от унаследованных программных средств, и новые требования [40]. КомментарийОсновное отличие прямого инжиниринга от реинжиниринга заключается в том, что в случае реинжиниринга «стартуют» от существующей реализации (существующей системы). Основное отличие прямого инжиниринга от инжиниринга в целом заключается в том, что на вход прямого инжиниринга поступают результаты реинжиниринга [40].
Процесс извлечения информации из существующей программной системы [36]. В общем случае обратное проектирование применяют для извлечения информации на высоком уровне абстракции, например информации уровня проектированию на основе программного кода. Сопровождение программных продуктов (Software maintenance) Модификация программного продукта после его поставки в целях исправления ошибок, улучшения производительности и других атрибутов качества, или адаптации продукта к изменениям окружения (внешней среды) [39]. Трансляция исходного кода (Source Code Translation) Трансляция исходного кода с одного языка программирования на другой или с одной версии в другую на том же самом языке программирования [40]. Инжиниринг систем (Systems Engineering) Высокоуровневый процесс инжинирии систем, направленный на достижение соответствия системы всем выдвигаемым к ней требованиям [40].
Далее в настоящей работе при исследовании существующих решений употребляется оригинальная терминология, предлагаемая авторами работ. При этом в качестве рабочего варианта используется определение реинжиниринга ИС, приводимое в [1].
в различных организациях позволяют сделать
Результаты исследований состояния информатизации в различных организациях позволяют сделать вывод, что в настоящий момент большинство из них уже имеет некоторые информационные системы (ИС). Эти ИС в различной степени автоматизируют процессы, протекающие в организациях.Исследования проектов информатизации, и, в первую очередь, проектов разработки ИС так же показывают, что создание новой информационной системы в большинстве случаев предусматривает изменение состояния существующих ИС. Типичными стали проекты:
По сути, сегодня можно говорить, что эра, когда разработчики ИС приходили в организацию и начинали проекты информатизации «с нуля», прошла. Наступает время проектов по систематической трансформации существующих ИС или эра реинжиниринга ИС.
Следствием сложившейся ситуации становится объективная потребность в исследовании, пересмотре и переосмыслении существующих подходов, методологий и технологий разработки ИС, что, в свою очередь, может потребовать их модернизации, а возможно, и разработки новых решений.
Ситуация осложняется тем, что в настоящий момент различными исследователями и практиками понятие реинжиниринга ИС трактуется по разному. Во многом это обусловлено необычайно широким спектром задач по реинжинирингу, с которыми приходится сталкиваться в реальных проектах.
Сегодня в мире существует большое количество подходов, методов и технологических решений, напрямую или косвенно соотносимых с деятельностью по реинжинирингу ИС. Однако они не интегрированы на уровне методологий (процессов разработки). Как результат, можно наблюдать наличие огромного количества методологий, где основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие «стройных» методологий, целью создания которых являлось бы комплексное, целостное решение задач реинжиниринга ИС.
В настоящей статье исследуются существующие подходы, методы и технологии реинжиниринга ИС, предлагается подход к их классификации. На основании результатов исследований и вводимой классификации дается оценка текущего состояния в данной области.
Заметим, что в процессе написания статьи не ставилась цель исследовать все решения в области реинжиниринга ИС, представить детальную информацию по каждому из них. В то же время авторами была предпринята попытка рассмотреть основные подходы, методы, технологии и инструментальные средства, которые характеризуют состояние дел в данной области. Детальную информацию об интересующих решениях можно найти в литературе, ссылки на которую представлены в конце статьи, а так же на следующих Web – сайтах:
и вводимой классификации подходов, методов
На основании проведенных исследований и вводимой классификации подходов, методов и технологий реинжиниринга ИС, становится возможным охарактеризовать текущее состояние в области его методологического и технологического обеспечения.Так, несмотря на наличие большого количества работ, охватывающих данную проблематику с различных точек зрения, следует признать, что:
В сложившейся ситуации актуальной задачами становятся:
Designing for FAILURE - ключ к успеху?Беседа с Брюсом Линдсеем
Прокомментировать>>Перевод: Сергей Кузнецов
Оригинал: A Conversation with Bruce Lindsay, ACM Queue, Vol. 2, No. 8 - November 2004.
Брюс Линдсей – это одна из легендарных фигур в истории баз данных. Он появился в IBM на закате проекта System R, и сразу привлек внимание в качестве соавтора многих замечательных статей. Но, прежде всего, он системный архитектор и программист. Именно под его архитектурным руководством был выполнен один из наиболее интересных проектов в области баз данных Starburst. В предлагаемом вашему вниманию интервью он говорит, в основном, не о базах данных, хотя все время имеет их в виду. Он говорит о том, как следует разрабатывать программные системы, чтобы добиться их общей надежности в условиях ненадежности компонентов, программистов, языков программирования и окружающей среды. Замечательно, что это интервью у Линдсея брал не менее легендарный персонаж из истории операционной систем Unix Стив Борн, создавший первый язык и интерпретатор Shell. Приятного и полезного вам чтения. Сергей Кузнецов
В конце 1980-х гг. он участвовал в разработке протокола DRDA (Distributed Relational Database Architecture, архитектура распределенной реляционной базы данных), а позже являлся главным архитектором Starburst, расширяемой системы баз данных, которая со временем превратилась в оптимизатор запросов и интерпретатор для DB2 на платформах Unix, Windows и Linux.
Линдсей разработал концепцию экстендеров баз данных, в которых мультимедийные данные – изображения, голосовые и видеоданные – трактуются как объекты, являющиеся расширениями стандартной реляционной базы данных, и эти данные можно запрашивать с использованием стандартного SQL (Structured Query Language). Сегодня он по-прежнему глубоко погружен в работу в лаборатории управления данными в Исследовательском центре IBM в Алмаден, участвуя в создании продуктов управления данными следующего поколения.
Стив Борн: Почему бы нам не начать с той мысли, что нельзя избавиться от ошибки, пока ее не обнаружишь?
Брюс Линдсей: Давайте немного поразмышляем над тем, как возникают ошибки. Они возникают на всех уровнях системы, и их причины могут простираться от воздействия альфа-частиц, разряжающих конденсаторы основной памяти, до пожаров, наводнений или террористических актов, разрушающих вычислительные системы целиком. Все делается неправильно, начиная с грубых промахов в логике программирования и заканчивая данными, поступающими не с того сектора диска. Нужно производить разработку систем с учетом возможности отказов на всех возможных уровнях системы, от уровня электронных схем до уровня подсистем, таких как СУБД или файловая система, и даже до уровня самих прикладных программ.
«Engineering for failure (разработка с учетом возможности отказа)» – это, возможно, плохое выражение, но в действительности это именно то, что требуется для обеспечения надежной и заслуживающей доверия обработки информации.
СБ: Безусловно верно, что при написании кода и разработке систем в голове должна сидеть мысль: «А что здесь может поломаться?». Причин может быть множество, и возможные линии поведения зависят от типа приложения или программного обеспечения. При написании программы типа Microsoft Word они совсем не те, что при разработке кардиомонитора.
БЛ: В случае кардиомонитора вы обязаны поддерживать работу сердца, а в случае Microsoft Word можно всего лишь выдать пользователям «синий» экран, к которому все привыкли.
СБ: Но в случае кардиомонитора вряд ли разумно спрашивать пользователей, хотят ли они поддерживать работу сердца, поскольку ответ очевиден, а в случае Word иногда стоило бы спросить пользователей, как поступать в создавшейся ситуации.
БЛ: Иногда можно спрашивать пользователя, хотя лучше было бы спросить подсистему, что она собирается сделать для самовосстановления, или прекратить ее работу в зависимости от ситуации.
СБ: Вы действительно противопоставляете отказы системы ошибкам пользователей?
БЛ: Я не считаю «отказами» ошибки пользователей, такие как ввод неверных данных. Это нормальное явление. Вряд ли неправильное написание go to вызовет ошибку в работе компилятора. Такие вещи являются ожидаемыми.
СБ: Что же такое, по Вашему мнению, ошибка?
БЛ: Ошибка возникает в каждом случае, когда некоторый используемый компонент не выдает ожидаемого результата, будь то обращение к основной памяти, которое не может быть выполнено из-за проблем с контролем четности, безрезультатный обмен данными с диском или вызов подпрограммы, в которой возникает исключительная ситуация. «Меня попросили выполнить действие X, а я этого не сделал.»
Хороший принцип разработки состоит в следующем: либо делайте то, что вас просят, либо говорите, что вы это делать не будете, и объясняйте причину, но не делайте ничего другого.
СБ: Я думаю, что имеется еще один вариант: «Я этого делать не буду, так что выясните, нет ли какого-то другого способа получить ответ на интересующий вас вопрос или выполнить требуемую вам функцию». Это ситуация с несколькими возможностями выбора.
БЛ: Ну конечно, так всегда и происходит. Например, функция состоит в том, чтобы зарегистрировать некоторый UserID, и выясняется, что мы пытаемся зарегистрировать UserID, который уже зарегистрирован. На уровне выше уровня регистрации требуется принять решение о том, что делать дальше. На этом уровне можно сказать: «Пардон, но в нашей системе может быть только один Брюс, и вас мы в нее никогда не впустим. Пожалуйте прочь» или «А не смените ли вы свое имя на Стив?».
СБ: А как Вы учитываете возможности отказов при разработке системы, а не одиночного приложения, когда система может быть достаточно крупной и сложной, и ей свойственны проблемы масштабируемости?
БЛ: Конечно, здесь нужно придерживаться позиции врача: не навреди в случае отказа. Другими словами, не следует предпринимать опрометчивых действий при отсутствии уверенности в их правильности. По другому это называется «быстрым выявлением сбоев» (fail fast), а я здесь имею в виду системы, в которых, большей частью, поддерживается персистентное состояние. Может оказаться очень опасным продолжать работу системы при отсутствии понимания сути сбоя. Поэтому достаточно успешной является идея быстрого выявления сбоев и склейки согласованного состояния системы на основе тщательно поддерживаемых резервных данных.
В близкой мне области систем баз данных можно много говорить о красоте моделей данных, об их мощности, о работоспособности систем, о простоте написания приложений, о возможности хранения огромных объемов данных и прочих подобных вещах, но на практике успешность этих систем определяется их надежностью. Пока системы не обрели достаточную для приобретения доверия пользователей способность надежно поддерживать данные, не допускать их потери, никто не решался доверить этим системам обработку критически важных данных.
Подход, используемый в этих системах, по существу, состоит в поддержке двух копий данных. Одна из них называется журналом восстановления, и он является подлинной копией данных. В нем содержатся записи обо всем, что происходило, в хронологическом порядке. Кроме того, имеется представление базы данных, оптимизированное для доступа и обновления «текущих данных».
Возможность систем баз данных сохранять последнее зафиксированное состояние данных, не взирая на сбои процессора, системы хранения и коммуникаций, объединенная с важными принципами транзакционности, атомарности и долговечности, придает этим системам надежность, достаточную для того, чтобы люди доверяли им поддержку критической информации. При отсутствии подобной надежности информация могла бы утратиться или исказиться.
СБ: Здесь стоило бы прояснить, какие методы используются для обнаружения ошибок.
БЛ: Обработка сбойных ситуаций всегда начинается с обнаружения сбоя – чаще всего путем использования в системе какой-либо разновидности избыточных средств, будь то биты четности или «санитарная проверка» (sanity check) в коде программы, когда 10% строк кода тратятся на проверку согласованности состояния с целью выявления того, не следует ли заняться обработкой ошибок. Таймауты, строго говоря, не являются избыточным средством, но это еще один способ выявления ошибок.
Здесь важной мыслью является то, что если вы отправляетесь в морское путешествие, имея только одни часы, то вы не можете сказать, показывают ли они правильное время. Требуется какой-то способ проверки. Например, при чтении сообщения, поступающего по сети, чтобы удостовериться в том, что ожидается именно это сообщение, можно проверить некоторые биты в заголовке сообщения и сказать: «Ага, кажется, можно продолжать работать».
Или, если вы производите чтение с диска, можно проверить метку дискового блока, чтобы удостовериться, что это именно тот блок, который запрашивался. В состоянии системы всегда имеется некоторая избыточность, позволяющая обнаружить появление ошибки.
Если не задумываться о возможности сбоев, то зачем помещать в блок диска адрес самого этого блока?
СБ: Значит, на самом деле Вы стараетесь убедиться в том, что понимаете то, что происходит в системе?
БЛ: По большому счету это именно так. И еще я стараюсь проверить то, что данные или состояние, над которыми требуется производить дальнейшую работу, являются самосогласованными.
СБ: Имеется ли какая-нибудь языковая поддержка обнаружения ошибок?
БЛ: По сути, языковая поддержка обнаружения ошибок отсутствует. В языках имеются средства обработки уже обнаруженных ошибок. Генерация исключительной ситуации средствами языка программирования – это нечто, что делается в соответствии с логикой программы.
Например, в скриптовых языках имеется очень ограниченная синтаксическая и семантическая поддержка исключительных ситуаций. И, в конечном счете, большую часть того, что предоставляется в языках, можно было бы закодировать самостоятельно.
В языках имеются некоторые довольно опасные возможности – в частности, инициирование ошибки (raise error) или исключительной ситуации, а также обработчики исключений. Как это соотносится со стеком вызовов процедур? В ранних подходах к языковой поддержке обработки ошибок стек сокращался без совершения каких-либо дополнительных действий, пока не достигался некоторый уровень, на котором было объявлено нечто, представляющее интерес для обработки данной исключительной ситуации, т.е. ошибки.
Вообще говоря, свертывание вызова процедуры или подпрограммы – вызова метода – без устранения беспорядка, который мог уже образоваться, т.е. частично произведенного этой функцией преобразования состояния, является очень опасным. Например, если имелись запросы динамической памяти, а соответствующий участок стека просто сокращается, запрошенная память так и не будет возвращена.
Поэтому очень важно дать каждому вызову процедуры возможность «аккуратно сложить свою палатку», даже если эти действия не имеют отношения к обрабатываемому исключению.
СБ: Да, похоже, что людям нужно не забывать про такие вещи, как динамическое распределение памяти. Я не знаю, имеются ли в связи с этим какие-нибудь хорошие правила? Есть ли у Вас какие-нибудь еще соображения по этому поводу?
БЛ: Ну, конечно, множество грехов в этой области покрывается сборкой мусора. Полезны также автоматические вызовы деструкторов C++ для объектов, состояние которых сохраняется в стековом фрейме. Хотя сборка мусора порождает некоторые серьезные проблемы производительности, особенно в многопотоковых приложениях, она способствует устранению ошибок, ведущих к потере памяти, а такие ошибки чрезвычайно трудно изолировать.
СБ: Кажется, что в некоторых современных языках проблема восстановления после возникновения ошибок, по крайней мере, принимается во внимание. Например, некоторые средства имеются в языке Python. По моему мнению, хорошо уже то, что люди начали думать об этой проблеме и пытаться оснащать языки соответствующими возможностями. Не знаю, насколько правильно они ее понимают.
БЛ: Хорошо, что люди начинают об этом задумываться хотя бы из-за того, что появляются новые языковые средства, побуждающие их к раздумьям о восстановлении после проявления ошибок. Но ни в каком языке нет волшебных возможностей, которые могли бы нас спасти. Все равно нужно думать о причинах того, что вызываемая процедура может не вернуть ожидаемые результаты, и о том, что можно сделать в этой ситуации.
СБ: Предположим, нам удалось обнаружить ошибку, и что следует делать далее? Можно проинформировать кого-то об этом, но встает вопрос: кого и о чем следует информировать?
БЛ: Имеются две разновидности обнаружения ошибок. В первом случае я смотрю на собственные внутренности и вижу, что они выглядят неправильно, и тогда я говорю, что возникла ошибочная ситуация. Во втором случае я вызываю некоторый другой компонент, который не делает то, что требуется. В обоих случаях я сталкиваюсь с обнаруженной ошибкой. Прежде всего, нужно «свернуть свою палатку», т.е.
восстановить состояние таким образом, чтобы управляемое тобой состояние стало согласованным. После этого нужно проинформировать ту штуку, которая тебя вызывала, возможно, выдав попутно некоторые дампы, или же можно попытаться использовать резервную логику для обхода ошибочной ситуации.
В наших проектах из области баз данных информация об ошибочной ситуации обычно передается все выше и выше по цепочке вызовов, пока на каком-то очень высоком уровне не будет сказано: «Да, дела действительно плохи. Пора производить массивный дамп памяти». При информировании об ошибке следует ее классифицировать. Следует присвоить ей имя. В каждом компоненте, информирующем об ошибках, должен иметься исчерпывающий список ошибок, информация о которых может передаваться этим компонентом.
В этом состоит одна из реальных проблем архитектуры сегодняшних языков программирования в части обработки исключительных ситуаций. В каждом компоненте должны регистрироваться все исключительные ситуации, которые могут быть возбуждены: обычно, если я вас вызываю, и вы говорите, что возбуждаете исключения A, B и C, а сами можете вызвать Джо, который возбуждает исключения D, E и F, а вы эти исключения игнорируете, то я неожиданно сталкиваюсь на своем уровне с D, E и F, хотя в вашем интерфейсе ничего не говорилось, что от вас могут исходить ошибки D, E и F. Это явление повсеместно распространено в программировании и языковых средствах. От вас никогда не требуется гарантия того, что вы объявили все ошибки, которые могут проистекать от вызова вашей подпрограммы. И поэтому разрешается игнорировать ошибки. Иногда я высказываюсь в пользу того, чтобы не разрешать игнорировать никакие ошибки. Можно изменить классификацию ошибки и передать информацию о ней на более высокий уровень, но ты не должен разрывать цепочку.
СБ: Системе точно не известно, которую информацию следует сообщать, а кому-нибудь может совсем не захотеться оказаться в ситуации, в которой придется пробираться сквозь 20 мегабайт данных, чтобы что-нибудь найти.
БЛ: В случае систем баз данных мы все более и более склоняемся к консервативному дампингу – т.е. к включению в дамп всего, что может представлять интерес. Это делается на основании того, что при наличии какого-либо используемого приложения, если при работе какого-либо производственного приложения приходится столкнуться с гейзенбагом, который трудно воспроизвести, часто бывает трудно заставить пользователей еще раз специальным образом запустить приложение, говоря примерно следующее: «Привет! Мне хотелось бы еще раз поломать вашу систему, хотя у меня имеются собственные средства для отслеживания того, что происходит».
Обычно они отвечают так: «Что? Оно же сейчас работает. Оно работает уже шесть часов. Да, эта проблема возникает раз в неделю, и нас это довольно-таки раздражает. Устраните ее, наконец. Но мы не собираемся ломать систему для вашего удовольствия».
Поэтому мы включаем в дамп все больше и больше информации. Мы не включаем в дамп саму базу данных, но если обнаруживаем подозрительную страницу, то, безусловно, направляем в дамп все ее содержимое – почти поразрядно – для возможного анализа. Слишком большой объем дампа – это не такая плохая вещь в нашей области, если приходится обслуживать эксплуатируемый код, и вам не позволительно сказать: «Привет, устройте-ка для меня еще разочек аварийный отказ вашей системы».
СБ: Когда дела идут плохо, и вы решаете выдавать дамп всего, что приходит в голову, вам могут задать вопрос: «А не лучше ли было бы узнать, что происходило в нужном месте в нужное время?» вместо того, чтобы получить дамп стека и стараться выяснить все на основе этих фотографий? Похоже, что вам нужен фильм, а не фотографии.
БЛ: Ну, конечно, если включить трассировку, то получится фильм, но опять же для этого требуется специальная возможность, и это обычно делается в центрах разработки. Часто именно с этого начинают разработчики, если ошибка является воспроизводимой, и они могут смотреть на все дампы.
Они воспроизводят ошибку при наличии подключенного к системе микроскопа и анализируют дампы трассировки – вот и получается кино.
СБ: Когда Вы разрабатываете код с учетом возможности сбоев, думаете ли Вы о ситуациях, информацию о которых следует зафиксировать, поскольку это может помочь при возможном поиске ошибки?
БЛ: Бывает так, что при раскрытии основной причины ошибки производится модификация подпрограмм построения дампа с целью включения в дамп дополнительной информации, которая помогает улучшить процесс раскрытия проблемы.
СБ: Было бы интересно поговорить о файловых системах и журналах и узнать вашу точку зрения по поводу того, насколько далеко мы ушли от прошлого, в котором имелась утилита fsck (file system check) для восстановления файловой системы после ее отказов.
БЛ: Я думаю, что в файловых системах произошла настоящая революция, когда при восстановлении после аварийного сбоя вместо сканирования диска или применения fsck стала использоваться мотивированная и инспирированная технологией баз данных система журнализации, которая журнализует изменения метаданных и затем в фоновом режиме записывает эти изменения на диск.
Здесь имеются два полезных эффекта. Один из них состоит в том, что журнал можно писать с применением высокопроизводительного устройства внешней памяти, а изменения метаданных, представленные записями в журнале, можно в отложенном режиме записывать в основную область хранения файловой системы в более позднее время, не обязательно совмещая это действие с выполнением пользовательского запроса. Кроме того, журнализация намного убыстряет восстановление файловых систем во время их перезапуска после аварийного сбоя, поскольку повторному выполнению или двойному контролю подлежат только самые последние изменения.
СБ: Давайте рассмотрим пример разработки системы, допускающей ухудшение эксплуатационных характеристик (graceful degradation). В системе Sabre, предназначенной для резервирования авиабилетов, допускается наличие дубликатов записи о бронировании (около одного дубликата на тысячу записей), поскольку оказалось, что наличие записей-дубликатов о бронировании не является слишком существенным.
Рано или поздно кто-нибудь обнаруживает наличие дубликатов и что- нибудь предпринимает. Эта система не является черно-белой. У нее имеются нечеткие границы (fuzzy edge), и в ней допускается наличие некоторых несогласованностей, потому что имеются свои способы восстановления согласованности.
БЛ: На всех уровнях системы наблюдаются деградирующие операции, начиная от систем основной памяти, в которых можно просто удалить неисправную микросхему и больше ее не использовать – следует надеяться, что это делается после восстановления состояния памяти с использованием избыточного кода с исправлением ошибок, до общесистемных явлений, когда в случае отказа системы можно перезапустить ее на резервной аппаратуре, которая, возможно, уже была частично задействована. В этих случаях имеется деградация производительности.
Вы подвергаете избыточной нагрузке одну систему, потому что другая система вышла из строя, и вы допускаете наличие пониженной производительности, пока не будет починена первая система.
Аналогично, в избыточных системах хранения на основе дисковых массивов во время восстановления вышедшего из строя диска мы наблюдаем снижение производительности при доступе к данным, которые раньше хранились на этом диске, поскольку эти данные должны воссоздаваться на основе данных, хранящихся в других блоках массива.
Так что временное ухудшение эксплуатационных характеристик наблюдается на всех уровнях системы.
Нужно вести себя очень осторожно в случае деградаций, при которых результат, возвращаемый системой, может быть каким-то образом дискредитирован. Примером может быть приложение по бронированию авиабилетов, о потере в котором записи о бронировании вы узнаете позже от клиента. Здесь требуется серьезная проверка на уровне проектирования системы, которая должна помочь ответить на вопросы: «Допустимо ли это для приложения, для внедрения этой системы?». Безусловно, мы сталкиваемся с этим в среде Web. Если полностью проигнорировать один запрос к Web-сайту из ста, ничего страшного не произойдет.
Пользователь нажмет на клавишу «refresh» своего браузера, и запрос будет обработан со второй попытки. Но если игнорировать 100% запросов в течение хотя бы нескольких минут, то известие об этом попадет в New York Times.
Так что мы видим, что решение о том, как реагировать на ошибки – не выдавать ли ответ вообще или выдавать частичный ответ, в действительности зависит от того, для чего будет использоваться этот ответ, и какова будет реакция клиента на неправильный ответ или отсутствие ответа.
СБ: Что Вы можете сказать относительно связи между отладкой системы и обнаружением ошибок и восстановлением системы после их проявления?
БЛ: Имеется две обширных категории сообщений об ошибках. Сообщения первой категории означают, что система предвидела данную проблему, например, попытку регистрации пользователя с уже использующимся в системе именем или выход значения параметра за пределы допустимого диапазона, а теперь сообщает вам, что эта проблема действительно возникла. Большинство систем с этим справляется плохо. Получаемые пользователями сообщения об ошибках в лучшем случае являются непонятными, а в худшем – вводящими в заблуждение. Это является результатом ряда проблем. Одна из них заключается в том, что во многих средах разработки программного обеспечения имеется отдельная небольшая подсистема, предназначенная для поддержки сообщений об ошибках. Для создания нового сообщения об ошибке нужно потратить полчаса на ввод сообщения об ошибке, нужно убедиться в том, что это сообщение является пригодным для перевода на национальные языки, и нужно присвоить ему код ошибки, отличный от тех, которые уже были выделены для других сообщений об ошибках. Чтобы избежать этой работы, многие люди повторно используют старые сообщения об ошибках, говоря, что данная ошибка похожа на ту, которая уже зарегистрирована в системе, и что можно использовать существующее сообщение.
Программистская лень приводит к отсутствию конкретности в сообщениях об ошибках.
Если можно сделать выбор между непараметризуемым сообщением, в котором просто констатируется факт ошибки, и намного более сложным параметризуемым сообщением, для которого нужно написать 15 строк кода, то программисты однозначно выбирают первый вариант.
Я думаю, что компании, занимающиеся разработкой программного обеспечения, недостаточно стимулируют правильную и точную формулировку сообщений об ошибках (и в компаниях, производящих аппаратуру, дела обстоят не намного лучше).
СБ: Когда вы производите сообщение об ошибке, вы должны знать, для кого оно предназначено, и что эти люди знают о происходящем в системе. Насколько принято испытывать сообщения об ошибках с привлечением сообщества пользователей? Мне кажется, что очень конструктивной была бы обратная связь.
БЛ: Зачастую текст сообщения об ошибке формулируется разработчиком, погруженным во внутренности системы, такой текст, очевидно, не отвечает потребностям конечных пользователей. Как я уже говорил, такие тексты являются недостаточно конкретными.
Но пока разговор шел про первую категорию сообщений об ошибках, т.е. тех, для которых достаточно понятна связь между данными, вводимыми пользователем, и соответствующей ошибкой. Сообщения об ошибках второй категории выдаются в тех случаях, когда система понимает, что она повреждена. В таких случаях сообщения в действительности совсем не рассчитаны на конечных пользователей и часто вообще ничего не говорят им. Подобные сообщения выглядят примерно так: «Оператор не может быть выполнен. Попробуйте выполнить другой оператор».
По существу, это сообщение является признанием системы, что в ней имеется ошибка, и в данный момент для исправления этой ошибки – неважно, программный это сбой или аппаратный – требуется гораздо больше информации. Выдача полного дампа бесполезна для бедного конечного пользователя.
Поэтому в большинстве серьезных систем – аппаратных и программных – поддерживаются наборы данных журнализации ошибок, и при возникновении ошибок подобного рода система сбрасывает в эти наборы данных дамп, содержащий массу информации о деталях состояния системы, которые могли привести к ошибке, и о действиях системы во время проявления ошибки.
СБ: Что такое гейзенбаги?
БЛ: Этот термин родился в моем присутствии. Гейзенбагами называются ошибки (баги), которые явным образом демонстрируют некорректное поведение системы, но такие, что при попытке разобраться в причинах этой некорректности проблема исчезает. Обычно для того чтобы можно было разобраться в причинах некорректности, включается трассировка, или добавляются дополнительные параметры, или что-то изменяется. И из-за этих изменений проблема исчезает. Довольно часто подобные проблемы проявляются в связи с параллельной работой программ. Или же они могут проявляться в зависимости от конкретного способа размещения программ и данных в основной памяти.
Так что настоящее определение гейзенбага состоит в следующем: когда вы смотрите на эту ошибку, она исчезает – с уважением к доктору [Вернеру] Гейзенбергу, который говорил: «Чем более пристально вы смотрите на что-то одно, тем менее отчетливо можете увидеть что-либо иное».
СБ: Я думаю, что хорошо, когда случается нечто, представляющее известную реальную неполадку, поскольку обычно это означает, что неисправность возникла на более низком уровне системы – при распределении памяти или выполнении каких-то других подобных действий.
БЛ: Такие ошибки очень трудно находить, но, конечно, чем труднее ошибка, тем больше удовольствия доставляет ее обнаружение.
СБ: Как происходит обнаружение ошибок и восстановление после их проявления в распределенных системах, которые по своей природе обладают высоким уровнем параллелизма и включают массу слабо связанных компонентов?
БЛ: Распределенные системы разбиваются на две обширные категории. В первой категории одна система использует другую систему для выполнения некоторых функций. Здесь первая система зависит от возможности второй системы выполнять эти функции. Примером такого зависимого использования являются Web-сервисы. Во второй категории распределенные машины совместно обеспечивают некоторый единый сервис. Примером могут служить распределенные файловые системы.
Наибольшее внимание уделяется возможности восстановления после сбоев и надежности систем второй категории, поскольку идея таких распределенных систем часто состоит в том, что функциональные возможности системы может обеспечить любой сервер – нужно всего лишь найти тот из них, который исправен и функционирует, а также участвует в данной игре. Но поскольку эти серверы поддерживают распределенное состояние, имеется громадная проблема выяснения того, кто участвует в игре. Имеются алгоритмы группового консенсуса. Имеется важная теорема, в которой говорится, что при наличии нормальных условий передачи сообщения – или при наличии предельных условий передачи сообщений – в локальной системе невозможно определить, произошел ли сбой другой локальной системы, или она просто медленно работает, или же имеет место сбой исходной локальной системы, т.е. она лишена возможности коммуникации.
Эти алгоритмы можно практически реализовать. Имеется много хороших алгоритмов. Выполнение таких алгоритмов обходится не очень дешево, но их можно использовать для поддержки списка работающих серверов и информирования каждого сервера обо всех других работающих серверах, поскольку, вообще говоря, в поддержке распределенного состояния должны участвовать все работающие серверы.
СБ: Одним из интересных аспектов здесь является соотношение между временем, требуемым на обнаружение чего-либо, и временем, которое приходится затрачивать на реальное восстановление системы.
БЛ: А также, что значит удалить отказавший компонент, поскольку здесь имеется проблема расщепления разума (split brain problem), когда я думаю, что отсутствуете вы, а вы считаете, что отсутствую я? Кто несет ответственность?
СБ: Ну да, и пока они спорят об этом, ничего не происходит.
БЛ: Такое возможно, хотя некоторые из этих систем могут продолжать обслуживание. Редко бывает так, что для выполнения одиночного действия в распределенной системе требовалось участие всех активных партнеров.
Имеется также проблема вывода из игры неисправных партнеров.
Если нас всего пятеро, и четверо считают, что пятый мертв, то для гарантии того, что он мертв, стоит выпустить в него еще три пули.
Мы встречаемся с этим, в частности, в области совместного управления дисками, где имеются два процессора, две системы, подсоединенные к одной и той же дисковой подсистеме. Проблема состоит в том, что если одна система принимает на себя управление дисковой памятью вместо другой системы, то первой системе лучше вообще не пользоваться дисковой подсистемой. Мы пытаемся найти архитектурные средства в дисковых подсистемах для вытеснения участников – так называемые ограждающие средства.
Если я думаю, что вы мертвы, и хочу взять на себя управление внешней памятью и ответственность за это, то, прежде всего, мне захочется сказать дисковой подсистеме, чтобы она не обращала на вас внимания, поскольку теперь за все отвечаю я. Если у вас возникнет возможность продолжать использовать дисковую подсистему, в то время как я блаженно верую, что единолично за нее отвечаю, то могут произойти ужасные вещи.
Имеются два аспекта совместной работы в распределенных системах. Один из них состоит в выявлении участников игры, а другой – в том, что если кто-то считается выбывшим из игры, то необходимо каким-то образом абсолютно убедиться, что он действительно больше не играет.
СБ: Обнаружение ошибок и восстановление затруднительны в многопотоковых приложениях. Значит ли это, что не следует создавать многопотоковые системы?
БЛ: Я думаю, что нам нужно разрабатывать многопотоковые системы, но это трудное дело. Я обычно говорил людям: «Если вы не занимались созданием многопроцессного кода в течение пяти лет, то у вас нет квалификации, достаточной для написания такого кода». А потом я понял, что, пока я придерживаюсь такой позиции, никто не собирается меня заменять. Поэтому я стараюсь помогать людям в понимании того, как следует писать многопроцессный код. Имеется куча методов, но в основном необходима синхронизация критических участков и масса проверок.
Преимущества мультипроцессного кода и использования разделяемой памяти настолько неотразимы, что нам приходится делать это.
СБ: Мне кажется, что состояние дел в области обнаружения ошибок и восстановления не слишком изменилось за последние 20 лет.
БЛ: Одной из вещей, которые мы теперь понимаем немного лучше, является так называемая область действия ошибки (scope of the error). Испортила ли ошибка только одну функцию? Вы вызываете эту функцию, а она не работает. Она говорит: «Я сломалась, возврат». В этот момент областью действия ошибки является эта функция. Конечно, если вы делаете возврат, если вы возбуждаете исключительную ситуацию, то область действия ошибки расширяется. Вы должны решить, ограничена ли область действия ошибки данным потоком управления. Если ошибка проявляется вне каких-либо манипуляций с разделяемыми данными, вы можете сказать: «Может быть, если мы всего лишь ликвидируем этот поток управления, то остальные потоки смогут продолжать работать, а может быть, мы даже сможем перезапустить этот поток управления, и в следующий раз его судьба окажется более удачной».
СБ: А как это представляется в коде?
БЛ: Обычно посредством механизмов управления потоками, которые требуются при написании любого многопотокового приложения. Поток может закончиться, и тогда менеджер потоков скажет: «О, этот поток относился к такому виду потоков, которые нужно перезапускать, если они заканчиваются».
Например, в системе баз данных вы можете подать в систему некоторый оператор, а система может разволноваться и сказать: «Ой, я не могу разобраться с синтаксисом этого оператора». Это ошибка пользователя, и мы были бы счастливы сообщить ему это, но потоку, который мог бы это сделать, нужно принимать на обработку другой оператор или даже повторно тот же самый оператор.
Если посмотреть на другой край спектра, то может выйти из строя диск журнала, и мы не сможем писать в журнал записи. В этот момент лучше приостановить все шоу.Должна иметься возможность перезапустить программное обеспечение и начать обеспечивать сервис на резервной аппаратуре. Нам требуется справляться с аварийными ситуациями масштаба вычислительной системы. Обо всем этом нужно задумываться с самого начала разработки приложений и подсистем.
Прокомментировать>>
Управление проектами - статьи
Метатехнология и технология самоорганизации
В реальном проекте технология самоорганизации создается самой командой, возможно, с помощью профессионалов по данному вопросу. Сам процесс ее разработки является мощным интегрирующим фактором в деятельности КМП.Она разрабатывается на стадии ЖЦ команды «Нормализация деятельности (normalizing)» и корректируется в последующем исходя из реальных условий. Поэтому говорить о единой «технологии самоорганизации» для всех типов и видов проекта некорректно. Однако, возможно говорить об уровне метатехнологии для достаточно большого числа проектов, характеризующихся сходными параметрами.
На базе такой метатехнологии самоорганизации команды, например, для IT-проектов, создается своя «технология самоорганизации команды конкретного проекта», учитывающая ресурсные возможности, особенности проекта, организационную культуру компании, уровень профессионализма членов команды, стандарты (международные, национальные, корпоративные) по менеджменту и управлению проектами и многое другое.
Метатехнологию можно сформулировать для достаточно широкого спектра проектов. Она является базой (организационной моделью и моделью деятельности) для создания адекватной конкретному проекту и конкретному набору членов команды ТСО.
Иначе, готовых рецептов нет. Большинство попыток свести управление современным проектом к работе по операциям и к управлению в технических системах не увенчались успехом.
Таким образом, метатехнология является базой и совокупностью инструментов для построения ТСО команды под конкретный проект.
Область применимости
На начальной стадии проекта (start-up) используется практика проведения стартовых семинаров, тренингов или интеграционных процедур для создания и организации работы команды (Team Building). На этой стадии понятие «самоорганизации» не применимо и не имеет смысла. На стадии расформирования и/или реорганизации команды сам термин «самоорганизация» выглядит странно. Поэтому «технология самоорганизации» применима только к процессу развития команды (Team Development).Начинается ее разработка на стадии «Нормализация деятельности (normalizing)» жизненного цикла КМП. На этой стадии члены команды приходят к взаимному согласию в результате переговоров и принятия компромиссов и разрабатывают нормы и правила, на основании которых будет построена их дальнейшая работа.
Сама технология «работает» на стадии «Исполнение планов по выполнению проекта (performing)», т.е. уже после того, как мотивация членов команды определена и ориентирована на успешное выполнение проекта, процесс осуществления проекта стабилизируется, эффективность работы команды возрастает, каждый член команды знает свою роль и т.п.
Следует также учесть, что при фазовых переходах в проекте (переход от одной фазы или стадии ЖЦП к другой) всегда необходимо проводить корректировку деятельности КМП с учетом изменившейся проектной ситуации. Как следствие, требуется также провести и ревизию некоторых элементов используемой технологии самоорганизации. Недооценка потребностей в изменениях может привести к неадекватности используемой технологии самоорганизации и изменившейся КМП.
Условия применимости
Самоорганизация возможна при определенных условиях:Иными словами, в рамках ТСО КМП:
Процесс. Статичность процесса определяется управленческой культурой команды, включающей систему ценностей, ментальность и образ командных действий для данной совокупности индивидуумов, образующих команду, и целями (задачами) проекта.
Изменяющийся интегрированный контекст проекта и ход проекта определяет динамику изменений самой команды. Сам процесс самоорганизации является динамическим. На его входе – КМП, которая должна быть уже построена, т.е. проведен процесс Team Building, интегрированный контекст проекта и метатехнология ТСО. На выходе – успешное завершение проекта и изменившаяся КМП.
Технология. Определяется самим проектом, совокупностью индивидуумов – членов Команды, совокупностью управленческих ролей КМП и их весом для конкретного проекта и/или его жизненной фазы, профессиональным и человеческим совокупным потенциалом членов команды и, в ряде случаев, других участников проекта. Следует учесть, что совокупный профессиональный и личностный потенциал членов КМП должен превышать требующийся для осуществления ТСО (требование избыточности системы).
Вид проектной команды. Представление о самоорганизации применимо к управленческому звену проекта (команде или группе менеджмента проекта) или когда вся команда проекта не превышает 10-12 чел.
Требования к членам команды. Для каждого члена КМП, сознательно участвующим в процессах самоорганизации командной и личной деятельности по проекту, необходимыми начальными условиями являются:
Для каждого члена КМП в самом процессе исполнения проекта при использовании технологии самоорганизации необходимыми условиями являются:
Адаптация
Функционирование любой самоорганизующейся системы обусловлено ее отношениями с внешней средой и реакциями приспособления к изменениям в ней. Адаптивная система должна выполнять свои функции, наиболее эффективным путем в зависимости от состояния окружающей среды. Уникальным свойством самоорганизующейся системы является изменение (корректировка) ее структуры и функций, адекватных изменениям внешней среды и наличие памяти.Адаптация КМП происходит за счет изменения взаимосвязей между ее элементами и корректировки ее управленческих функций с целью выполнения проекта наиболее экономичным путем.
Целесообразность.
Под целесообразностью понимается общая характеристика поведения сложных динамических систем (в случае КМП – организационной и социальной), описывающая ориентацию системы на достижение целей и получение определенных результатов.Целью самоорганизующейся системы является модель «желаемого будущего», а в рамках КМП – достижение запланированных целей и получение ожидаемых результатов проекта, как результатов сознательной деятельности всей команды.
С точки зрения определения целей ТСО команды сложностью является большое количество персональных характеристик членов Команды, которые имеют разные оценочные шкалы, не имеют однозначных трактовок и проявление которых зависит от конкретной ситуации по проекту. Также немаловажную роль играют динамика изменений окружающей среды проекта, неопределенность и неоднозначность информации о внешней и внутренней среде проекта, «человеческий» фактор и т.п.
Иерархическое строение.
В КМП иерархия уровней управления отсутствует, поэтому деятельность выстраивается на связях координации и партнерства. В этом сущность менеджерской команды и ее принципиальное отличие от таких типов проектных команд, как команда управления проекта и команда проекта. Поэтому в рамках КМП используется иерархия целей и задач проекта и ответственности членов КМП. Каждый зависит от каждого и эффективная работа всей команды является совокупностью вкладов каждого ее члена. Если сравнить КМП с тепловозом, то неисправность или отсутствие тех или иных узлов не позволяет ему выполнять работу, для которой он предназначен. В данном случае вопрос о том, какой узел важнее, не возникает.Инструменты менеджмента проектов для ТСО КМП
Возникающие трудности при выборе инструментов всегда связаны с уникальностью проекта (по определению). Уникальность проекта всегда требует создания уникальной команды проекта, т.к. вне проекта «команда проекта» не существует. Поэтому совокупность инструментов можно в той или иной степени определить, однако их набор и взаимосвязи в обязательном порядке формируются под конкретный проект в рамках групповой работы конкретных членов КП.Для того, чтобы поддержать необходимую эффективность деятельности команды, как системы, и избежать возможной подмены целей проекта и команды на групповые или индивидуальные цели, используется ряд инструментов для организации деятельности команды. В частности:
В качестве регулирующих процесс самоорганизации инструментов можно использовать:
Интерпретация системных свойств применительно к КМП.
Применительно к КМП свойств системы можно интерпретировать следующим образом:Память
Память, как способность к воспроизведению прошлого опыта в рамках деятельности Команды, позволяет работать быстрее и эффективнее. Накопление информации в процессе осуществления проекта, т.е. формирование опыта, позволяет предсказывать ход проекта системы в его непрерывно изменяющемся контексте. Как следствие, в ряде случаев решения на основе предсказания хода проекта, базирующегося на основе прошлого опыта, оказываются эффективнее, нежели решения, принятые без его учета.Однако такой путь далеко не всегда является наиболее эффективным. В ряде случаев, использование памяти, как совокупности стереотипов подходов и деятельности, приводит к принятию типовых, простых и неверных решений в нетипичных случаях.
Разнообразие состояний
Разнообразие состояний КМП обуславливается многочисленностью ее элементов, имеющих разную природу (человеческую, социальную, техническую и проч.) и наличием различных как измеряемых, так и неизмеряемых явных и неявных связей между ними.Для того, чтобы использовать ТСО надо создать КМП, обладающую или способной создать в себе еще большее разнообразие, чем разнообразие решаемых проектных задач. Иначе, совокупный потенциал (профессиональный, человеческий, трудовой) КМП должен быть большим, нежели необходимый для осуществления данного проекта. В условиях недостаточного совокупного потенциала КМП или отсутствия ее целостности ТСО просто не будет работать.
Целостность КМП, как системы, проявляется в возникновении новых интегративных качеств, не свойственных образующим ее компонентам, т.е. свойства КМП не являются суммой свойств ее элементов. Такое проявление целостности называется синергией КМП.
При использовании системного подхода для
Системные характеристики КМП.
КМП можно рассматривать как систему, обладающую определенными характеристиками. В этом случае, в качестве подхода к построению ТСО команды можно использовать основные положения теории самоорганизующихся систем [8-12].Под самоорганизующимися системами понимаются открытые системы, в которых происходит (или произошел) спонтанный процесс упорядочивания, обусловленный свойствами элементов самой системы В этом случае под самоорганизацией понимается целенаправленный процесс, в ходе которого создается, воспроизводится или совершенствуется организация сложной динамической системы [9].
Применительно к КМП, под ее самоорганизацией понимается целенаправленный динамический процесс самостоятельного принятия решений и осуществления действий, позволяющий сделать оптимальный выбор из множества вариантов решений и действий и провести соответствующую корректировку хода проекта.
В этом случае целесообразно идентифицировать КМП как систему, определить необходимые и достаточные условия ее самоорганизации, а также определить область применимости ТСО КМП в проектной деятельности.
В КМП, как в системе, можно выделить:
В самоорганизующейся команде обратные связи должны компенсировать любые возмущения, возникающие в проекте (отрицательные обратные связи), а также быть стимулом для улучшения исполнения проекта со стороны членов КМП (положительные обратные связи).
Влияние внешних факторов, например, динамики
Влияние внешних факторов, например, динамики развития рынка и появление новых рынков, изменения управленческих парадигм, повышения комплексности самих проектов, развитие менеджмента проектов, как стратегической управленческой культуры и профессиональной области деятельности и проч. требуют разработки новых подходов к деятельности по проектам, отличающихся технологичностью, рациональностью и эффективностью. В свою очередь, изменение макро- и микросреды проектной деятельности принципиально изменяет внутреннюю среду проекта и требует использования адекватных известных и создание новых инструментов1 в менеджменте проектов.Потребность в технологизации некоторых компонентов проектной деятельности, ранее являющихся предметом «искусства», «мастерства», «ноу-хау (know-how)» и интуиции «зрелых» профессионалов. определяется расширением применения менеджмента проектов и, как следствием, недостатком в высокопрофессиональных менеджерах проектов.
Сведение к «технологии» тех компонентов профессиональной деятельности «зрелого» менеджера проектов, которые всегда являлись характеристикой его класса и «ноу-хау» работы, требует большой осторожности, хорошего опыта и взвешенного подхода. Однако, переосмысление и развитие современного менеджмента проектов, как управленческой интегративной культуры, стратегии деятельности в рыночных условиях и командной «игры», позволяют решать задачи, ранее не стоявшие на повестке дня.
Одной из таких актуальных задач является самоорганизация проектных команд для эффективного выполнения проекта. Актуальность задачи и готовность к ее решению определяется:
В общем случае, под « технологией самоорганизации Команды менеджмента проекта (КМП)» понимается взаимосвязанная совокупность норм и правил, инструментов и действий, используемых с целью обеспечения процессов саморегулирования, самообучения и самоорганизации КМП, как элемента метатехнологии осуществления проекта.
Если использовать системный подход к формированию и использованию такой «технологии самоорганизации» (ТСО), то целесообразно:
Данный подход также применим, в частности, для проектов, в которых вся команда проекта не превышает 10-12 человек и формирование отдельной КМП нецелесообразно. Однако, в этом случае, сама ТСО должна включать не только управленческие компоненты, но и учитывать особенности профессиональной деятельности по проекту других членов команды.
Запуск процесса самоорганизации
Сама по себе самоорганизация не происходит. Естественным образом происходит только повышение энтропии, развитие беспорядка, хаоса и развал работы. Поэтому процесс надо «запустить» и сознательно «силовым» способом поддерживать систему регуляторов этого процесса (регулировать границы процесса самоорганизации КМП).Для запуска нужно иметь:
Управление проектами - статьи
Изменения методологии в режиме реального времени
И, наконец, последний из наиболее важных факторов при создании методологии - подгонка нужной методологии непосредственно в ходе работ. Коль скоро мы понимаем, что каждый проект заслуживает своей собственной методологии, то становится очевидно, что изначальные предположения о том, какую методологию следует использовать, это всего лишь наша первая попытка угадать, что же нам в действительности понадобится. Вот тут-то и становится заметна роль инкрементных разработок.Если мы будем проводить опрос среди разработчиков в середине итераций и между ними, то мы получим возможность учитывать самые свежий опыт работы. Если же мы будем учитывать этот опыт, то команда получит возможность улучшать используемую методологию прямо по ходу работ.
Впрочем, описание динамического изменения методологии не входит в рамки этой конкретной статьи. Некоторую информацию по этой теме можно почерпнуть в работе [Cockburn98], но более подробно она будет представлена в отдельной статье.
Каждому проекту своя методология
В предыдущих разделах статьи мы уже показали, что существует множество различных методологий (и это совершенно естественно) - см. рис. 5. Все они отличаются друг от друга с точки зрения количества занятых в проекте людей, критичности проекта, приоритетов и, возможно, философии разработчиков.
Рисунок 5. Методологии, организованные по принципу люди х критичность х приоритетность.
На рисунке 5 вы видите семь возможных размеров проекта и четыре зоны его критичности. Такое деление достаточно условно, хотя и правдоподобно - мой опыт подсказывает, что именно такие показатели свидетельствуют о необходимости изменения характера методологии, применяемой в проекте. Каждой ячейке схемы может одновременно соответствовать сразу несколько различных методологий. Выбор будет зависеть от предпочтений спонсоров проекта - ставят ли они на первое место производительность, обозреваемость, повторяемость или корректность процесса. "Размер" методологии растет по мере приближения к правой стороне схемы (больше людей, больше коммуникационных элементов в методологии), а "плотность" - к верхней ее части (более строгий контроль). Согласно Принципу 3, чем правее или выше, тем больше стоимость разработки проекта, поэтому те, кто озабочен экономической стороной вопроса, должны постараться разместить свой проект как можно левее и ниже. Бывают ситуации, когда прочие стимулы, например, престиж руководителя проекта или безопасность собственной карьеры, могут заставить вас считать проект "более значительным и критичным", даже если это приведет к увеличению стоимости разработок.
Самое замечательное, что эта схема действительно приблизительно соответствует реальному положению дел. Мы можем сосчитать количество занятых в проекте людей, обсудить его критичность и приоритеты. Используя описанные выше принципы, мы можем принять некие базовые решения относительно того, какую методологию следует использовать в данном конкретном проекте. В конце концов, все остальное решают личные предпочтения. Ниже я приведу несколько примеров из личного опыта и расскажу, как мне самому удавалось применять эти идеи и принципы на практике.
Компоненты и объем методологии
Под "методологией" я понимаю то, что написано в качестве первого толкования этого слова в Американском словаре Miriam-Webster: "ряд связанных между собой методов или техник". Оксфордский словарь толкует это слово только как "изучение методов". В этой статье я использую американский вариант. (Для интересующихся: в "Толковом словаре русского языка" Ожегова это слово трактуется как "принципы и способы организации теоретической и практической деятельности" и "совокупность методов, применяемых в какой-либо науке". -- прим. переводчиков)Под "размером" методологии я имею в виду число элементов управления в ней, к которым относятся поставляемые артефакты, стандарты, виды деятельности, меры качества и т.д. "Плотность" методологии измеряется уровнем детализации и связности, необходимых для ее осуществления. Более высокая плотность соответствует жесткому контролю или сильному формализму. "Вес" методологии определяется путем умножения размера на плотность (только теоретически, так как я не привожу здесь никаких цифр относительно размера и плотности).
Я буду говорить также о "размере проекта". Под этим термином я подразумеваю число людей, работающих над проектом, деятельность которых необходимо координировать. Нередко возникает мнение, что размер проекта соответствует размерам задачи, но все не так просто. Размер задачи нельзя определить в абсолютных величинах, так как всегда может появиться новый человек, который сумеет разглядеть в этой задаче некоторый упрощающий паттерн. Именно поэтому я старательно разграничиваю понятия "размер проекта" и "размер задачи".
Рисунок 1. Составляющие методологии (с примерами).
Методология включает в себя, по крайней мере, те предметы и темы, которые указаны на рис. 1: роли, навыки, команды разработчиков, инструментарий, техники, виды деятельности, стандарты, рабочие продукты, меры качества и систему ценностей, принятых в команде разработчиков.
В большинстве своем, эти пункты не нуждаются в дополнительных объяснениях. Под "стандартами" мы имеем в виду нотационные стандарты (например, диаграммы и языки программирования), которые используются при выполнении данного проекта. Есть также стандарты управления и принятия решений, например, использование инкрементных разработок. И, наконец, у нас есть некоторая система условностей - стандартов, которые определяются для данного конкретного проекта.
Менее очевидно, что такое "система ценностей, принятых в команде разработчиков". Под этим термином мы понимаем то, к чему стремится команда, как они предпочитают общаться и работать. Для команд с различными системами ценностей будут эффективны различные методологии.
У методологии есть "объем", который определяется протяженностью жизненного цикла проекта, разнообразием ролей и видов их деятельности, которые и пытается покрыть собой методология (см. рис. 2):
Рисунок 2. "Объем" методологии.
Некоторые компании работают по методологиям, которые покрывают весь процесс разработки программного продукта - от первого звонка клиента до поддержки и сопровождения уже работающей системы. При этом все роли оплачиваются из фондов проекта. Большая часть тех коммерческих книг, которые именуются "методологиями", посвящены, как правило, описанию только одной роли, а именно, роли проектировщика/программиста. В таких книгах рассказывается о том, как нужно проектировать, уделяется большое внимание нескольким различным техникам и стандартам изображения диаграмм. Если мы сравним тот объем задач, который должна охватывать методология, с той информацией, которая содержится в этих книгах, сразу станет понятно, почему у загруженных работой программистов такие "методологии" вызывают лишь досаду и раздражение. На самом деле, то, какие техники или стандарты изображения диаграмм использует проектировщик, создавая дизайн системы, не оказывает существенного влияния на конечный успех проекта, который конечно же, является наиболее важным фактором в любом бизнесе.
Краткий обзор
"Методология с большой буквы" - это название того, как организация многократно производит и поставляет программные системы:кого в ней нанимают на работу и зачем, чего ожидают люди от своих коллег, какие условности они соблюдают, начиная от размещения рабочих мест в офисе и до используемых рабочих продуктов. Когда какая-то компания помещает в газете объявление о приеме на работу, это объявление представляет собой некий артефакт принятой в этой компании методологии. Как оказалось, чтобы получить практические результаты от изучения методологии, мы должны рассматривать ее именно с такой широкой точки зрения.
В данном случае, моей целью было создать откровенный диалог между людьми, придерживающимися различных взглядов на этот вопрос, и обозначить принципы, согласно которым можно рекомендовать ту или иную методологию. Итак, сначала нам надлежит ответить на следующие вопросы: Что же такое "методология"? Должно ли методологий быть много? Может ли одна быть "лучше", чем другая? Как узнать, какие элементы методологии стоит перенимать? Как применить все эти знания в крупном проекте?
Существование множества методологий совершенно необходимо. Их можно классифицировать по размеру команды разработчиков и критичности системы
(разумеется, их можно классифицировать по гораздо большему количеству величин, однако эти две лучше всего подходят для изначальной оценки). Затем те, кто занимаются проектированием методологии, определяют рассматриваемые вопросы, роли, виды деятельности, а также поставляемые артефакты и стандарты, которые они собираются охватить. Они работают, исходя из своих убеждений, уделяя первостепенное внимание некоторым особенностям данного конкретного проекта. Все это должно наилучшим образом подходить людям, которые заняты в работе над проектом, и их культурным характеристикам.
В этой статье мы рассмотрим то, как эти идеи были применены в ряде проектов с различным количеством разработчиков, использовавших разные технологии.
Краткое содержание
Как только мы пытаемся разобраться, "из чего же состоит методология", сразу становится понятно, что методологий должно быть много. При этом для каждого конкретного проекта "оптимальной" будет одна какая-то методология. Более того, все люди обладают разными склонностями, которые обусловлены их жизненным опытом, страхами и принципами. При выборе методологии особое внимание нужно уделять трем основным факторам: размеру команды разработчиков, критичности проекта для компании и его приоритетности. Помимо этого, на результат будут оказывать влияние как культурные ценности команды, так и индивидуальные характеристики ее членов. В этой статье описаны структура и опыт использования этих принципов в проектных разработках.Методология и ее автор
"Любая методология основывается на страхе", - написал как-то Кент Бек в одном из обсуждений методологий. Поначалу это замечание показалось мне малозначительным, но потом я понял, что в большинстве случаев, оно совершенно справедливо. Каждый элемент методологии призван предотвратить появление тех проблем, с какими автор методологии уже сталкивался в прошлом. Боитесь, что программисты сделают в коде много ошибок? Не забывайте о проверках кода. Вам кажется, что заказчики сами не знают, чего им надо? Создавайте прототипы пользовательских интерфейсов. Опасаетесь, что проектировщики уйдут в самый разгар работы? Сделайте так, чтобы они писали подробную документацию всего, что делают. Если бы методологи могли (или хотели) явно обозначить свои основные страхи и пожелания, цель методологии была бы ясна с первого же взгляда.И, наконец, в качестве последней составляющей характеристики методологии, мы должны упомянуть индивидуальную философию ее автора. Эта философия оформляется в процессе приобретения автором личного опыта, а также экстраполяций, сделанных на основе этого опыта. Чтобы методология "подошла" определенному проекту, она должна соответствовать философии и страхам как команды разработчиков, так и самого автора методологии.
Мой опыт в различных проектах
В Центральном Банке Норвегии работает около 40 штатных программистов и вполовину меньше контрактников, и надо сказать, им приходится решать на удивление много разнообразных задач.В то время, когда я там находился, основным проектом был проект Y2K, в котором было занято 35 человек. Главной целью здесь являлось предотвращение крушения банковской системы Норвегии, которое могло состояться 1 января 2000 года. Критичность проекта соответствовала "потере невосполнимой суммы", главными приоритетами были своевременность и корректность проекта. Основополагающей технологией являлись традиционные большие ЭВМ.
В то же самое время шла работа над другим, внутренним проектом, который заключался в создании программы для банковского персонала. Она включала в себя возможность заказывать обед в кафетерии и отслеживать статус сделанных заказов - и все это в виде веб-приложения. Над этой задачей работало один-два человека, которые использовали Delphi или Java и Интернет-браузер. Критичность проекта соответствовала "потере комфорта", приоритеты - сделать быстро и без особых затрат.
Та же группа программистов несла ответственность за работу над системой, которая должна была собирать и проверять все данные о межбанковских транзакциях в стране, причем эти разработки велись вместе с еще одной компанией. В проекте, который я сейчас опишу более подробно, тоже использовались большие ЭВМ.
Один программист использовал язык SQL для формирования различных обобщающих отчетов, касающихся инвестиций и затрат. Еще один проект был начат для того, чтобы заменить существующие системы, работающие на больших ЭВМ, на распределенные системы, использующие Интернет-технологии, объектно-ориентированный подход и компонентную архитектуру, построенную на базе CORBA/Java. Были еще и другие проекты, но я думаю, что упомянул уже достаточно, чтобы читатель получил общее представление о ситуации. Как мне кажется, в подобном случае невозможно говорить о какой-то одной методологии, которая была бы "правильной" для всего этого разнообразия задач и проектов.
Что касается меня, то я работал над проектом, связанным с межбанковскими транзакциями, а также над внутренним Интернет-проектом для отслеживания заказов. Первый из них был особенно интересен, так как за время работы над ним его пришлось дважды "передвигать" из одной клетки нашей "методологической решетки" (рис. 5) в другую.
В этот момент я решил перевести наш проект в категорию E5. Это означало переход к инкрементным разработкам, планированию выпусков системы с минимальным риском, еженедельные телеконференции всей группы разработчиков, ежемесячный доклад о положении дел и т.д.
Однако сразу после этого ушел в отпуск архитектор, одного из ведущих программистов перебросили на проект "по борьбе с ошибкой 2000 года", а мы обнаружили ошибку в проектных решениях, отвечающих за восстановление после ошибочных ситуаций и за контроль над взаимоисключающим доступом. Теперь на наш проект отвели уже десять человек, большинство которых не имело опыта работы в данной области, к тому же работали в совершенно разных местах. Обычные каждодневные встречи и общение были попросту невозможны.
В середине февраля я решил, что проект пора переводить в категорию E15. Мы разработали более подробный план поставок для каждого разработчика, запустили программу моделирования тестов, стали уделять большее внимание общению с каждым из группы разработчиков. Из-за нехватки времени мы не стали предписывать членам команды делать еще и бумажную работу, а предложили перевести все в рамки личного общения - бесед по телефону, телеконференций и поездок друг к другу на поезде.
В этом проекте я впервые на практике применил схему с рис. 5 и с ее помощью последовательно менял методологию прямо в ходе проекта. Впрочем, неосознанно я пользовался всеми этими принципами и схемами, начиная с 1994 года. Вот еще несколько примеров, которые я привожу в порядке возрастания размеров проекта:
В нем не было никакой письменной документации, за исключением нескольких набросков вариантов использования. Вся работа проходила в совершенно неформальной обстановке, вплоть до того момента, когда было принято решение не разрабатывать эту систему самим, а купить уже готовый продукт (все в соответствии с приоритетами экономичных проектов).
Принципы
Существенную роль в поисках нужной методологии играет определение принципов, по котором ее можно было бы разработать. После создания полудюжины различных методологий и проведения нескольких дюжин опросов и интервью разнообразных проектов, я сумел определить четыре основные принципа, которые и представляю вашему вниманию. На сегодняшний день я могу сказать, что практически уверен в справедливости любого из них. Ниже мы рассмотрим их использование.Принцип 1. Большая по размерам методология нужна тогда, когда в проекте занято большое число разработчиков.
"Большей по размерам" я называю ту методологию, в которой содержится большое количество элементов. Поскольку главное предназначение любой методологии - координировать работу людей, то следовательно, чем больше проект, тем "больше" должна быть и используемая в нем методология. Объем методологии возрастает пропорционально числу ролей и типов рабочих продуктов. [Harrison96].
Этот принцип не позволит нам рассчитывать, что методология, которая хорошо зарекомендовала себя в маленькой команде, будет так же хорошо работать и в большой. Кроме того, он указывает на то, что не стоит употреблять методологию, рассчитанную на большую команду разработчиков, если над проектом работает небольшая группа программистов.
Принцип 2. Большая корректность методологии (видимая со стороны) или, другими словами, "большая плотность" нужна в тех случаях, когда скрытые ошибки в программном продукте могут повлечь за собой значительный ущерб (большая критичность разрабатываемой системы).
Я классифицирую программные системы по следующим категориям возможного ущерба (разумеется, этот список можно расширить):
Потеря комфорта в работе означает, что при поломке системы люди будут вынуждены больше работать вручную или же идти друг к другу для разговора, чтобы устранить помеху в коммуникации. Представьте, например, что ломается система, контролирующая процесс купли-продажи, или же программа, поддерживающая корпоративную инфраструктуру.
Потеря несущественной суммы означает, что утрата денежных или других сходных по значимости ценностей приносит компании некоторые неудобства, но не более. К этому типу можно отнести неправильную выплату зарплаты или неверные платежи по счетам (все это можно исправить вручную).
Потеря невосполнимой суммы означает, что утрата денежных или сходных по значимости средств фактически эквивалентна банкротству компании. В эту категорию можно отнести программные системы национальных банков и т.п.
Потеря жизни означает, что в результате ошибки в программе могут погибнуть люди. К этой категории относятся предприятия, работающие на атомной энергии, проекты, связанные с космосом, системы управления полетами самолетов и т.д.
Согласно этому принципу, дополнительные затраты на более тщательную защиту от ошибок вполне могут себя оправдать - в зависимости от того, в какой из четырех вышеперечисленных категорий находится проект.
Поломка на атомной станции гораздо серьезнее, чем, например, поломка в моей программке, которая отслеживает течение матча по боулингу. Следовательно, при создании программных продуктов для атомной станции можно позволить себе использовать более трудоемкую и дорогую методологию. В этом случае, методология будет содержать большее количество различных элементов, причем эти элементы будут иметь большую "плотность".
Допустим, в обоих проектах используются варианты использования (use cases). Ребята из Лиги по боулингу вполне могут написать их в виде нескольких предложений на салфетке или на доске и считать это достаточным документом. Команда, которая строит атомную станцию, наверняка будет настаивать на том, чтобы все варианты использования были написаны с помощью специального инструментария, чтобы были заполнены все необходимые поля и т.д. После они обязательно потребуют пересмотра, внесения правок и многократного подписания документов в течение жизненного цикла проекта. При этом стоимость вторично написанных вариантов использования возрастает. Однако преимущество этого метода состоит в том, что чем большее количество "писателей" и "читателей" будут взаимодействовать между собой, тем меньше вероятность возникновения ошибок и недопонимания.
Возрастающая стоимость разработок вполне оправдывается большей безопасностью и надежностью конечного продукта.
Принцип 2 указывает на то, что есть ситуации, когда дополнительные расходы на разработку оправдывают себя. И это хорошо, поскольку следующий Принцип, за номером 3, гласит, что более "тяжелая" методология ложится тяжким бременем на бюджет проекта.
Принцип 3. Незначительное увеличение "размеров" или "плотности" методологии ведет к существенному увеличению стоимости проекта.
Приостановка работы одной команды программистов для координации с другой командой требует не только дополнительного времени, но и дополнительной концентрации (см. обсуждение "потока" у ДеМарко [DeMarco99] и Коуберна [Cockburn98]). Для обновления документации, относящейся к требованиям, дизайну системы и тестированию, тоже понадобится немало времени.
Этот принцип справедлив для любого проекта. Как вы уже заметили, мы не обсуждаем, выгодны или не выгодны компании дополнительные затраты - здесь затрагивается исключительно вопрос стоимости, не более. Проблема определения сообразности дополнительных расходов относится к Принципу 2.
Итак, мы подошли к точке, когда уже можно обсуждать отношения между размером методологии, проекта и задачи. Делать это довольно непросто, потому что существует тенденция считать, что чем больше задача, тем больше нужно людей для ее выполнения.
Размеры проекта и методологии связаны между собой положительной обратной связью. Если над проектом работает сравнительно немного людей, то им нужна сравнительно небольшая методология. Чем меньше "весит" методология, тем продуктивнее работает команда. А чем продуктивнее работают люди, тем больше задач они могут решать - иначе говоря, маленькая команда разработчиков, использующая "легкую" методологию, вполне способна решать крупномасштабные задачи.
С другой стороны, когда в проекте участвует большее количество людей, их работу сложнее координировать, т.е. нужна более "тяжелая" методология.
Такая методология будет снижать их продуктивность, поэтому для выполнения задачи понадобится большее число разработчиков. Впрочем, размер методологии растет медленнее, чем размер проекта, поэтому в какой-то точке можно прийти к такой ситуации, когда команда будет справляться с поставленными задачами, и менеджмент будет успевать координировать работу программистов (при условии грамотного и здравого управления процессом, разумеется).
Именно поэтому (см. Рисунок 3) для решения конкретной задачи вам понадобится меньше людей, если вы будете использовать легкую методологию, и больше - если тяжелую. Впрочем, существует ограничение по размеру задачи, которую может решить данное число людей. У большой команды, использующей тяжелую методологию, этот "порог" выше, чем у маленькой команды, которая использует легкую методологию. Таким образом, если ваша задача выходит за рамки такого ограничения, то вам придется, с одной стороны, увеличивать количество разработчиков и, с другой, использовать более тяжелую методологию.
Рисунок 3. Объем задачи и методологии непосредственным образом влияет на количество персонала в компании.
Главная трудность состоит в том, что практически невозможно точно определить объемы задачи в самом начале проекта, а следовательно, и минимальное число людей, которые могут эту задачу решить. К тому же, количество разработчиков напрямую зависит от того, какие конкретно люди будут работать над проектом.
И наконец, если размеры проекта возрастают, может оказаться, что оптимальным решением будет применить другую методологию.
Завершившийся не так давно проект С3 (Chrysler Comprehensive Compensation [C3a, C3b]), может служить убедительным примером всего, о чем я сейчас говорил. После того, как 26 человек не смогли выполнить задачу по созданию системы, которая считалась "большим проектом", за дело взялась малая часть этой команды - всего восемь человек. Используя новую, максимально легкую, но при этом строгую методологию [XP], они начали проект с нуля и уже через год смогли завершить то, что не смогла сделать большая команда, применявшая тяжелую методологию.
Можно с уверенностью сказать, что частично такой успех методологии ХР был обеспечен последним, четвертым Принципом.
Принцип 4. Наиболее эффективная форма коммуникации (для передачи идей) - непосредственное взаимодействие, лицом к лицу, как при рисовании у доски.
Принцип 4 гласит, что разработчикам, которые сидят друг возле друга и могут свободно общаться, легче создавать программный продукт, то есть, затраты на разработку этого программного продукта будут меньше. Это также означает, что если проект растет таким образом, что обеспечить непосредственную коммуникацию между разработчиками уже не удается, ее эффективность будет падать, а значит, возрастут связанные с ней затраты.
На рисунке 4 изображена кривая, которая показывает, как падает эффективность коммуникации при переходе от непосредственного общения у доски к разговору по телефону, интерактивной переписке (чату и т.п.), видеозаписям, и, наконец, к документации на бумаге. Чем ниже находится кривая, тем меньше у разработчиков возможности общаться между собой, исчезает мультимодальность коммуникации, возможность передавать информацию с помощью интонации, задавать вопросы по мере их возникновения.
Рисунок 4. Эффективность коммуникации
Однако это "правило коммуникации" вовсе не означает, что любой программный продукт должен быть разработан несколькими людьми, сидящими в одной комнате. Автор методологии должен знать, что если первоочередными факторами являются продуктивность и стоимость программных разработок, то необходимо уделить особое внимание работе небольшими командами и непосредственному общению между сотрудниками (как, например, это сделано в Extreme Programming [XP]). Этот вывод подтвержден исследованиями [Plowman95]. Кроме того, в работе Силлинса [Sillince96] приводится обсуждение различных аспектов коммуникации внутри одной организации.
Приоритеты
При всем при этом немалое значение в выборе методологии играет желание спонсоров проекта: хотят ли они получить программный продукт быстро, с минимальным количеством дефектов, или же им нужно наблюдать за процессом во всех его проявлениях. Разным приоритетам соответствуют разные методологические рекомендации.В некоторых методологиях приоритеты заметны сразу, в некоторых нет. Так, например, объектно-ориентированная методология Мартина и Оделла [Martin96] достаточно общая и подходит для многих случаев, однако не совсем понятно, на что конкретно она направлена, и можно ли менять эту "направленность" для работы над различными проектами. Семейство методологий OPEN [BHS97], по всей видимости, основной целью полагает корректность программных продуктов, явность и повторяемость процесса. Методология под названием The Personal Software Process of Humphreys [Humphreys97] была разработана для обеспечения предсказуемости работ.
В трех последних методологиях о приоритетах говорится открыто: авторы семейства методологий Crystal [Cockburn98, Crystal] и Extreme Programming [XP, Beck99] заявили, что их методологии направлены, в первую очередь, на повышение продуктивности и снижение стоимости работ. При этом они все же отличаются друг от друга - Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология "Adaptive Software Development", детище Джима Хайсмита [Highsmith], разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках).
Любая методология состоит из десяти
Любая методология состоит из десяти основных элементов: ролей, навыков, видов деятельности, используемых техник, инструментария, поставляемых артефактов, стандартов, мер качества и приоритетов проекта. Главным результатом моей работы, который я обобщил в этой статье, стало обязательное наличие многих разнообразных методологий. В зависимости от размера проекта (числа людей, работу которых необходимо координировать), критичности разрабатываемого приложения и основных приоритетов, в проекте могут применяться различные методологии. Для любой точки в пространстве размер/критичность создатели методологии выбирают определенный ряд аспектов (роли в проекте, виды деятельности, поставляемые продукты и стандарты) и пытаются минимизировать риски, связанные с некоторыми качествами проекта. При этом они базируются на своем личном опыте, к которому относятся также их намерения, страхи и философские воззрения. При сравнении различных методологий необходимо учитывать все эти моменты, а также их соотношения с нуждами проекта или организации.Мы выяснили четыре основных принципа проектирования методологии. Вкратце их можно описать следующим образом:
чем больше команда, тем "тяжелее" должна быть используемая методология;
увеличивайте "плотность" методологии при увеличении критичности проекта;
чем "тяжелее" методология, тем выше стоимость проекта;
самая эффективная форма коммуникации - непосредственное общение.
Все эти принципы нашли свое подтверждение во время работы автора над различными проектами, однако нам известно очень мало других исследований на данную тему, хотя разработка данного вопроса представляется очень актуальной.
Управление проектами - статьи
Для чего нужны модели
Прошло уже почти 20 лет со времени появления в 1986 году вызвавшей множество споров статьи Фредерика Брукса «Серебряной пули нет». В данной работе автор предрекал, что в течение ближайшего десятилетия с момента её выхода не возникнет методов, использование которых позволит на порядок величин повысить производительность разработки программного обеспечения. Эта статья вызвала множество споров и работ с опровержениями, и в 1995 году Ф. Брукс опубликовал ответы на некоторые из критических замечаний [1].По признанию самого Ф. Брукса наиболее тщательный анализ его статьи был предпринят Дэвидом Харелом в работе «Кусая серебряную пулю» [2]. Д. Харел рассматривал «Серебряной пули нет» как чрезмерно пессимистическую и намеревался высветить в своей работе более яркую сторону проблемы, предпосылая статье подзаголовок «К светлому будущему программных разработок». Им была предложена унифицированная система разработки программного обеспечения, главной целью которой было освободить программиста от необходимости рассуждать на чрезмерно глубоком уровне детализации, предоставить возможность размышлять над решением проблемы и представлять свои идеи при помощи соответствующей высокоуровневой нотации, а именно моделей. «Использование подходящего графического формализма может оказать впечатляющий эффект на инженеров и программистов» [2]. Кроме самих моделей для эффективной работы необходимы средства для их изучения и анализа, среди которых одной из наиболее полезных, по мнению Д. Харела, является возможность исполнения модели.
В настоящее время всё чаще упоминается метод разработки на основе моделей или Model Driven Development (MDD) [5], обещающий стать первым технологическим скачком со времён появления компиляторов, который сможет значительно ускорить процесс создания программного обеспечения и улучшить его качество. Лидирующие позиции в данной области призван занять стандарт Model Driven Architecture (MDA), разработкой которого занимается консорциум OMG. Разработка в рамках MDA предполагает, что сначала создаётся одна или несколько абстрактных моделей системы, которые далее проходят несколько стадий автоматизированной трансформации в более детальные модели и, в конечном итоге, преобразуются в код на языке программирования.
Как проще написать одну строку на Java, чем 10 строк на языке ассемблера, так же проще построить графическую модель на языке UML, чем писать на Java, считают сторонники подхода MDA. Но для успешного применения моделей необходима не только удобная нотация для их записи, которую предоставляет язык UML, но и соответствующий инструментарий для их изучения.
Автоматизация разработки является тем технологическим средством, которое должно привести к ускорению процесса создания программного обеспечения и повышению его качества. Тем не менее, ранние попытки применения автоматизации в сфере моделирования ограничивались лишь поддержкой в создании диаграмм и генерацией скелетного кода, что было недостаточным для того, чтобы существенно увеличить производительность разработки. Наибольшей же отдачи от MDD можно добиться лишь после полной реализации его потенциальных возможностей для автоматизации, которые включают:
Данная статья посвящена теме исполнения моделей. Автоматическая верификация подразумевает возможность при помощи компьютера определить, удовлетворяет ли модель требованиям, предъявляемым к системе. Такая проверка может принимать различные формы, включая формальный математический вывод, но наиболее часто под этим подразумевается тестирование и отладка моделей путём их исполнения. В любом случае важно иметь такую возможность для моделей, находящихся на высоком уровне абстракции и даже неполных, которые появляются на ранних стадиях процесса разработки, поскольку именно тогда и принимается большинство фундаментальных решений.
Генерация автоматной модели
Многие современные реализации исполняемых моделей базируются на синтезе автоматов. Далее конечные автоматы можно интерпретировать непосредственно или использовать для последующей генерации кода. Применение автоматов в данном случае обусловлено следующими их преимуществами: они представляются в хорошо формализованном виде, имеется развитый математический аппарат для работы с конечными автоматами, который позволяет проводить над ними формальные исследования и преобразования, и, наконец, автоматные модели довольно хорошо отображаются в код на целевых языках. Но важно подчеркнуть, что хотя автоматные модели являются хорошо формализованным и мощным средством спецификации, они могут оказаться сложнее в работе и менее наглядными для неподготовленных пользователей, чем другие модели. Кроме того, при рассмотрении программной системы возможен разрыв, связанный с различиями в степени абстракции, используемой в автоматных и других спецификациях.Рисунок 2: использование автоматов
Следует отметить, что при исполнении моделей при помощи автоматов появляются дополнительные трудности при реализации визуализации исполнения. Дело в том, что исполнению подвергается уже не сама модель, а её представление в виде автоматов или даже код на языке программирования, а отображать изменения необходимо в терминах самой модели. Таким образом, по сравнению с непосредственной интерпретацией моделей, в данном случае необходимо прилагать дополнительные усилия для определения соответствия конструкций, употребляемых в моделях, и их образов в автоматах и коде.
Интерпретация
В данном случае для исполнения модели создаётся специальная программа, называемая интерпретатором. На вход интерпретатору подаётся сама модель в том виде, в каком она была создана пользователем, без каких либо промежуточных преобразований. Основным недостатком интерпретации является её низкая скорость.Рисунок 1: интерпретация
На рисунке 1 представлена схема исполнения моделей с использованием непосредственной интерпретации.
Исполнение моделей при помощи виртуальной машины
Буздин К.В.Труды Института Системного Программирования РАН, 2004 г.
Параллельное исполнение
При комплексировании работы виртуальных машин могут возникать ситуации, когда нужно организовать их параллельное выполнение. Это может потребоваться, например, в случае необходимости рассмотрения всех альтернатив сразу. Кроме этого, некоторые языки моделирования имеют в своём составе специальные конструкции для обозначения того, что элементы модели должны работать параллельно.Для организации параллельной работы нескольких виртуальных машин можно использовать механизм потоков (thread), предоставляемый многозадачными операционными системами. В этом случае каждая виртуальная машина запускается в отдельном потоке.
Если же существует необходимость организации более детального контроля над параллельной работой виртуальных машин, то можно вручную организовать их псевдопараллельное выполнение. В этом случае в качестве единицы работы отдельной виртуальной машины можно использовать её команды. Каждая из параллельно работающих машин поочерёдно получает право сделать один шаг, после чего она возвращает управление. Для реализации этого можно использовать менеджер, содержащий список всех параллельно работающих машин и раздающий им право сделать очередной шаг на основании выбранной стратегии.
Если в системе реализованы вызовы одной виртуальной машины из другой, то при получении машиной права сделать очередной шаг возможны два варианта:
1. Не существует машины, вызванной из данной машины. В этом случае машина выполняет одну команду из своего программного поля и возвращает управление.
2. Из данной машины
A вызвана машина B, и машина A ожидает её завершения. В таком случае машина A делегирует право сделать очередной шаг машине B. Машина
B выполняет шаг и возвращает управление в машину A, после чего та тоже возвращает управление.
От того, насколько эффективно будет организована работа с моделями, напрямую зависит успех MDD. Один из наиболее удобных и эффективных путей познания пролегает через эксперимент. Именно поэтому исполнение моделей способно значительно улучшить и ускорить их понимание. В данной статье был предложен способ исполнения моделей, основанный на использовании виртуальных машин. Показаны его основные преимущества по сравнению с непосредственной интерпретацией и конечными автоматами, которые широко применяются в данной области. При проектировании системы исполнения моделей, основанной на виртуальной машине, разработчик обладает большей свободой в принятии решений, поскольку команды виртуальной машины создаются исходя из потребностей выбранной предметной области. Этим же обусловлена и простота перевода модели в последовательность таких команд. Кроме того, виртуальные машины обладают широкими возможностями комплексирования.
Почему важно, чтобы модели были исполняемыми
Одним из наиболее важных способов нашего познания является обучение посредством эксперимента. В контексте данной статьи это означает исполнение моделей. Дэвид Харел сравнивает модели, которые не могут быть исполнены, с машинами, у которых нет двигателя. Важным преимуществом исполняемых моделей является то, что они на ранних стадиях обеспечивают возможность получения опыта работы с создаваемой системой. В данном случае уместна аналогия с языками программирования. Когда мы изучаем новый язык, мы всегда бываем очень воодушевлены успешным выполнением первой тривиальной программы “Hello, world!”. Этот простой опыт укрепляет нашу уверенность в правильности действий и служит отправной точкой в дальнейших исследованиях. Информация, полученная в результате экспериментов, помогает перейти от формального знания к пониманию. Путём исполнения модели, отражающей наши ожидания относительно поведения системы, задолго до собственно реализации самой системы мы можем убедиться, что она действительно будет работать правильно. В случае, если при этом будут обнаружены отклонения от ожидаемого поведения, мы можем вернуться к модели, изменить её и запустить тот же сценарий, на котором были выявлены недостатки. Таким образом, исполнение модели позволяет найти ошибки, которые иначе остались бы незамеченными до тех пор, пока большая часть системы уже не была бы реализована, и было бы слишком поздно. И это начинает проявляться сразу же после того, как модель впервые будет запущена на исполнение.Кроме того, на ранних стадиях создания системы к работе могут привлекаться представители заказчика. В этом случае исполняемая модель будет играть роль прототипа при уточнении требований.
Результат исполнения модели
Результаты, получаемые при исполнении модели, могут быть подразделёны на два вида:В первом случае исполнение модели предоставляет возможность получить опыт от общения с реальной системой. При этом допустимо пошаговое исполнение с целью более детальной отладки. При интерактивном исполнении пользователь играет роль окружения системы, он может порождать события, наблюдать и изменять значения переменных, выбирать путь дальнейшего продолжения исполнения, если имеется несколько возможностей. В ответ инструмент поддержки исполнения должен перевести систему в новое состояние. Кроме того, поскольку большинство моделей имеют графическое представление, то изменение состояния должно отражаться на самой модели, например, путём изменения цвета некоторых её элементов. Для получения эффекта непрерывного исполнения интересующую последовательность событий из окружения системы можно подготовить заранее. В таком случае, при наличии соответствующей графической поддержки, можно наблюдать анимацию модели. Аналогичного эффекта можно добиться, если инструмент сам будет генерировать события случайным образом. Также полезна возможность использования точек останова для изучения конкретных состояний моделируемой системы. Особый интерес представляет полное исполнение модели, когда инструмент генерирует все возможные сочетания событий из окружения с целью проверки всех возможных вариантов поведения моделируемой системы. При этом необходима возможность формального описания интересующих разработчика ситуаций и автоматического их распознавания, поскольку результат полного исполнения для реальных систем будет слишком объёмен для исследования его человеком.
В процессе исполнения модели инструмент может собирать различные данные, например, подсчитывать некоторые метрики или составлять трассы, которые представляют собой последовательность событий, возникающих в системе. Подобные данные могут оказаться полезными в дальнейшей работе над системой, например для создания тестов.
Создание виртуальной машины
При создании виртуальной машины для некоторого класса задач необходимо выполнить следующие этапы:1. Выявить весь объём данных, которые в процессе выполнения задачи могут подвергаться преобразованию. Эти данные образуют поле зрения виртуальной машины.
2. Определить набор команд, который, подобно командам универсальной ЭВМ, будет служить для записи решения конкретной задачи. Этот набор является специфичным для данного класса задач. Последовательность команд из этого набора, определяющая решение конкретной задачи, записывается в программное поле виртуальной машины и не меняется в процессе её функционирования.
3. Реализовать интерпретационный компонент виртуальной машины, представляющий собой совокупность механизмов. Посредством этих механизмов виртуальная машина осуществляет интерпретацию команд, находящихся в программном поле.
4. Реализовать транслятор из внешнего представления модели в последовательность команд виртуальной машины.
Для виртуальной машины должен быть определён способ её использования, то есть:
способ передачи входной информации и формирования начального поля зрения;
способ активизации (запуска) системы;
способ останова системы;
способ извлечения переработанной информации.
Тот факт, что при создании виртуальной машины заданию подлежит набор команд, определяет большее удобство её применения. Для использования автоматов должны быть разработаны методы сведения моделей к автоматам, а решение данной задачи может представлять значительную сложность. В случае же виртуальной машины мы сами имеем возможность взять такой набор команд, который наилучшим образом будет отражать специфику выбранных для исполнения моделей. При этом сам процесс перевода модели в последовательность подобранных таким образом команд не потребует серьёзных усилий. Конечно же, процесс подбора команд должен представлять собой компромисс между простотой перевода моделей в команды и легкостью собственно интерпретации составленных из таких команд последовательностей.
Способы исполнения моделей
Рассмотрим следующие способы исполнения моделей:Виртуальная машина как строительный компонент
Взглянем ещё раз на то, что представляет собой виртуальная машина. Она состоит из некоторого интерпретатора, исполняющего последовательность известных ему команд и имеющего доступ к области памяти для хранения данных. Рассмотрим, что получится, если допустить возможность существования в пределах одного сеанса исполнения нескольких таких интерпретаторов. Поскольку программное поле виртуальной машины остаётся неизменным в течение всего процесса её функционирования, то несколько интерпретаторов могут работать с одной и той же последовательностью команд или каждый иметь свою собственную. Возможна также реализация, в которой различные интерпретаторы будут предназначены для работы с разными наборами команд. Таким образом, задача исполнения модели может быть разделена на подзадачи, для каждой из которых будет создан отдельный набор команд и его интерпретатор со своей моделью памяти. Кроме того, возможен также случай совместной работы нескольких интерпретаторов над общей областью памяти для хранения данных, но, поскольку данные в процессе исполнения модели могут изменяться, такой подход сопряжён с дополнительными трудностями и его использование не всегда оправдано.Таким образом, набор команд в совокупности с его интерпретатором и моделью памяти образуют своеобразный строительный компонент. Из таких компонентов при создании системы исполнения моделей можно составлять различные комбинации. Остаётся только вопрос о способах комплексирования работы таких компонентов, наибольший интерес из которых представляют два, описанные ниже.
Виртуальная машина
В качестве промежуточного представления для исполняемых моделей могут использоваться не только конечные автоматы. Дело в том, что они представляют собой слишком общий и низкоуровневый инструмент. Конечные автоматы подходят для решения очень широкого круга задач, поэтому в них может не оказаться инструментов, специфичных для выбранных для исполнения моделей. Кроме того, сложность конечных автоматов может резко возрастать при увеличении сложности самой описываемой ими модели [4].Альтернативной основой для реализации исполняемых моделей может послужить виртуальная машина. Виртуальная машина — это абстрактная машина, для которой существует интерпретатор. В свою очередь, абстрактная машина — это модель процессора, которая не предназначена для реализации «в железе». Для неё определены набор команд и модель памяти. В памяти хранятся данные, с которыми может работать машина. В сравнении с автоматами при создании виртуальной машины имеется большая свобода выбора модели данных.
: использование виртуальной машины
На рисунке 3 схематически представлен процесс исполнения модели при помощи виртуальной машины. Модель подаётся на вход транслятору, который переводит её в набор команд виртуальной машины. Далее интерпретатор осуществляет исполнение команд в заданном пользователем режиме. Кроме того, в процессе исполнения может происходить запись отладочной информации.
При визуализации исполнения здесь, как и в случае использования автоматов, необходимо определять соответствие между конструкциями, употребляемыми в моделях, и их образами в последовательности команд виртуальной машины.
Исследуя рисунки 1, 2 и 3 можно заметить, что и непосредственная интерпретация, и использование автоматов являются частными случаями метода исполнения моделей, основанного на виртуальной машине. Действительно, в первом случае этап трансляции является вырожденным, и внешнее представление модели одновременно образует последовательность команд для интерпретационной компоненты виртуальной машины. Не представляет большой сложности определить набор команд для представления автоматов, в таком случае этап трансляции модели в такую последовательность команд представляет собой ни что иное, как генерацию автоматов по модели. Таким образом, последний из представленных способов исполнения моделей является, очевидно, наиболее гибким.
Вызов виртуальной машины
Пожалуй, одним из наиболее полезных способов комплексирования виртуальных машин является вызов одной виртуальной машины из другой. При его реализации вызываемые и вызывающие машины могут как совпадать, так и существенно различаться по своей структуре. В наборе команд той виртуальной машины, из которой происходит вызов, выделяется команда или команды для порождения и вызова другой виртуальной машины. Порождённая машина получает ссылки на своё поле данных и последовательность команд, после чего запускается. Поведение вызывающей машины при этом может варьироваться: либо ожидание завершения вызванной машины, либо продолжение своего выполнения без ожидания завершения вызванной. Следует отметить, что вызовы могут быть многократно вложенными.Для иллюстрации вышесказанного рассмотрим две возможных реализации вызова виртуальных машин.
1. Виртуальные машины различны, имеют разные наборы команд и различную структуру области для хранения данных. Вызвавшая машина после осуществления вызова блокируется до окончания работы вызванной, после чего продолжает своё выполнение. Такой способ вызова полезен, например, при исполнении моделей на языке MSC 2000 [3], который имеет два уровня: HMSC (high-level MSC) и собственно MSC (message sequence charts — диаграммы последовательности сообщений). HMSC диаграмма представляет собой граф потока управления, в узлах которого помещены ссылки на MSC диаграммы. Таким образом, виртуальная HMSC машина будет являться вызывающей, а MSC машина — вызываемой.
2. Виртуальные машины имеют одинаковую структуру, работают с одним набором команд, но имеют отдельные экземпляры области данных. Вызвавшая машина не блокируется после вызова, а продолжает своё выполнение. Такая организация полезна для обработки альтернатив, которые часто встречаются во многих моделях и призваны отражать различные варианты поведения системы. Допустим, что в процессе своей работы виртуальная машина А1 дошла до такого места, где ей нужно обработать n альтернатив. В этом случае А1 создаёт n-1 своих копий А2, А3, … Аn. При этом копированию подвергается и поле зрения, поскольку предполагается, что до разветвления поведение всех машин было одинаковым. Таким образом, всего приходится по одной машине на каждую альтернативу, и каждая из машин продолжает своё выполнение в пределах назначенной альтернативы. Следует отметить, что с этих пор все машины действуют абсолютно независимо и ничего не знают друг о друге, хотя они и могут разделять один и тот же набор команд. Такой способ может быть применён для обработки альтернатив в языке MSC [3] на HMSC диаграммах и альтернативных выражений на самих MSC диаграммах. Данный пример поднимает ещё один важный вопрос об организации параллельной работы нескольких виртуальных машин.
Управление проектами - статьи
Базовые концепции и принципы модели процессов MSF
«Информационная работа – это работа мысли»Билл Гейтс. «Бизнес со скоростью мысли»
Единое видение проекта
Любой коллективный труд, а тем более такой нетривиальный как разработка и внедрения программного обеспечения, имеет мало шансов на успех, если все участвующие стороны не представляют (или еще хуже не правильно представляют) конечной цели проекта, иначе говоря, не имеют единого видения (shared vision) проекта. Все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат. Всем должна быть понятна цель проекта. Подход MSF не зря акцентирует внимание на этом, казалось бы, умозрительном принципе. На практике не всегда так просто обеспечить единое понимание целей и задач проекта. Зачастую эта единая цель вступает в противоречие с интересами некоторых участников проекта. Или эти участники видят выгоды только от одной подсистемы проекта, которая касается их непосредственно. Например, бывает очень тяжело на последних этапах проекта объяснить сотрудникам склада, зачем им вводить номер накладной на отпущенный товар. Им он не нужен. Зато он нужен бухгалтерии. Конфликт возникает, потому что кладовщики думали, что автоматизируют склад, а не предприятие в целом. Поэтому MSF выделяет в жизненном цикле проекта целую фазу для обеспечения единого видения проекта.Фаза планирования
Наступает важнейший этап разработки решения. Фаза планирования включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Всё начинается с анализа и документирования проектных требований с разделением их на категории: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования. Затем при создании функциональной спецификации нужно следить за соответствием (traceability) функциональности и существующих требований. Детализация требований происходит по известному всем аналитикам сценарию, прибегая к моделированию вариантов использования, (use - case modeling) и стори-боардингу (story-boarding), хотя у каждого опытного аналитика наверняка есть свой арсенал методов. Затем работа переходит в область проектирования (дизайна), где разрабатываются концептуальный, логический и физический дизайны, служащие уже инструментами для разработчиков. Результаты проектирования документируются в функциональную спецификацию, которая детально описывает вид и поведение всех составляющих решения. На основании спецификации работает команда разработчиков (с учётом синхронизации действий между собой), производится оценивание работ, достигается чёткое соглашение с заказчиком о том, что должно быть сделано. Как только создана спецификация, руководители ролевых кластеров смогут создать детальный план, относящийся к его роли. Примерами планов могут стать: план внедрения, план тестирования, план обучения, план мер безопасности и т.п. Затем проектная группа коллективно анализирует планы и выявляет зависимости между ними. Эти планы в последствии объединяются в сводный план проекта и сводный сетевой график работ. На этом же этапе создается также план управления рисками, к составлению которого есть смысл привлекать всех участвующих в проекте лиц.Завершается этап вехой «Планы проекта утверждены», на момент которой уже существуют документы: функциональная спецификация, план управления рисками, сводный план и сводный календарный график работ.
Основные задачи проектной группы на фазе планирования:
| Ролевой кластер | Фокус |
| Управление продуктом | Концептуальный дизайн; анализ бизнес-требований; коммуникационный план. |
| Управление программой | Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет. |
| Разработка | Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates). |
| Удовлетворение потребителя | Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение. |
| Тестирование | Оценка дизайна; требования тестирования; план и календарный график тестирования. |
| Управление выпуском | Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения. |
Фаза разработки
Название фазы говорит само за себя. Однако не стоит думать, что все остальные ролевые кластеры проекта на этой фазе могут пить кофе. Все роли принимают активное и деятельно участие в тестировании, выявлении дефектов, анализе удовлетворения нужд заказчика и других задачах в соответствии со своим ролевым кластером. Равно как и сама разработка, очень редко заканчивается этой фазой (да и начинается тоже редко только с этого момента), обычно разработка продолжается и на фазе стабилизации и даже на фазе внедрения иногда приходится что-то править. К моменту завершения этой фазы разработка всех компонент завершена и решение готово к комплексному тестированию.Задачи ролей во время этой фазы:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Ожидания заказчика. | ||
| Управление программой | Управление функциональной спецификацией; мониторинг проекта; доработка планов. | ||
| Разработка | Разработка программного кода и инфраструктуры; документирование конфигураций. | ||
| Удовлетворение потребителя | Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн. | ||
| Тестирование | Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования. | ||
| Управление выпуском | Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists). |
Рекомендуемые промежуточные вехи:
Фаза стабилизации
На фазе стабилизации фокус смещается в область тестирования и документирования решения. А также создание пилотного внедрения. Результатами этой фазы являются: окончательный продукт (golden release), документация выпуска, материалы поддержки решения, результаты тестирования, проектная документация и анализ пройденной фазы.Задачи проектной группы на этой фазе:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Исполнение коммуникационного плана; планирование премьеры продукта. | ||
| Управление программой | Мониторинг проекта; приоритезация ошибок. | ||
| Разработка | Устранение ошибок; оптимизация программного кода. | ||
| Удовлетворение потребителя | Доработка эксплуатационных руководств; учебные материалы. | ||
| Тестирование | Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации. | ||
| Управление выпуском | Развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения. |
Фаза внедрения
Наконец-то. Если проект докатился до этой фазы, то можно считать, что треть пути пройдена... Это конечно шутка, так быть не должно, хотя так бывает довольно часто, особенно если были допущены ошибки на начальных этапах проекта. На этом этапе группа внедряет решение, стабилизирует его и, пробиваясь сквозь противоборство службы сопровождения и поддержки, таки передает решение им, получив одобрение заказчика. И, наконец, получает вожделенный акт. Однако согласно MSF и вопреки реалиям работа группы на этом не заканчивается. Группа работает над сбором метрик и анализом проекта, дабы бесценный опыт, полученный в результате проекта, не канул в дебрях короткой памяти человеческой.Результатами фазы будут: информационные системы эксплуатации и поддержки, процедуры и процессы, базы знаний, отчёты, журналы протоколов, версии проектных документов, отчёт о завершении проекта, окончательные версии всех проектных документов, описание последующих шагов.
Задачи группы на фазе внедрения:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Получение отзывов и оценок заказчика; акт о приеме выполненной работы. | ||
| Управление программой | Сопоставление рамок проекта с поставленным решением; управление стабилизацией. | ||
| Разработка | Разрешение проблем; поддержка эскалации. | ||
| Удовлетворение потребителя | Обучение; управление календарным графиком обучения. | ||
| Тестирование | Тестирование производительности. | ||
| Управление выпуском | Управление внедрением; одобрение изменений. |
Не нужно также забывать, что после внедрения первой версии продукта, может последовать следующая итерация жизненного цикла.
Фаза выработки концепции
Это первая фаза жизненного цикла проекта. Начинается она с формирования ядра проектной группы (если конечно это первая итерация продукта). Затем закладывается основа, фундамент, будущего решения на основе единого видения проекта (ничем не ограниченное представление о целях и задачах, стоящих перед проектной группой). После этого очерчиваются рамки (чётко описанные задачи, которые предстоит решить), однозначно описывающие то, что предстоит сделать в рамках проектных ограничений, и оцениваются риски. Нельзя смешивать эти два понятия, но и нельзя рассматривать одно в отрыве от другого. Если программист будет создавать продукт, не владея документом единого видения (shared vision document) только на основании описания рамок (scope document), он вероятнее всего не сможет создать то, что ожидает заказчик, ведь основные цели, представления и ожидания заказчика сконцентрированы именно в документе единого видения. Оба эти документа должны создаваться итеративно и тщательно, минимизируя дальнейшие отклонения от них.Главной вехой этой фазы будет событие «Концепция утверждена». К этому моменту у заказчика и проектной группы уже сформированы устойчивые представления о задачах, функциональности и ограничениях проекта. К моменту этой вехи должны быть готовы следующие документы: общее описание и рамки проекта (vision \ scope document), документ оценки рисков, описание структуры проекта. Задачи проектной группы на этой фазе распределяются следующим образом:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта. | ||
| Управление программой | Цели дизайна; концепция решения; структура проекта. | ||
| Разработка | Прототипирование; анализ технологических возможностей; анализ осуществимости. | ||
| Удовлетворение потребителя | Необходимые эксплуатационные характеристики решения и их влияние на его разработку. | ||
| Тестирование | Стратегии тестирования; критерии приемлемости, их влияние на разработку решения. | ||
| Управление выпуском | Требования внедрения и их влияние на разработку решения; требования сопровождения. |
MSF рекомендует обозначить следующие промежуточные вехи в течение фазы:
Итеративный подход
Весь жизненный цикл проекта протекает в виде последовательности итераций выпуска версий. MSF рекомендует вкладывать в первую версию продукта только базовую функциональность и затем наращивать ее в следующих версиях. Для малых проектов иногда бывает достаточно одной итерации, однако все равно рекомендуется не упускать возможности версионирования т.к. это эффективный инструмент достижения успеха проекта.
Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации. Такой подход позволяет планировать возможности для последующих версий, делать учёт опыта предыдущих циклов, обеспечивая гибкость и устойчивость к переменам требований. Таким образом, обеспечивается ведение «живой» документации, которая изменяется по мере эволюции проекта. В рамках одной итерации все документы (равно как и программный код) тоже развиваются итеративно. Например, план тестирования или концепция проекта (shared vision document) распространяется среди всех ролей проекта в виде «подходов» (approaches) еще до утверждения и затем итеративно эволюционируют благодаря обратной связи участников проекта до формы, подлежащей утверждению. Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями, и часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии. Создание базовой версии всех проектных документов на самых ранних этапах дает возможность всем членам проектной группы осмыслить свои задачи и цели проекта, а так же приступить к работе с минимальными задержками.
Методология MSF рекомендует делать текущие сборки программных компонент решения. Это особенно важно в сложных комплексах, где необходимо учитывать и тестировать совместимость компонент. Для этих целей Майкрософт при разработке своих продуктов выполняет ежедневные билды (daily builds).
Разработка и тестирование ведутся практически одновременно, что увеличивает надежность результирующего кода. Для осуществления такого подхода к разработке необходимо вести управление конфигурациями проекта. Необходим строгий мониторинг и контроль версий программного кода, документации, аппаратных настроек и других артефактов проекта. Управление конфигурациями в свою очередь служит эффективным инструментом управления изменениями в проекте, которое регламентируют процесс внесения изменений в артефакты проекта от запроса на изменение, до включения его в базовую версию. Вот основные рекомендации MSF для выпуска версий решения:
Концентрация на бизнес-приоритетах
При создании любого решения необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить потребитель решения. Если проект нацелен на предприятие, то точкой концентрации будет бизнес-отдача (business - value). В отношении персональных программ, как, например, компьютерная игра, отдачу можно выразить в виде эмоционального удовлетворения потребителя. Можно сказать уверенно, что MSF не подходит для волонтёрских проектов, удовлетворяющих чьи-то амбиции или являющихся творческой отдушиной для разработчиков – творцов с рождения.Матрица компромиссов
Для эффективного достижения компромиссов в течение всего жизненного цикла проекта, MSF рекомендует на начальных этапах зафиксировать приоритеты факторов проекта (ресурсы, время, возможности). На один из факторов влиять в течение проекта будет практически невозможно (Фиксируется), - другой будет обладать некоторым приоритетом при разрешении компромиссов (Согласовывается) и оставшийся будет принят в соответствии с первыми двумя (Принимается).
Зафиксировать приоритеты в проектной документации можно с помощью простых текстовых оборотов: «Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения» или «Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки» и т.п. В дальнейшем возврат к приоритетам может сильно помочь при нахождении компромисса внутри проектной группы (обращаю внимание на то, что представитель заказчика тоже является членом проектной группы).
Модель проектной группы MSF
Вот здесь начинается самое интересное и, на мой взгляд, новаторское в подходе MSF. Этой теме уделена целая «белая книга» из пакета руководств MSF и здесь мы рассмотрим только основные подходы к построению проектной группы. Существуют основные принципы и концепции модели проектной группы, которые во многом являются чуждыми большинству IT компаний. Здесь разрушаются некоторые стереотипы (например, диктаторские полномочия и соответствующая ответственность менеджера проекта) и предлагается несколько иная, более органичная структура организации рабочих групп. Подход, по меньшей мере, весьма интересен.Проектная группа разделяется на шесть ролевых кластеров, соответствующих шести качественно различным задачам проекта.
Между этими кластерами образовывается устойчивый баланс ответственности и полномочий, позволяющий команде эффективно функционировать. Как я уже упоминал, существуют основные принципы модели проектной группы.
Таким образом, все ролевые кластеры в команде равноправны . Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды.
Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Что важнее решать вам – о управленец! Однако, по мнению Майкрософт, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца. Перечислю основные области ответственности ролевых кластеров.
| Управление продуктом |
Представление интересов заказчика; аналитика; обоснование бизнес-отдачи; формирование единого видения и рамок проекта; управление требованиями заказчика; определение приоритетов факторов (время/рамки/ресурсы); PR продукта; план коммуникаций. |
| Управление программой | Управление процессом разработки с целью получение продукта в рамках проектных ограничений; формулировка спецификации и разработка архитектуры; управление совещаниями и коммуникациями; формирует сводный план; управление рисками; сетевой график работ; отчётность. |
| Разработка | Определяет дизайн решения; оценка времени разработки; разработка; консультирование. |
| Тестирование | Планирование тестирования; тестирование. |
| Удовлетворение потребителя | Представляет интересы потребителя (на заказчика, а конечного пользователя системы); сбор требований потребителя; формирует требования к эргономике, справочной системе и учебным материалам. |
| Управление выпуском | Внедрение; обеспечение сопровождения; материальное обеспечение и логистика; инфраструктура поставок. |
Рассмотрим каждую из фаз жизненного цикла проекта подробнее.
MSF – философия создания IT-решений или голые амбиции лидера
, Softline Company (Киев)Статья была опубликована в журнале ИТ-менеджер www.it-manager.com.ua
MSF – симбиоз итеративного и фазового подхода
«Развитие, как бы повторяющее пройденные уже ступени,но повторяющее их иначе, на более высокой базе
(“отрицание отрицания”), развитие, так сказать,
по спирали, а не по прямой линии; — развитие скачкообразное,
катастрофическое, революционное…»
Подход, основанный на фазах и вехах
Что может быть ближе отечественной АСУшной душе, чем такой подход. Десятилетиями наши системы внедрялись поэтапно. Поковыряли ложкой в тарелке, что-то подправили, подмазали – совещание. Не годиться – на доработку. Подправили – совещание. После пятой фрикции (в лучшем случае) с горем пополам закрыли этап. И так далее. Нет-нет, мы не будем возвращаться в ностальгическое прошлое. Майкрософт не предлагает то же самое, только с перламутровыми пуговицами. В рамках одной итерации, жизненный цикл выпуска версии разбивается на пять фаз (выработка концепции (единого видения), планирование, разработка, стабилизация (тестирование), внедрение). Каждая фаза цикла заканчивается главной вехой (контрольной точкой). Соответственно главные вехи будут иметь названия: концепция продукта утверждена, планы продукта утверждены, разработка завершена, готовность решения утверждена, внедрение завершено. Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых кластеров (разработка, тестирование, внедрение, управление проектом и пр.).
В этой контрольной точке всплывают все противоречия и коллизии, возникшие за период фазы проекта. Хорошей практикой является не откладывание проблем до конца фазы, дабы не тратить время и нервы всех участников совещания в главной вехе (хотя на самом деле совещания может и не быть, а возможно просто рассылка и утверждение документов по электронной почте). В рамках фазы должны присутствовать промежуточные вехи, обозначивающие достигнутые промежуточные результаты. Например, на фазе разработки такими промежуточными вехами могут быть: билд n завершен, билд n +1 завершен и т.д. MSF дает определенные рекомендации (рассмотрены ниже) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вехи.
Поощряйте свободное общение
До сих пор большинство IT организаций ограничивает доступность к информации участников проекта исключительно необходимой для выполнения их работы или хотя бы пытается это делать, порождая недоверие внутри рабочей группы, но те, кому интересно всё равно узнают рано или поздно то, что им интересно. Методология MSF разрушает этот стереотип, поощряя свободное общение внутри проекта. Это заметно сокращает риск недопонимания, возникновения недоразумений и стимулирует максимальный вклад всех участников проекта в общее дело. Стоит заметить, что здесь не идет речь о финансовой или юридической информации, которая априори не может быть общедоступной. Зачастую разработчики не знают о проблемах возникающих у внедренцев, а тестирование не в курсе, что идет уже вторая неделя срыва сроков. Во избежание этого MSF предлагает проведение анализа хода работы над проектом в определённых временных точках, документирование результатов пройденных фаз проекта и обеспечение свободного общения в течение жизненного цикла проекта. Благодаря такому подходу обеспечивается выявление рисков всеми участниками проекта на ранних стадиях, что без сомнения вносит ощутимый вклад в успех решения.Проявляйте гибкость – будьте готовы к переменам
В отличие от традиционной модели управления проектами, в которой подразумевается четкая формулировка требований на начальном этапе проекта и разработка на основании ТЗ, подход MSF основывается на принципе изменяющихся проектных условий. Проектная группа должна быть готова к переменам и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.Методология очень интересна, если не
Подытожим. Методология очень интересна, если не сказать больше. Ее можно использовать как эффективный инструмент, подходя к нему с творческой изобретательностью и осмысленностью. Нет, наверное, такой методологии управления, строгое соответствие которой, обеспечит успешность проекта. Не нужно воспринимать MSF как догму или панацею. Можно её адаптировать под свои нужды или использовать только фрагменты или концепции применимые в Вашем проекте.Например, в качестве дополнительного фактора проекта при поиске компромисса (наравне с ресурсами, временем и возможностями) может выступать безопасность или можно добавить дополнительную промежуточную веху «Контроль безопасности» в конце каждой фазы проекта, если того, конечно, требует ваша проектная среда.
Удачных проектов!
Создавайте базовые версии
Под базовой версией в MSF подразумевается зафиксированное состояние любого проектного артефакта (а лучше всех одновременно) в том числе программный код, план проекта, руководства пользователя, настройки серверов и т.п. В последствии, имея базовые версии, вы сможете эффективно управлять изменениями, вернуться на шаг назад, если это необходимо и выполнять аналитику по завершению проекта.Треугольник компромиссов
Часто бывает очень полезно изобразить эту зависимость заказчику в виде треугольника компромиссов
После достижения утвержденного равновесия с заказчиком, т.е. на запрашиваемые возможности вы назвали и зафиксировали сроки и смету, любое изменение на одной из сторон треугольника влечет изменение на двух оставшихся. Такой подход служит удобным инструментом для нахождения компромиссов с заказчиком и поможет объяснить суть имеющихся ограничений. Иногда имеет смысл добавлять еще четвертое измерение – качество, за счёт которого можно сэкономить время и ресурсы при неизменных возможностях, хотя, на мой взгляд, это последнее на чём стоит экономить. Однако отечественные реалии диктуют свои законы и не редки случаи, когда важен сам факт внедрения и заниженная планка качества решения (quality bar) всех устраивает. В таких случаях участники проекта должны, по крайней мере, знать об этом, и этот факт должен найти адекватное отражение в проектной документации (например, отсутствие дизайнерского оформления интерфейса или ведения журнала операций пользователя в системе).
Управляйте компромиссами
Наверное, не было еще ни одного менеджера проекта, которому не приходилось бы бороться с разрастанием рамок проекта и, как следствие, с перерасходом средств и затягиванием сдачи. Настоящим искусством менеджера является элегантное нахождение компромисса между ресурсами проекта (людскими, финансовыми и пр.), календарным графиком (временем) и реализуемыми возможностями (рамками).в чём угодно, но уж
|
"Царь Вызывает антирес Ваш технический прогресс: Как у вас там сеют брюкву С кожурою али без?.. Посол Йес!" Л. Филатов "Сказ про Федота-стрельца..." |
Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление. В руководствах по MSF кроме методов, моделей и концепций встречаются практические советы и приёмы, отнюдь не лишенные рациональности. Структурно пакет руководств MSF разделён на пять документов, так называемых «белых книг», каждый из которых охватывает определенную дисциплину или модель MSF : «Модель процессов MSF», «Модель проектной группы MSF», «Дисциплина управления проектами MSF», «Дисциплина управления рисками MSF» и «Дисциплина управления подготовкой MSF». Эта статья посвящена в большей степени первой книге «Модель процессов MSF», в которой будет рассмотрена модель жизненного цикла IT -проекта, а также базисные концепции и принципы методологии MSF.
Предметной областью рассматриваемой методологии является IT -проект (разработка ПО, внедрение/адаптация уже разработанных систем, разворачивание сетевой инфраструктуры или всё вышеперечисленное в комплексе). На мой взгляд, возможность применения данной технологии возникает в любом проекте, в котором задействовано более 4-6 человек. Итак, на чём же зиждется успех гиганта?
в которых может отсутствовать фаза
Существуют проекты, в которых может отсутствовать фаза внедрения или разработки (например, разработка игры, или адаптация 1С).В первую очередь реализовуйте рискованные нововведения, минимизируя влияние риска на весь проект.
Деятельность каждой фазы не ограничивается ее рамками, как было уже сказано, разработка продолжается почти всегда.
Длительность фаз может быть совсем не одинакова, как изображено на картинках (суть это замечания взята с текста MSF, я бы в жизни не догадался его написать).
Управление проектами - статьи
ЧТО ПЕРВИЧНО - ПРОЦЕССЫ ИЛИ ПО? ВАЖНО ОПРЕДЕЛИТЬ КРИТЕРИИ
Когда речь заходит о решении данного вопроса в применении к конкретной организации, то, прежде всего, необходимо определить критерии, в соответствии с которыми выбирается «сценарий» создания АСУП. Очевидно, что эти критерии во многом соответствуют факторам, определяющим объем и подходы к проведению внедрения. Но наиболее значимым критерием, оказывающим максимальное влияние как на состав этапов внедрения, их очередность и процесс создания АСУП в целом, по нашему мнению, является квалификация персонала. Под этим понимается как квалификация собственно (далее персонал организации), так и квалификации участников команды проекта внедрения. Два этих понятия взаимосвязаны, так как персонал организации либо частично, либо полностью может представлять команду проекта внедрения.ФАКТОРЫ, ВЛИЯЮЩИЕ НА ОБЪЕМ И ПОДХОД К ПРОВЕДЕНИЮ ВНЕДРЕНИЯ
В рамках оценки готовности организации к внедрению проводится анализ ряда факторов, которые, в свою очередь, оказывают влияние на объем внедрения, состав его этапов и их очередность. Среди таких факторов можно выделить следующие:Перечисленные выше факторы различны по своей сути и влиянию на процесс внедрения ПО и подходы к его проведению. Наиболее значимым из них является квалификация персонала организации, которые в дальнейшем войдут в состав команды проекта внедрения. Чем выше квалификация персонала, тем большую часть внедрения ПО, а значит и создания АСУП, организация может выполнить самостоятельно. В свою очередь, такие факторы, как диверсифицированность организации, территориальная распределенность участников проектов, реализуемых в организации, могут определить содержание и объем работ по пилотному проекту, что повлияет на продолжительность внедрения в целом.
Так или иначе, результат анализа факторов позволит определить степень участия внешней консалтинговой фирмы в реализации проекта создания АСУП. Данная степень может быть:
С точки зрения консалтинговой фирмы в первом случае речь идет о таком называемом «быстром внедрении», во втором - о полномасштабном внедрении (Рис. 1).
Рисунок 1. Виды внедрений, в зависимости от степени участия консалтинговой фирмы во внедрении2
Возможны также и промежуточные варианты. В любом случае, на выходе процесса создания внедрения ПО должна быть настроенная АСУП, отвечающая заранее сформулированным требованиям. Кроме того, не стоит забывать, что даже в процессе полномасштабное внедрения персонал организации не остается в стороне. Он должен принимать активное участие в большинстве вопросов, связанных с настройкой будущей системы. Ведь в конечном итоге система управления всего лишь инструмент. И настраивается он именно под организацию, а значит, должен максимально учитывать ее специфику. Это позволит в дальнейшем использовать систему управления для решения стоящих перед организацией задач наиболее эффективно.
КВАЛИФИКАЦИЯ КОМАНДЫ ПРОЕКТА ВНЕДРЕНИЯ
Одно дело определить состав этапов внедрения и их очередность, сформировать предварительный план внедрения, другое дело – его реализовать. Как правило, для создания АСУП формируется команда проекта внедрения (далее команда проекта). Ее состав во многом определяется опять же квалификацией персонала организации. Если она высока, то команда проекта может быть целиком составлена из сотрудников организации. В противном случае в состав команды проекта должны войти, как минимум, представители консалтинговой фирмы. В любом случае, на стадии формирования команды проекта необходимо помнить, что ее квалификация и слаженная работа всех ее участников является одним из важнейших условий успешного создания АСУП. Иными словами, содержание и объемы внедрения определяют требования к участникам команды проекта и их квалификации. Среди этих требований можно выделить такие, как:Например, опытная консалтинговая фирма может использовать наработки по предыдущим проектам в виде типовых бизнесс-процессов, использование которых позволит сократить общую продолжительность создания АСУП.
Существуют различные рекомендации по повышению квалификации команды проекта. Например, для осуществления какого-либо проекта может быть привлечена высококвалифицированная управляющая компания, которая принесет с собой собственную автоматизированную или неавтоматизированную систему управления, и заставит организацию стать ее активным участником. В данном случае необходимо всегда помнить, что управляющая компания может рано или поздно уйти, и организация останется без системы управления.
Проект внедрения представляет собой такой же проект, как и все остальные. Соответственно, для его управления подходят все существующие методики в области управления проектами.
Итак, содержание проекта внедрения известно и команда проекта сформирована. Соответственно, можно сформировать структуру декомпозиции работ (далее СДР) по созданию АСУП. Следующим действием должно явиться закрепление ответственных из числа команды проекта за те или иные пакеты работ из состава СДР – формирование так называемой матрицы ответственности. Ускорить выполнение данной задачи можно с использованием программного продукта Project Manager (далее РМ) серии Primavera Enterprise разработчика фирмы Primavera Systems (Рис. 2).
Рис. 2. Матрица ответственности проекта внедрения АСУП
В дальнейшем формируется укрупненный план создания АСУП, за работами которого закрепляются в виде ресурсов участники команды проекта внедрения в соответствии с их ролями в проекте (Рис. 3).
КВАЛИФИКАЦИЯ ПЕРСОНАЛА
Рассмотрим влияние квалификации персонала на создание АСУП. Чем выше ее уровень, тем большую часть внедрения организация в состоянии выполнить самостоятельно. В организациях, обладающих высококвалифицированным персоналом, как правило, деятельность построена на отработанных бизнесс-процессах, позволяющих успешно функционировать в условиях конкуренции. Эти бизнесс - процессы могут быть даже не задокументированны и не формализованы. Но в данном случае это не должно явиться помехой на пути внедрения. Каждый сотрудник знает, за что отвечает, какую информацию и когда должен предоставлять и т.д. Последующая настройка ПО позволит ускорить процессы обработки и передачи информации. Возможно, в дальнейшем потребуется разработать несколько регламентов и инструкций для работы сотрудников в АСУП. Но опять же, за счет высококвалифицированного персонала организация выполнит это самостоятельно. Как правило, объем услуг консалтинговых фирм в подобных внедрениях невелик и ограничивается поставкой и инсталляцией ПО, а также обучением сотрудников организации.В то же время, если по результатам оценки готовности организации ко внедрению выявляется необходимость участия консалтинговой фирмы собственно в разработке АСУП, то на первом этапе проводится обследование и описание существующих бизнесс-процессов. При этом в качестве объектов обследования в большей степени выступают бизнесс-процессы управления, связанные с предоставлением, обработкой и анализом информации. На следующем этапе производится построение оптимизированных бизнесс-процессов с выделением из них автоматизируемых. На выходе должны быть модель функционирования АСУП, позволяющая:
Только после этого проводится настройка ПО. За кадром остались не менее важные этапы, такие как фиксирование требований к АСУП в виде технического задания, формирование команды проекта внедрения.
Итак, квалификация персонала организации влияет на степень участия консалтинговой фирмы во внедрении. В то же время, от уровня квалификации персонала зависит и объем внедрения. Рассмотрим это на следующем примере.
Как уже было сказано выше, процессы в организации желательно документировать. Для этого рекомендуется использовать два типа документов, такие как регламенты и инструкции. Регламенты описывают процесс взаимодействия различных исполнителей в процессе реализации той или иной управленческой функции в рамках системы управления. Инструкции же описывают либо конкретные действия отдельных исполнителей на рабочих местах в ПО системы управления, либо отдельные операции того или иного процесса. Таким образом, инструкции детализируют регламенты. Как показывает практика, чем выше квалификация персонала, тем в меньшей степени требуется разработка инструкций. И, следовательно, объем работ по внедрению сокращается.
ОПИСАНИЕ БИЗНЕСС-ПРОЦЕССОВ И ПО
С методологической точки зрения, для успешного функционирования системы управления разработка бизнесс-процессов должна предшествовать настройке ПО. Отработанные и регламентированные бизнесс-процессы во многом сами по себе гарантируют слаженную работу предприятия, образуя некую внутреннюю системы управления. Каждое подразделение выполняет свои функциональные обязанности, предоставляя информацию руководству для принятия управленческих решений и координации работы предприятия. Дальнейшая автоматизация ряда рутинных бизнесс-процессов за счет использования ПО лишь позволяет дополнительно ускорить их выполнение.В связи с этим большим заблуждением является мнение, что ПО может решить все внутренние проблемы на предприятии. А, как правило, причины этих проблем заключаются в отсутствии бизнесс-процессов, отвечающих существующим требованиям рыночных отношений. Находясь под влиянием такого подхода, руководители не уделяют должного внимания анализу и оптимизации существующих бизнесс-процессов на предприятии. В результате ПО выходит на первый план и автоматизируется существующий «беспорядок». Процессы управления, несмотря на то, что уже автоматизированные, по сути остаются прежними. Как следствие, руководство предприятия не получает ожидаемой отдачи от АСУП.
Особенно важную роль описание бизнесс-процессов играет в случае создания АСУП на базе разрабатываемого ПО, или если в рамках создания АСУП предполагается осуществление интеграции между различными информационными системами. В первом случае крайне необходимо разработать бизнесс-процессы, максимально отвечающие требованиям к АСУП, так как от этого будет напрямую зависеть эффективность использования ПО. Во втором случае без описания процессов, заложенных в две смежные интегрированные информационные системы, и процесса обмена информацией между ними, практически невозможно приступить к разработке интеграционного модуля. И в том, и в другом случае качество описания процессов закладывает фундамент под дальнейшие работы по разработке ПО или интеграционных решений, внося свой вклад в эффективное функционирование АСУП в целом.
Внедрение систем управления. Что вначале - процессы или ПО?
К.В. Халимов, ЗАО "ПМСОФТ",М.В. Резник, ЗАО "ПМСОФТ"
В последнее время все большее
В последнее время все большее число предприятий осознают необходимость создания автоматизированных систем управления проектами (далее АСУП). При этом первым и необходимым условием для успешной реализации проекта создания АСУП является наличие у руководства организации заинтересованности в будущей системе и четкого понимания целей, для достижения которых она создается. Это значительно упростит процесс формирования требований к системе.Создание любой АСУП в организации связано с решением ряда основных задач, таких как выбор программного обеспечения (далее ПО), его поставщика и внедрение ПО. При этом последняя задача является наиболее трудоемкой и значимой в рамках процесса создания АСУП. Для ее успешного решения очень важно на стадии подготовки к внедрению оценить, насколько организация готова к его проведению и по возможности сформировать предварительный перечень этапов внедрения. Это поможет составить представление об объеме будущих работ. Результатом оценки является принятие решения о начале внедрения или временной задержке в его проведении, и определение степени участия внешней консалтинговой фирмы в его реализации.
Управление проектами - статьи
Моцарт и Сальери
Гуру программирования Ф. Брукс в 1975 году писал []: «Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов». Некоторые психологи, которые работают с программистами, идут дальше и даже утверждают, что программирование – это высшая форма творчества [].Творчество - это интеллектуальная деятельность человека, законы которой нам неизвестны. Если бы мы знали законы творчества, то и картины, и стихи, и музыку, и программы уже давно бы создавали компьютеры. Творческое начало это то, что роднит программирование с наукой и искусством.
Творчество в программировании начинается с определения целей программы и заканчивается только тогда, когда в ее коде, написанном на каком-либо языке программирования, поставлена последняя точка. Попытки разделять программистов на творческую элиту, архитекторов и проектировщиков, и нетворческих программистов-кодеров не имеют под собой объективных оснований. Даже если алгоритм программы строго определен математически, два разных программиста его закодируют по-разному, и полученная программа будет иметь разные потребительские качества 4.
Факт 1. Программирование было, есть и останется в обозримом будущем творческой деятельностью.
Творчество неразрывно связано с вдохновением, а это субстанция капризная и непредсказуемая (помните знаменитый сон Д. И. Менделеева, про Периодическую таблицу элементов его имени?). Знаю только, что без вдохновения в программировании не обойтись. И чем сложнее задача, тем труднее извлечь это вдохновение из подсознания. Иногда для этого требуются часы, а иногда недели 5.
Программирование это не искусство, в том смысле, что оно не является творческим отражением и воспроизведением действительности в художественных образах. Об искусстве в программировании можно и должно говорить только в смысле умения, мастерства, знания дела, как и в любой другой профессии.
И как в любой другой профессии программистское мастерство может доставлять истинное эстетическое наслаждение, но только для людей, причастных к этой профессии 6.
Программирование это не наука. Наработки математиков в области логики, теории информации, численных методов, реляционной алгебры, теории графов и некоторых других дисциплинах на долю процента не покрывают сложность программистских задач. В программировании нет системы знаний о закономерностях создания программ. Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны - источники серьезных будущих проблем. Но не более того. Существующее состояние Software Engineering напоминает мне большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых у меня никогда в будущем не будет. Завтра в моей новой системе будут другие вычислительные машины, технологии, языки программирования, инструменты и окружающее ПО, новые проблемы взаимодействия с которыми мне обязательно придется решать.
Факт 2. Программирование - не искусство и не наука – это ремесло. Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.
А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского. Путь к мастерству в ремесле лежит только через опыт. Нельзя научиться программированию, читая книги. Как нельзя по книгам научиться писать романы, картины, стихи, музыку. А еще программистам нужен постоянный труд самоусовершенствования и саморазвития. Поэтому далеко не все, кто пишет программы, становятся профессионалами.
Факт 3. Производительность труда программистов с одинаковым уровнем знаний и опытом в обозримом будущем, по-прежнему, будет отличаться на порядок.
Более того, производительность одного и того же программиста в течение проекта будет так же отличаться на порядок даже при решении сходных по сложности задач.
Хотите, меряйте производительность в строках исходного кода, хотите – в функциональных точках.
Почему-то, если мы говорим о поэтах, художниках, композиторах, то разброс творческой производительности никого не удивляет. «Творческий полет», «творческий застой» - это про деятелей искусства. А когда говорим о неравномерности производительности программистов, то многие менеджеры начинают с этим спорить, и пытаются «пинать» программистов, как будто это заставит их думать быстрей. Не заставит. Но может заставить уйти или заняться имитацией работы.
Профессиональное творчество программиста принципиально отличается от творчества в науке и искусстве. Программистские задачи с каждым годом становятся все сложнее и объемнее, а сроки, за которые требуется решить эти задачи, наоборот, с каждым годом сокращаются. Поэтому современные программы создаются коллективами от нескольких до тысяч программистов, в то время как творческие деятели науки и искусства работают, как правило, в одиночку.
Правда существует еще прикладная наука, космонавтика, авиастроение, автомобилестроение и другие высокотехнологичные отрасли промышленности, в которых над созданием новых изделий трудятся сотни тысяч человек. Очень велик соблазн провести аналогию с этими отраслями и говорить об индустриальном подходе к разработке ПО. Не получается.
Упрощенно, путь от идеи до ее реализации в этих отраслях выглядит следующим образом: НИР-ОКР-завод. В верхней части этой пирамиды находятся отраслевые НИИ, которые производят идеи и занимаются проектированием новых изделий. На втором этаже пирамиды работают конструкторы в конструкторских бюро, в задачу которых входит реализация нового проекта в чертежах деталей и технологиях изготовления и сборки. На нижнем уровне находятся производственные мощности - заводы, на которых инженеры и рабочие воплощают «в железе» чертежи и технологии.
Если проводить аналогию, то программисты работают исключительно на вершине описанной пирамиды. Программирование – это проектирование и только проектирование. Роль конструкторского бюро для программного проекта выполняют компилятор и сборщик программ. А программистским аналогом завода, который переводит конструкторскую документацию в продукт, доступный потребителю, служит вычислительный комплекс, на котором выполняется созданная программа.
А теперь давайте вспомним, сколько НИР так и остались на бумаге, не дойдя до ОКР, и сколько еще ОКР закончилось закрытием тематики. Я думаю, что процент инноваций, дошедших до производства от общего числа проектов, выполненных в отраслевых НИИ, будет сравним с процентом успешных программных проектов. И давайте еще учтем, что ученые в НИИ опираются на достаточно хорошо изученные законы математики, физики и химии, а программирование, как мы отмечали выше, пока остается лишь ремесленным производством.
Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля. Я полагаю, что количество провальных проектов в этих областях ничуть не меньше, чем в программировании. Дай Бог, если хотя бы пятая часть кинофильмов не «ложится на полки» после первого показа.
И еще одна аналогия программных проектов с кинематографом. Наличие даже самых звездных актеров не обеспечивает успех фильма. Только талантливый режиссер способен организовать и вдохновить актеров на создание шедевра, открыть новые звезды. А талантливых режиссеров, как, впрочем, и талантливых менеджеров программных проектов, к сожалению, не так много, как хотелось бы.
Факт 4. В обозримом будущем большая часть проектов разработки ПО будет завершаться со срывами сроков и перерасходом бюджета, часть проектов не будет завершена вообще, и только приблизительно 20% проектов будут укладываться в первоначальный бюджет и сроки.
Бизнесмены должны помнить, что инвестиции в разработку ПО в обозримом будущем по-прежнему будут связаны с высокими рисками.
Но риски компенсируются тем, что прибыли от одного успешного проекта могут порой покрыть убытки от десятков менее удачных.
Есть еще нечто, что отличает труд профессионального программиста от ученого, художника, композитора и поэта. Предметом деятельности ученых являются упрощенные модели, в которых они могут абстрагироваться от большинства деталей реального мира, не существенных для их целей. Математик, доказывая новую теорему о тензорах, не заботится ни о чем, кроме системы постулатов, положенных в основание дифференциальной геометрии. Физик, описывая динамику жидкости в трубе, абстрагируется от того, как движутся и сталкиваются молекулы и от того, как движутся планеты вокруг Солнца. Деятели искусства тоже во многом оперируют абстракциями. Поэту, композитору, художнику достаточно лишь сделать намек, абрис объекта творчества, и на этом его работа закончена. Остальное пусть додумывает читатель, слушатель, зритель.
Программист тоже работает с абстракциями, но ему приходится держать в голове гораздо больше абстракций, чем любому ученому. Абстракции сопутствуют программисту на всех уровнях разработки программы от описания ее целей до исполняемого машинного кода. И этих уровней могут быть десятки. И на каждом уровне абстракций их деталей становится все больше и больше.
Дополнительно к абстрактному мышлению, программист должен обладать сильно выраженным системным мышлением, чтобы удерживать многочисленные взаимосвязи, существующие на всех уровнях программистских абстракций, а также взаимосвязи между этими уровнями. Еще одной сложностью является то, что все эти абстракции и взаимосвязи между ними изменяются во времени, и программист должен учитывать эту динамику.
Кроме того, программист должен обладать маниакальной усидчивостью, сосредоточенностью и упорством для перебора всех возможных вариантов поведения своих абстракций и доскональной проработки всех деталей. 7 Проработка должна быть абсолютно точной и не должна содержать ни одной ошибки, неправильного, лишнего или отсутствующего символа исходного кода (а это порой сотни тысяч строк).
Инструменты программирования: синтаксические анализаторы, компиляторы и проч., - лишь незначительно помогают в этой работе.
Еще одна особенность, которая присуща программистскому творчеству, это постоянное обновление информационных технологий 8, которые программисту необходимо знать и успешно применять в своей работе. Поэтому профессиональный программист должен, как сказал один из наших прежних вождей 9, «учиться, учиться и учиться». Программист должен удерживать в голове, постоянно пополнять и активно применять на практике гигабайты профессиональной информации. Это устройство компьютеров, компьютерных сетей и сетевые протоколы. Это операционные системы и языки программирования. Это программные интерфейсы промежуточного ПО и прикладных библиотек с особенностями и багами их реализации в конкретных продуктах. Это технологические стандарты, технологии разработки и инструменты, которые их поддерживают. Это архитектуры программных систем, паттерны и антипаттерны проектирования и много-много другой информации.
Еще в начале 70-х замечательный ученый академик А.П.Ершов сказал: “Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста”.
Образно можно сказать, что программист должен сочетать в себе легкость и полет таланта Моцарта с усидчивостью и скрупулезностью Сальери.
Описанные психологические особенности программистского творчества привели к тому, что наиболее успешными программистами становятся люди, которые обладают выраженным аутистическим складом мышления. Аутистическое мышление (от древнегр. autos — сам) — замкнуто-углубленный тип личности. Применительно к личности используется также термин «шизоид».
Факт 5. Аутист-шизоид – наиболее распространенный среди программистов тип личности.
Мы, программисты, все немного шизоиды 10.
По неофициальным данным [], в компании «Майкрософт» число аутистов среди сотрудников составляет от 5 до 20%. Аутизм это не болезнь! Мы просто не такие как остальное большинство, которое не готово сутками проводить время за мониторами компьютеров и получать от этого удовольствие. И, пожалуйста, не надо нас лечить и переделывать! Это удача для человечества, что рождаются аутисты. Так, по результатам исследований процент гениев (то есть людей, способности которых существенно выше средних) среди людей с диагнозом "аутизм" достигает 20%. В то время как среди так называемых "нормальных" людей он не превышает 0,001%. Психологи считают аутистами таких известных исторических личностей, как Ньютон, Эйнштейн, Гегель, Фрейд, Юнг, Агата Кристи и даже любимый Пушкин 11.
Аутизм сейчас популярная тема не только среди профессиональных психологов, но и в обществе. Про аутистов даже сняты художественные фильмы: «Человек дождя» и «Меркурий в опасности». Поэтому позволим себе отослать заинтересовавшегося читателя к многочисленным профессиональным и не очень источникам информации, которые в большом числе присутствуют в Интернете. Остановимся только на тех качествах шизоидного типа личности, на которые мы будем ссылаться в дальнейшем.
? Они ориентированы на свой внутренний мир, а не на окружающих их людей, они с трудом идут на установление контактов с другими людьми, их реакции часто необычны и непонятны окружающим, а привычки и пристрастия - устойчивы и с трудом поддаются изменению.
? Для них характерно сочетание противоречивых черт в личности и поведении: холодности и утонченной чувствительности, упрямства и податливости, настороженности и легковерия, апатичной бездеятельности и напористой целеустремленности, необщительности и неожиданной назойливости, застенчивости и бестактности, чрезмерных привязанностей и немотивированных антипатий, рациональных рассуждений и нелогичных поступков, богатства внутреннего мира и бесцветности его внешних проявлений.
? Они могут повторять одно и то же действие снова и снова.
Они хотят жить так, чтобы в окружающем их мире ничего не изменялось и чтобы события всегда происходили в привычном для них порядке. Даже незначительное изменение в этом порядке их очень расстраивает.
? На работе они часто неуправляемы, так как трудятся, исходя из собственных представлений о ценностях в жизни. Однако, в определенных областях, где требуется художественная экстравагантность, одаренность, нестандартность мышления, символизм, они могут достичь многого.
"Аутист видит в компьютере близкое существо, – считает Эми Клин, ассистент профессора Центра детского развития при Медицинской школе Йельского университета. – Компьютеры бескомпромиссны и негибки, а люди, с которыми нам приходится иметь дело, отличаются теми же качествами". Аутизм ограничивает способность таких людей к общению, но вознаграждает их даром невероятной концентрации и творческой продуктивности [].
Аутистическая природа программирования это не просто еще один факт, а, по-видимому, самый важный из всех фактов, которые необходимо учитывать, если мы хотим успешно производить программное обеспечение.
Каждый программный проект это потенциальная катастрофа. И если мы не будем постоянно прилагать усилия к тому, чтобы этой катастрофы избежать, мы неотвратимо к ней придем. Мы подробно писали о специфической сложности программных проектов и непредсказуемости их главной составляющей – программистов. Что же позволяет нам при разработке ПО с уверенностью смотреть в завтрашний день? Ответ прост – управление на макро уровне. В статистической динамике газа мы абстрагируемся от броуновского движения каждой из молекул и оперируем усредненными характеристиками: скорость потока, температура, давление. Аналогично, в программном проекте мы можем в разы ошибиться при оценке трудоемкости реализации каждого отдельного функционального требования. Но наши ошибки будут как в меньшую, так и в большую сторону. Поэтому для проекта в целом они будут компенсироваться 12. В моей практике ошибка суммарной трудоемкости проекта составляет не более 30%.
Производительность участников проекта также может отличаться в разы, но средняя производительность по всем участникам вещь достаточно стабильная и прогнозируемая. По моему опыту оптимальное с точки зрения макроуправления количество человек в группе разработчиков – 4-6. Если проект большой, то необходимо провести его архитектурную декомпозицию на минимально связанные подсистемы, разработку которых следует вести отдельными группами со своими руководителями и планами.
Задачей любого управления является достижение некоторой цели. В нашем случае целью управления является успешное завершение проекта. Если кто-то думает, что успех проекта это реализация в программе 100% требований к назначенному сроку и в пределах выделенного бюджета, то это не так. Успех проекта живет в головах людей. Успех это в первую очередь чувство удовлетворения заказчика 13. Но не только. Успех это еще и чувство удовлетворения людей, которые выполняли проект. Вряд ли стоит называть проект успешным, даже если заказчик остался доволен его результатами, но при этом из компании ушли все профессионалы, участвовавшие в этом проекте. Я сознательно не касаюсь здесь вопросов экономической эффективности проекта и не потому, что «джентльмены о деньгах не говорят», а потому, что это самостоятельный и непростой вопрос совсем из другой области.
Факт 6. Цель управления программным проектом лежит в области психологии.
В каждом программном проекте десятки процессов: бизнес-анализ, планирование, проектирование, кодирование, конфигурирование, документирование, тестирование, внедрение, сопровождение и много чего еще. Эти процессы могут быть определены, документированы и даже нормированы, а могут быть, и нет. Но менеджер проекта не управляет процессами, он управляет лишь людьми, которые эти процессы выполняют. А управлять людьми можно только, ставя им правильные цели и мотивируя людей на их достижение. А оценка и мотивация людей - это опять в чистом виде психология.
Факт 7. Средства управления программным проектом лежат в области психологии.
То, что важным фактором программистского проекта является психология, начали писать более 30 лет назад, книги Венберга [] и Де Марко [] ничуть не утратили своей актуальности и сегодня. Но понимание того, что психология является решающим фактором успеха или неуспеха проектов разработки ПО, пришло только в последние годы. Радикальным решением проблем кризиса программирования поочередно объявлялись поиск лучшего языка программирования (1960-е годы), технологии программирования (1970-е годы), инструментария программирования (1980-е годы), системы качества (1990-е). И только центральному и ключевому фактору - фигуре самого программиста - внимание почти не уделялось [].
«Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте». Это вывод Алистэра Коуберна [], который базируется на результатах анализа очень разных программных проектов, реализованных за последние 20 лет. Проекты отличались друг от друга по количеству программистов, по срокам выполнения, по применяемой технологии - от самой тяжелой (CMM 5-го уровня) до полного ее отсутствия. Коуберн не обнаружил статистически значимой корреляции успеха или неуспеха проекта ни с одной из перечисленных характеристик.
Не правы те, кто утверждает, что нет разницы между управлением программными проектами и проектами в любой другой отрасли промышленности, например, в строительстве или авиастроении. Разница есть и она принципиальная.
Факт 8. Основная сложность управления программными проектами заключается в противоречии между коллективным характером труда и аутистической природой программирования.
О чем и зачем
Почему эссе? Потому, что этот материал на достаточно частную тему – психологические аспекты управления программными проектами. Потому, что трактовка рассмотренных вопросов отражает субъективный опыт автора и не претендует на полноту.Для чего написана эта статья? Для того чтобы обнародовать еще одну попытку ответить на традиционные для России вопросы: «кто виноват?» и «что делать?». Вдруг кто-нибудь еще не знает правильных ответов? 1
Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» [] пришла к следующим неутешительным выводам.
«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%»?
Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?
Начну сразу с ответов.
Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».
Что делать? Управлять людьми. Успех, а равно и провал, проектов по производству ПО на 100% лежит в области психологии.
Все, что написано далее, посвящено не тому, чтобы доказать или обосновать приведенные выше выводы (автор осознает непосильность для себя подобной задачи), а тому, чтобы поделиться с заинтересовавшимся читателем теми жизненными наблюдениями, которые, в конце концов, привели к данным выводам.
Впрочем, совсем уж субъективные иллюстрации из личного опыта, которые, на мой взгляд, могут быть опущены без ущерба для понимания остального содержания статьи, выделены мелким шрифтом и оформлены в виде сносок.
Как должно солидным людям, давайте договоримся о понятиях. Поскольку была выбрана форма эссе, а не академической монографии, то автор может позволить себе вольность и дать свои определения терминов, которыми нам предстоит оперировать, не приводя многочисленное цитирование первоисточников и углубленный анализ различных трактовок понятий. 2 Разумеется, это не мои определения, а то, что сложилось и укрепилось в голове под влиянием многих авторов за годы программирования.
Программирование - процесс отображения определенного множества целей на множество машинных команд и данных, интерпретация которых хотя бы на одном компьютере обеспечивает достижение поставленных целей.
Цели могут быть любые: воспроизведение звука в динамике ПК, расчет траектории полета космического аппарата на Марс, печать годового балансового отчета и т.д. Важно то, что они должны быть определены. Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели 3.
Это отображение может быть очень простым, например, перфорирование машинных команд и данных на перфокартах. А может быть многоступенчатым и очень сложным, когда сначала цели отображаются на требования к системе, требования – на высокоуровневую архитектуру и спецификации компонентов, спецификации - на дизайн компонентов, дизайн - на исходный код. Далее исходный код при помощи компиляторов и сборщиков отображается на код развертывания, код развертывания – на вызовы функций ПО окружения (ОС, промежуточное ПО, базы данных), которое может располагаться на множестве компьютеров, объединенных в сеть, и только после этого – в машинные команды и данные.
Профессиональное программирование (синоним производство программ) – деятельность, направленная на получение доходов при помощи программирования.
Принципиальным отличием от просто программирования является то, что имеется или, по крайней мере, предполагается некоторый потребитель, который готов платить за использование результатов программирования. Отсюда следует важный вывод о том, что производство программ это всегда коллективная деятельность, в которой участвуют минимум два человека: программист и потребитель.
Профессиональный программист – человек, который занимается профессиональным программированием. Профессионального программиста следует отличать от профессионала (мастера в программировании). Разброс профессионального мастерства в программировании достаточно широк и далеко не каждый, кто зарабатывает на жизнь программированием, является мастером, но об этом позже.
Обозримое будущее – ближайшие 5-10 лет, на которые автор готов экстраполировать действие закономерностей и выводов, изложенных в статье. Возможно, что за это время удастся осуществить прорывы или в искусственном интеллекте, или в теории доказательства правильности программ, которые могут революционно изменить состояние дел в программировании.
Резюме. Растите профессионалов
Работа менеджера проекта подобна труду садовника.Подобно тому, как садовник любовно отбирает наиболее подходящие растения для своего будущего сада, менеджер набирает людей, наиболее соответствующих целям проекта.
Подобно тому, как садовник ищет лучшую почву для каждого растения с учетом его особенностей, менеджер для каждого участника проектной команды ищет наиболее подходящую для него задачу.
Подобно тому, как садовник тщательно лелеет своих питомцев, оберегает их от вредных воздействий, следит за тем, чтобы ни одно растение не затеняло другое, а только дополняло его и способствовало его росту, менеджер проекта терпеливо работает с каждым участником проектной команды, способствуя его правильному развитию, охраняя от внешних и внутренних потрясений, для того, чтобы максимально раскрыть его индивидуальные способности и увеличить отдачу от них, с удовлетворением отмечает каждое новое достижение.
«Что посеешь, то и пожнешь» - этот закон одинаково применим как к труду садовода, так и к труду менеджера проекта. Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложите в людей часть своей души, и вам воздастся сторицей.
Управляем катастрофой
До сих пор мы только констатировали объективно существующие трудности и проблемы, которые связаны с разработкой программных проектов. Читатель давно уже в праве ожидать от нас ответа на вопрос «что делать?». Короткий ответ – управлять людьми, которые вовлечены в проект. И круг таких людей достаточно широк. Оставшаяся часть статьи будет посвящена управлению программными проектами, а если точнее, то работе менеджера проекта 14 по управлению людьми, как внутри проекта, так и вне него. Начнем по порядку.Над входом в храм Аполлона в Дельфах написано «Познай себя». Начинайте проект с себя. Вы – менеджер проекта. Если это ваш первый проект, то поздравляю вас с приобщением к благородной профессии. «Управление благородно по своей сути. Менеджмент ничего не имеет общего с деятельностью бюрократа, сидящего наверху. Менеджер делает самую необходимую в компании работу. Благодаря нему становится возможным выполнение самых грандиозных проектов. Нет более почетной работы, чем та, которую делает настоящий менеджер» [].
Но даже, если у вас сверхвысокий IQ , это не поможет вам в управлении людьми. Чтобы управлять людьми, нужны совсем другие качества. Менеджер должен обладать сверхвысоким EQ – коэффициентом эмоционального интеллекта ( Emotional Intelligence ). Вот три компонента эмоционального интеллекта:
? Понять свои собственные чувства.
? Научиться управлять ими.
? Научиться распознавать эмоции других и управлять ими.
Загляните в себя, есть ли у вас необходимые качества. В силу аутистической природы программирования хороший программист, как правило, этими качествами не обладает. Из хороших программистов выходят, как правило, плохие менеджеры проектов. Аутисты предпочитают не общаться с другими людьми и не испытывать потребности в таком общении, они не интересуются другими людьми, стремятся быть в одиночестве. Недостаточный EQ и шизоидные наклонности могут привести к параноидальному стилю управления: чрезмерной бдительности, подозрительности, озабоченности скрытыми мотивами, повышенной тревожности [].
Такие руководители считают подчиненных некомпетентными симулянтами, которые не любят свою работу и стремятся избежать ее, если у них есть такая возможность. Руководители подобного типа практикуют строгий контроль через активное личное наблюдение, формальные правила и ограничения. Ведут себя агрессивно, в особенности с теми подчиненными, которые высказывают свое мнение. «Кнут и пряник»15
для них единственные инструменты мотивации подчиненных. Эти инструменты, может быть, полезны, когда мы управляем стадом баранов, но для управления командой эйнштейнов категорически не годятся. Эйнштейны очень быстро разбегаются, если, конечно, их не огородить колючей проволокой 16. Мы еще вернемся к вопросу мотивации эйнштейнов.
Если у вас недостаточный EQ , не отчаивайтесь. В отличие от IQ , который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни.
Призыв 1. Повышайте свой эмоциональный интеллект, если вы хотите руководить успешными программными проектами.
Поймите свои собственные мотивы. Ответьте себе на вопрос, почему вы беретесь именно за этот проект 17. Помните, что вам предстоит поставить на кон свою репутацию и вложить в проект душу. «Вполнакала проекты не делаются» - очень точная формулировка И. Ставинского []. Поэтому нужно четко понимать, в чем будет ваш выигрыш в случае успешного завершения проекта.
Призыв 2. Поймите свои личные цели, достижение которых связано с успешным завершением проекта.
Эти цели не обязательно должны быть материальными: повышение оклада или должности. Это могут быть идеальные цели: познать новое, сделать то, что до вас никто не делал, обеспечить существенные конкурентные преимущества вашей компании или, наконец, осчастливить все человечество. Главное, чтобы для вас лично эта цель была значимой настолько, чтобы стремление к ее достижению могло бы поддерживать в вас состояние постоянного горения от начала до завершения проекта.
Как мы отмечали ранее, главная цель управления проектом - вызвать у заказчика чувство удовлетворения.
Степень удовлетворенности – субъективная величина, которая является отношением субъективной оценки достижений к субъективной же оценке ожиданий или потребностей. Отсюда следует:
Призыв 3. Продавайте свой проект от начала до завершения работ.
Понимание этого правила пришло ко мне достаточно давно 18, но формулировку его я заимствовал у Тома Питерса []. Продавать проект следует в первую очередь заказчику. Если, после заключения договора на разработку ПО, вы планируете следующую встречу с заказчиком на приемо-сдаточных испытаниях, то вы прямой дорогой идете к катастрофе. Вы должны работать над тем, чтобы заказчик постоянно испытывал чувство удовлетворения от начала проекта до его завершения. Этого можно добиться, если вы разрабатываете проект итерационно: чуть-чуть спроектировали, чуть-чуть закодировали, чуть-чуть протестировали и продали этот результат заказчику. Продали - это означает - убедили (снова психология) заказчика, что вы представили ему нечто большее, чем то, на что он мог бы рассчитывать на текущем этапе проекта. Если во время приемо-сдаточных испытаний критика заказчиком того, что вы произвели, это, скорее всего, признак неизбежной катастрофы, то замечания на ранних итерациях это весомое свидетельство движения вашего проекта к успеху. С радостью принимайте их и тщательно анализируйте 19. Даже если вы не будете уверены в их положительном влиянии (вы ведь можете что-то не знать о бизнесе заказчика), оперативно совершенствуйте свой проект и вновь представляйте результаты заказчику. Тем самым заказчик становится соучастником вашего проекта и соавтором будущего результата. А какой же родитель не любит ребенка, которого он сам растил и воспитывал. Это обратная связь, которая необходима любой системе управления, если вы хотите, чтобы она обладала устойчивостью. Это гарантия того, что на приемо-сдаточных испытаниях заказчик будет ожидать ровно то, что вы ему представите. Управляйте ожиданиями заказчика и формируйте у него адекватную оценку представленного вами результата.
Заказчик далеко не единственный человек, которому вы должны постоянно продавать свой проект. Заказчика окружают люди, которые могут существенно влиять на формирование его мнения. Например, будущие пользователи вашей программы. Вы просто обязаны продавать ваш проект и им. Так же полезно продать проект экспертам в той области ИТ, к которой относится ваш проект. Заручитесь их поддержкой, она особенно пригодится вам, если заказчик не является специалистом в ИТ.
Очень важно продавать проект вашему руководству, если заказчик проекта со стороны. Руководство должно быть постоянно уверено, что проект завершится в срок и в полном объеме. Сделайте проект прозрачным, пусть руководство видит все, от плана проекта до исходного кода программ и скриптов. Руководство, конечно, не поймет, как продвигается ваш проект, но избавится от присущей ему фобии, что от него что-то скрывают. Разработайте для руководства небольшой и ясный набор индикаторов (об индикаторах проекта чуть позже), который будет отражать продвижение проекта к цели, и регулярно представляйте отчет по их изменению, чтобы руководство могло следить за прогрессом проекта.
И если уж речь зашла о руководстве, то уместно привести здесь еще одно правило.
Призыв 4. Не позволяйте руководству принимать других решений в вашем проекте, кроме двух: остановить проект или сменить менеджера.
По всем остальным вопросам в проекте принимать решения должен менеджер, а руководство вправе лишь высказывать свои рекомендации. Если это не так, то вы идете к катастрофе. Джоель Спольски [] так описывает последствия вмешательства руководства: «…Руководители разных уровней с удовольствием запускали руки в каждый стряпающийся пирог, раздавая указания направо и налево в стиле, который я стал называть порулил и убегай. «Порулил и убегай» потому, что начальники появлялись на горизонте вероломно, отдавали глупые распоряжения как именно все, черт побери, должно быть сделано, без какого-либо предварительного размышления, и покидали комнату, оставляя всех собирать осколки».
Если вам не удалось оградить проект от подобных вмешательств, вам, скорее всего, придется собирать осколки до его завершения.
А теперь о самом главном в управлении программным проектом – управлении проектной командой. Управлять людьми – значит побуждать их к правильным действиям. А побуждать их можно, только управляя мотивами. Согласно теории мотивации для того, чтобы человек совершил какое либо действие он должен испытывать некую потребность и предполагать, что, выполнив это действие, он в той или иной степени эту потребность удовлетворит. Поэтому управление мотивами осуществляется, как правило, в двух направлениях: 1) формирование правильных потребностей; 2) формирование правильной оценки степени их удовлетворения 20.
Я отношу себя к сторонникам гуманистического направления в теориях мотивации и исхожу в своей практической деятельности из структуры потребностей, которую описывает пирамида А. Маслоу. Мои многолетние наблюдения показывают, что потребности нижнего уровня пирамиды (физиологические и безопасности) для программистов, как, впрочем, и для других работников интеллектуального труда, играют несущественную роль. Это означает, что если эти потребности удовлетворены процентов на 50-70, то их дальнейшее удовлетворение слабо мотивирует работу программиста. Для программистов гораздо большее значение имеет удовлетворение потребностей принадлежности, самоуважения и самоактуализации. Причем, чем выше квалификация программиста, тем на более высоком уровне пирамиды Маслоу находятся мотивирующие его потребности. Попробуйте уговорить суперпрограммиста перейти на техническое сопровождение системы, даже если вы пообещаете ему в два раза большую зарплату. А вот уговорить его перейти на проект в области сверхновых технологий вполне возможно, даже при некоторой потере в доходах.
Об этом же пишет Э. Йордан []: «Деньги, выгода, комфорт и тому подобное являются факторами «гигиены» - их отсутствие вызывает неудовлетворенность, однако они не могут заставить людей полюбить свою работу и дать им необходимые внутренние стимулы.
Что действительно может дать такие стимулы, так это ощущение значительности достигнутых результатов, гордость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост - все то, что обогащает работу». Об этом же более 30-ти лет назад писал Вейнберг []: «Творчески работающему программисту присуща глубокая внутренняя мотивация». На мой взгляд, это еще одно следствие аутистической природы программирования.
Призыв 5. Имейте ясное представление о мотивах каждого участника проекта, чтобы эффективно управлять проектной командой.
Как я уже отмечал ранее, потребности каждого программиста зависят от его возраста, опыта и квалификации. Позволю себе привести свою экспертную оценку распределения мотивирующих потребностей для профессиональных программистов.
Потребности |
Профессионализм |
||
Начинающий |
Опытный |
Профессионал |
|
Материальные (зарплата, условия труда, социальный пакет и проч.) |
50% |
20% |
|
Безопасности (стабильность компании, востребованность технологии проекта на рынке труда, возможность повысить квалификацию) |
20% |
||
Принадлежности (возможность учиться у более опытных коллег, опыт участия в успешном проекте, признание в коллективе) |
40% |
20% |
10% |
Самоуважения (развиваться, делать что-либо лучше других, повышение в должности, самостоятельность и ответственность в работе) |
10% |
30% |
40% |
Самоактуализации (амбициозность целей проекта – сделать то, что никто не делал или не смог сделать) |
10% |
50% |
|
Команда успешного проекта это команда победителей. Успешный проект должен сделать победителем всех его участников [].
Призыв 6. Рассматривайте работу команды над проектом как корпоративную игру, в которой каждый участник, стремится к достижению своих личных целей, продвигая проект к успеху.
Управление командой начинается с ее формирования.
Призыв 7. При наборе персонала убедитесь, что человек сможет сделать то, что нужно в вашем проекте и хочет то, что вы сможете ему дать.
Вроде все просто, однако, это не так. Сможет это не только знает и умеет, но еще и захочет 21. А часто бывает ситуация, что не знает и не умеет, например, если технология совершенно новая, но хочет. И этого стремления, как правило, бывает достаточно, чтобы освоить новую технологию и успешно решить поставленную задачу. Главный вывод, который отсюда следует это то, что на серьезный проект, надо набирать разных программистов. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его квалификацию и найдете достойную задачу, которая его заинтересует.
В настоящее время нет каких-либо формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием 22. При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволит вам создать эффективную программистскую команду. О практике проведения интервью могу рекомендовать работы [, ], в которых изложены подходы, во многом совпадающие с моим опытом.
Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации.
Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса - кустарным творением программистов - когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает
для пользователя.
Призыв 8. Не загружайте программистов несвойственной для них работой. Включайте в проектную команду, бизнес-аналитиков, эргономистов, художников-дизайнеров, документалистов. Разделение труда - залог перехода от кустарного производства к более эффективному промышленному производству.
Теперь, когда цели определены, команда собрана, пора приступать непосредственно к созданию программной системы. Поскольку, разработка ПО, как мы отмечали выше, корпоративная игра, то первое, что мы должны сделать, это договориться о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды в проекте. Повторим вслед за автором []: «Каждому проекту своя технология». И чем больше и ответственней проект тем «тяжелей» должна быть технология. Технология может меняться вместе с развитием и ростом проекта, но на каждом этапе она должна быть определена и описана . Бессмысленно спрашивать с программиста ответа за то, что ему не поручено 23.
Призыв 9. Договоритесь о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды.
Регламенты и стандарты требуются еще и для того, чтобы все участники проекта разговаривали на одном языке, а ваш проект не превратился в проект строительства Вавилонской башни.
Иначе, например, если не определено или не исполняется соглашение по правилам кодирования, программисты быстро перестанут понимать друг друга.
Главная задача менеджера - обеспечить максимально эффективное использование знаний и способностей каждого участника проекта для решения проектных задач. Набранная вами группа специалистов это еще далеко не та команда, которая способна быстро и качественно достигать поставленные цели, умеющая самостоятельно принимать нестандартные и эффективные решения. В силу аутистической природы программирования набранная вами группа это собрание индивидуалистов-эйнштейнов, которые, как правило, самодостаточны и не нуждаются ни в руководстве, ни в общении. Для того, чтобы из группы получилась команда, необходима общность представлений участников о нормах поведения в коллективе и ожиданиях от каждого из его участников. Каждый участник команды должен понимать, какое трудовое поведение приемлемо, а какое порицается, каковы должны быть отношения в группе, стиль и методы работы. У меня выработалось определенное представление о правильных нормах поведения, которые я настойчиво внедряю в своих проектах. На мой взгляд, программист может считать себя профессионалом только тогда, когда:
Основные усилия по мотивации участников проектной команды я направляю на то чтобы стимулировать правильное поведение.
Призыв 10. Постоянно работайте над строительством команды, мотивируйте правильное поведение участников проекта.
Очень важно, чтобы каждый член проектной команды знал, или хотя бы имел при желании возможность узнать о проекте не меньше, чем его менеджер. И не стоит ничего скрывать, ни проблем с заказчиком, ни разногласий с руководством. Трудно ожидать самостоятельные, нестандартные и эффективные решения от человека, у которого «шорами» ограничено видение проблемы.
Ошибкой являются попытки управления проектом на микро-уровне: мотивирование достижения формальных индивидуальных показателей, например, реализация программистом функциональных требований, количество написанных им строк исходного кода или плотность выявленных ошибок. В творческой деятельности формальные подходы не работают 24. Де Марко [] по поводу одной из своих коллег говорил: «я слабо представляю, какой вклад она вносит в мой проект, но за 12 лет ее работы в компании все проекты, в которых она участвовала, заканчивались успехом». За ответом направляю к его книге.
Основным инструментом управления у менеджера является план работ. Как мы уже отмечали ранее, работа по проекту должна вестись итерационно, а каждая итерация должна наращивать функциональность, которая определена требованиями к системе. Наиболее приемлемое время итерации от 2 до 6 недель. Именно на этот срок должно осуществляться детальное планирование. Поскольку в реализацию попадают только хорошо проработанные системные требования, то можно добиться достаточно высокой точности плана. Трудоемкость элементарных работ детального плана должна составлять от 4 до 20 часов при расчете на среднего программиста. Каждая итерация должна заканчиваться коллективным анализом «Lessons Learned»: удалось ли достичь поставленных целей, какие проблемы пришлось решать, как реорганизовать технологические процессы для более эффективной работы, - и детальным планированием следующей итерации.
Макро-показателей, по которым менеджер должен осуществлять мониторинг проекта, не так уж и много:
? Процент реализованных функциональных требований от общего числа.
? Объем затраченных на разработку человеко-часов.
? Количество строк исходного кода.
? Количество ошибок выявленных и закрытых.
Динамика этих показателей в сравнении с плановыми значениями позволяет вам и вашему руководству формально судить об успешности продвижения проекта. Если эти показатели существенно (более, чем на 10-15%) отличаются от прогнозируемых, то это свидетельствует о возможных проблемах проекта. Например, если количество кода превышает ожидания, то это может быть следствием ошибок в оценке трудоемкости (придется пересматривать планы, поскольку, скорее всего, увеличится срок проекта) или недостатков архитектуры и слабого повторного использования кода. Меньшее по сравнению с ожиданиями количество выявленных ошибок может свидетельствовать о недостатках в тестировании.
Программисты это, как правило, очень трудолюбивые люди (порой до фанатизма), с глубокой внутренней мотивацией к программистской работе. Как правило, я не вмешиваюсь в работу конкретного программиста, если срок выполнения поставленной задачи не превышен в 2-3 раза по сравнению с оценками в детальном плане. Так я определил для себя допуск на разброс траекторий на молекулярном уровне. Это оправдано, поскольку некоторые задачи решаются в разы быстрее, и на макро-уровне проект продвигается в соответствии с планом. Но если на микро- уровне возникают существенные отклонения от плана, это служит поводом для анализа причин неэффективной работы программиста.
Для эффективной работы программисту необходимо и достаточно выполнение четырех условий:
? Понимание целей работы.
? Желание ее сделать.
? Умение ее делать.
? Возможность ее сделать.
Неадекватное понимание целей конкретного проекта может привести к проблемам. Большинству опытных программистов свойственно стремление решить свою задачу не просто хорошо, а как можно лучше.
Они стремятся сделать задачу для самого общего случая, оптимально по памяти и быстродействию, используя самые последние достижения информационных технологий, закладывая в архитектуру возможность дальнейших расширений. Доводя свою программу до совершенства, программист способен затратить гораздо больше времени, чем реально требуется на задачу. Это стремление всегда вступает в конфликт с коммерческой стороной профессионального программирования, как способа получения доходов. С точки зрения заказчика, качественная программа это та, которая удовлетворяет заявленным требованиям. Не более того 25.
Призыв 11. Нацеливайте программистов на правильное решение задачи максимально быстрым способом.
Опыт свидетельствует, что более чем в 90% случаев ее не придется переделывать. Если работа вашей подпрограммы занимает только 1% общего времени выполнения, то, затратив сколько угодно времени на оптимизацию ее алгоритма, вы не добьетесь улучшения системных характеристик более чем на 1%. Такой выигрыш вряд ли стоит того, чтобы тратить время на оптимизацию. Со всеми остальными программистским наворотами дело обычно обстоит так же.
О мотивации программистов я уже говорил, поэтому добавлю лишь одно правило.
Призыв 12. Не пытайтесь получить от программиста больше того, что он хочет вам дать.
Ключевое слово здесь «хочет», заметьте, не «может», а именно «хочет» 26. Задача не будет выполнена за любое отведенное на нее время, если у программиста нет мотивов для ее решения. Или сумейте мотивировать программиста на выполнение задания, или передайте ее другому участнику проекта. Другого пути нет.
Еще раз напомню, что доминирующие потребности программистов находятся в верхней части пирамиды Маслоу, поэтому пинать и пугать их - занятие совершенно бесперспективное. Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег. Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности).
Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм. Сложнее дело обстоит с суперпрограммистами. Их основным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте – системная архитектура и реализация архитектурно значимых компонентов системы (скелета системы). При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить любую задачу в проекте.
Третье условие эффективной работы программиста – умение делать порученную работу. Как правило, начинающие программисты мало что умеют. Их главный метод программирования – копирование чужих образцов (Copy/Paste). Это естественный путь обучения ремеслу. Вспомним художников, которые учатся, копируя полотна великих мастеров. Важно, чтобы образцы для подражания были достойными. Поэтому целесообразно поручать задачу паре программистов, в которой один из них выступает наставником, а другой подмастерьем, перенимающим опыт.
У меня нет личного опыта парного программирования, которое рекомендует xProgramming, когда одну программу пишут по очереди. Но есть накопленная с годами уверенность, что ревизия кода более опытным коллегой на предмет «изобретения велосипеда» просто необходима. Кстати «изобретение велосипеда» любимое занятие не только среди начинающих, но и среди уже достаточно опытных программистов, у которых всегда возникает потребность переписать все по-своему.
Этому, как правило, есть две причины. Первая - недооценка сложности поставленной задачи. Вторая - недостаток времени для изучения достижений технологий, используемых в проекте.
Дополнительно, парная ответственность за исходный код страхует ваш проект от негативных последствий неожиданного ухода одного из специалистов 27.
Призыв 13. Планируйте время на самообучение участников проектной команды и обучение менее опытных программистов более опытными наставниками.
Время на это все равно тратится. Но если времени на обучения не достаточно, то будьте готовы к тому, что бездумное применение технологии Copy/Paste будет приводить к размножению ошибок в вашем проекте в геометрической прогрессии, и что масса времени будет тратиться на изобретение очередного велосипеда. Все это неизбежно приведет к снижению общей эффективности работ по проекту.
И о последнем условии эффективной работы – программисту должна быть предоставлена возможность сделать порученную работу. Здесь речь идет не о тривиальном наличии компьютера и инструментов разработки 28. И не о наличие отдельного кабинета, о котором пишет Де Марко 29. В творческой деятельности обязательным элементом ответственности является свобода выбора пути решения стоящей проблемы. Свобода не только необходимое условие творчества, но и важный мотивирующий фактор. Даже если вы уверены в существовании более правильного решения, вы не в праве настаивать на нем, вы можете высказать свое мнение только в виде рекомендации. Предоставьте членам проектной команды право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет. Впрочем, вы ведь тоже можете ошибаться.
Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов свободы. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники.
Работать больше, это совсем не значит - работать продуктивнее. Скорее наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переработкам. «Хорошо управляемое предприятие - это спокойное место. Зато «фабрика, отличающаяся "кипучей" деятельностью и "трудовым героизмом" работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе» [].
Если программист адекватно мотивирован для того, чтобы выполнить порученную работу, то он будет стремиться сделать ее максимально быстро и с необходимым качеством. Многие программисты, особенно молодые, по собственной инициативе готовы тратить на решение задачи по 12-16 часов в сутки. Это неправильно, эффективность работы резко снижается, и при злоупотреблении сверхурочной работой программист уподобляется мухе, бьющейся головой о стекло, вместо того чтобы методично искать правильное решение 30.
Еще одно распространенное заблуждение менеджеров: оптимизм программистов. Я не имею в виду начинающих программистов, я говорю об опытных. На мой взгляд, заниженные оценки сроков решения поставленной задачи, как правило, являются следствием морального давления менеджеров. Программисту в силу своего аутистического нежелания общаться с другими людьми, легче согласиться с навязываемыми руководством сроками, чем объяснять начальству, почему оно не право.
Отношение менеджера и членов успешной проектной команды должны строится не на принципах подчинения, а на принципах партнерства. Партнерство не может быть без доверия. Если в проектной команде нет доверия, это путь к катастрофе.
Призыв 14. Не мешайте программистам. Доверяйте им. Обеспечивайте им свободу творчества. Предоставляйте им право на ошибку. Не оказывайте на них давление.
Повторюсь, управляйте проектом на макро-уровне. Не бойтесь, если одна молекула временно летит медленнее, чем остальные, или не совсем в ту сторону. Главное, чтобы это не было системой, чтобы среднее движение всех молекул было направлено к цели и осуществлялось с необходимой скоростью.
Важнейшим неформальным макро- показателем состояния проекта являются коммуникации, их качество и количество. Если угодно, то по моей экспертной оценке коммуникации, включая наставничество и консультации, в успешном проекте занимают 30-50% рабочего времени. Только благодаря эффективным коммуникациям можно достигнуть синергетического эффекта, который отличает команду от просто группы. Мне неоднократно приходилось убеждаться, что освоение новой информационной технологии парой программистов, которые осуществляют интенсивный обмен знаниями, происходит минимум в 3 раза быстрее, чем в случае, когда ту же работу выполняет один программист. Недостаточное количество коммуникаций свидетельствует, как правило, об отсутствии команды, каждый углублен в свою задачу и не интересуется, что делают его коллеги. В результате будет сделано не то, что нужно, а то, что будет сделано, вряд ли удастся интегрировать в единую систему. Если через день после получения недельного задания у программиста не возникло уточняющих вопросов, жди беды. Скорее всего, он с головой ушел в «проектирование дома, забыв уточнить, для чего он предназначен» []. Учитывая шизоидную несклонность программистов к общению, менеджеру требуется прилагать значительные усилия для того, чтобы мотивировать необходимый уровень коммуникаций.
Эффективность коммуникаций напрямую связана с доброжелательностью межличностных отношений. Не стоит ожидать плодотворного обмена информацией, если участники проекта поставлены в условия конкуренции или разделены барьерами должностной иерархии. Доброжелательность это не отсутствие споров и дискуссий, а нацеленность в спорах и дискуссиях на поиск консенсуса (интегрированного решения проблемы, которое объединяет лучшие стороны всех предложений), а не на выяснение межличностных отношений.
Меня давно перестали напрягать обсуждения в рабочее время членами проектной команды вопросов, не связанных непосредственно с проектом. Я рассматриваю их как способ установления открытых и доверительных отношений между коллегами, без которых немыслимы эффективные коммуникации по производственным вопросам.
Кроме того, это способ отвлечься от зацикленности, от длительных и безуспешных попыток решить задачу, способ вытеснить проблему в подсознание. Все, кто занимался творческой деятельностью, понимают необходимость данной фазы в интеллектуальном процессе. В психологии это называют фазой инкубации проблемы.
Для успешного проекта характерно постоянное ощущение его участниками чувства удовлетворения и гордости за результаты своей работы, чувства оптимизма. Только наблюдая и анализируя общение участников проектной команды, можно получить информацию об их удовлетворенности состоянием дел. Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников.
Призыв 15. Наблюдайте за коммуникациями в проекте. Постоянно поддерживайте необходимый уровень энтузиазма в проекте. Мотивируйте участников проекта на установление эффективного неформального общения.
Объективности ради отметим, что слишком интенсивные коммуникации могут свидетельствовать о проблемах в проекте. Например, о слишком большой связанности архитектурных компонентов, разрабатываемых разными людьми. Это так же может свидетельствовать о недостатках нормативной или проектной документации, в которых отсутствуют ответы на повседневные рабочие вопросы, и их приходится искать, отвлекая коллег. Хотя, в силу аутистической природы программистов избыток коммуникаций в проекте встречается достаточно редко.
З.Ы.
Я ничего не сказал о том, что для успеха проекта надо еще составлять календарный план, управлять рисками, требованиями, конфигурацией, качеством, проектировать архитектуру, соблюдать стандарты кодирования, тестировать и документировать систему и много чего еще. Но, во-первых, вы все это давно уже знаете. Во-вторых, наличие детальных диаграмм Ганта пока еще не спасло от катастрофы ни один проект. И, наконец, в-третьих, «разруха не в клозетах, разруха в головах», как говорил профессор Преображенский.Управление проектами - статьи
Аннотация.
Рассматривается задача семантически корректной и функционально содержательной реконсиляции прикладных данных. Задача имеет ключевое значение для успешного применения современных технологий оптимистической репликации и создания перспективных распределенных приложений, таких как системы коллективной инженерии, мобильные базы данных, семантические сети. Рассматривается модельно-ориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL. На основе статического анализа формальных спецификаций прикладной модели выявляются отношения зависимости и отношения порядка между операциями в конкурентных транзакциях и применяется аппарат логического, полисиллогистического вывода для выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции. Обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации.Действия
Действие - это базовая операция, выполняемая приложением над реплицированными данными. Оно хранится в журнале и становится доступным для анализа сразу после записи или реконструкции журнала. Мы будем рассматривать действие как структуру, состоящую из шести элементов:В рамках рассматриваемой объектно-ориентированной метамодели целевым объектом действия может быть прикладной объект, группа прикладных объектов или целая популяция, определяемая некоторым объектным запросом. Объектом действия может быть также атрибут прикладного объекта или его отдельный элемент, если атрибут сложно структурирован, например, являясь некоторой коллекцией. В большинстве случае это прикладные объекты и их атрибуты.
Стандартный набор действий включает в себя операции создания, удаления, перемещения прикладного объекта, модификации атрибута или его элементов. Семантика операций может быть уточнена в зависимости от специфики рассматриваемого класса приложений. Например, в ряде случаев изменение атрибута целого типа может интерпретироваться как его увеличение или уменьшение на некоторое значение. Изменение атрибута, являющегося множеством элементов некоторого типа, может быть одновременно представлено как включение и/или исключение соответствующих элементов. Подобная детализация имеет смысл только в тех случаях, когда нарушения семантических ограничений проявляются на подобном уровне. Мы рассчитываем, что языки объектно-ориентированного моделирования позволяют конкретизировать репертуар и детальную семантику действий независимо от особенностей конкретного приложения и конкретной модели данных.
Граф реконсиляции
Граф (гиперграф) реконсиляции RG определим как набор пяти множеств (V = V1
V1, V2 - множества вершин, соответствующих операциям исходных транзакций T' и T". VC - множество операций, применяемых в корректирующей транзакции. При проведении анализа каждой вершине на графе присваивается логический статус. Статус указывает, включается ли соответствующая операция в итоговый журнал или нет. Граф реконсиляции обладает рядом свойств, существенных для его конструктивного анализа. Так как предполагается, что каждая транзакция, участвующая в процессе реконсиляции, является корректной, ребра, соответствующие обратным импликациям t1 → ¬t2 и ¬t1 → t2, могут быть установлены только между вершинами, принадлежащим разным транзакциям. В то же время ребра, соответствующие прямым импликациям t1 → t2 и ¬t1 → ¬t2, могут появиться как внутри отдельных транзакций, так и в разных транзакциях. Аналогично, между парой вершин одной транзакции не может существовать противоположных отношений порядка, что противоречило бы возможности их одновременного применения.
Следующие свойства связаны с обобщающими идеями сильных цепей зависимости и предшествования.
Пусть RG(V,E) - граф реконсиляции. Путь v1(t1), v2(t2), ..., vn(tn)
Прямой зависимостью назовем цепь зависимости, эквивалентную импликации t1 → tn или ¬t1 → ¬tn. Обратной зависимостью будем называть цепь, эквивалентную импликации t1 → ¬tn или ¬t1 → tn.В графе реконсиляции не существует циклов обратной зависимости. Если бы такой цикл был найден, это означало бы, что любой статус операции, приписанный ее вершине, не соответствует логическим отношениям. Это противоречит существованию тривиальных решений логической системы, в качестве которых всегда могут быть выбраны операции первой или второй транзакции.
Путь v1(t1), v2(t2), ..., vn(tn)
В графе реконсиляции не существует циклов предшествования, содержащих только вершины какой-либо одной транзакции. В противном случае это также противоречило бы существованию тривиальных решений задачи.
Этапы реконсиляции
В предлагаемом подходе общий процесс реконсиляции включает в себя семь этапов, представленных на Рис. 1:
Рис. 1.Основные этапы процесса реконсиляции
Во внимание принимается также требование наиболее полного покрытия результирующей транзакцией множеств операций в исходных транзакциях, поскольку именно этим определяется ее функциональная содержательность. В случаях, когда число приемлемых вариантов слишком велико, может быть построен план реконсиляции, который бы учитывал возникшие конфликты и определял альтернативные способы их разрешения, например, на основе дерева принятия решений.
В настоящей статье мы сосредоточимся на втором, третьем и четвертом этапах, охватывающих семантический анализ транзакций с использованием формальных спецификаций прикладной информационной модели, а также методы логического, прежде всего, полисиллогистического вывода для поиска решений рассматриваемой постановки задачи реконсиляции. Методы семантической декомпозиции транзакций более подробно обсуждаются в нашей работе [].
Логический анализ
Реализация намеченного подхода тесно связана с проведением логического анализа отношений зависимости и порядка, выявленных между операциями в конкурентных транзакциях на этапе семантического анализа. С целью формализации этапа решения предлагается использовать представление логической системы отношений в виде графа и/или матрицы реконсиляции и применить для эффективного поиска решений аппарат математической логики, в частности, полисиллогистический вывод и методы интервальной темпоральной логики. При этом декомпозиция и редукция логической системы рассматриваются и как самостоятельные этапы общего процесса реконсиляции, предваряющие непосредственный поиск решения, и как алгоритмические элементы единого метода, распространяемого на все переменные и отношения формализованной логической системы. Главной особенностью рассматриваемого метода является поиск непротиворечивых, семантически корректных решений, удовлетворяющих всем логическим отношениям, при обеспечении их полноты и репрезентативности. Последнее свойство принципиально для обсуждаемой задачи, поскольку для функциональной содержательности решения важно включить в итоговую транзакцию как можно больше операций исходных транзакций.В случаях, когда в логической системе присутствуют только бинарные отношения, удобно иллюстрировать применение метода с помощью введенного графа реконсиляции, имеющего прозрачную графическую нотацию. Для представления множественных отношений в логической системе естественным выглядит обобщение понятия на гиперграф, однако мы предпочитаем использовать эквивалентное представление в виде матрицы реконсиляции. В настоящей статье рассматривается метод анализа с использованием графа реконсиляции.
Логический вывод на графе реконсиляции
Обсудим метод, использующий графическую нотацию для графа реконсиляции на Рис. 5. Вершины графа изображены окружностями и помечены символами операций. Каждая вершина располагается в одной из областей, соответствующих исходным транзакциям и, возможно, применяемой корректирующей транзакции. На диаграмме области исходных транзакций располагаются на противоположных сторонах и отделяются от центральной области корректирующей транзакции двумя вертикальными линиями. В случаях, если коррекция отсутствует, на диаграмме размещаются лишь области исходных транзакций, отделенные друг от друга одной вертикальной линией.Бинарные отношения зависимости между операциями изображаются дугами, помеченными упорядоченными парами черных и/или белых кружков, бинарные отношения предшествования - стрелками. Строгие отношения зависимости представляются сплошными дугами, а нестрогие отношения - пунктирными дугами. Строгие отношения предшествования заканчиваются темными стрелками, а нестрогие отношения предшествования заканчиваются светлыми стрелками. При использовании некоторых визуальных элементов метода полисиллогистического вывода [] графическая нотация обеспечивает прозрачную и непротиворечивую интерпретацию обсуждаемой задачи. Для представления множественных отношений зависимости и порядка могут быть добавлены необходимые визуальные элементы, соответствующие ребрам соответствующего гиперграфа реконсиляции. На Рис. 6 приведен пример графа реконсиляции для рассмотренных выше транзакций.
Рис. 5.Графическая нотация элементов графа реконсиляции.
Опишем предлагаемый метод логического вывода, используя представленную графическую нотацию. Для выделения цепей зависимости и определения того, какие вершины могут зависеть от заданной вершины, удобно использовать следующее визуальное правило. Заметим, что цепями зависимости в графе реконсиляции являются только те цепи, ребра которых инцидентны общим вершинам с чередующимися цветами кружков. Это объясняется тем, что пара цветов, присваиваемая отношению импликации, соответствует запрещенной комбинации статусов операций, при этом черный цвет обозначает статус включения, а белый - исключения.
Таким образом, чередование цветов в инцидентных ребрах порождает цепочки логического вывода и соответствующие зависимости.
Рис. 6. Пример графа реконсиляции.
Общая схема метода вывода представляется следующими этапами.
На первом этапе все операции исходных транзакций объединяются в один временный журнал.
На втором этапе проводится поиск циклов прямой зависимости. Вершины найденных циклов формируют классы эквивалентности для операций, или, другими словами, множества операций, которые включаются в итоговую транзакцию только совместно. Таким образом, осуществляется декомпозиция транзакций на семантически связанные группы операций. В конечном итоге это приводит к снижению числа независимых переменных в решаемой логической системе, поскольку статус любой из вершин цикла однозначно определяет состояния всех остальных вершин.
На третьем этапе выявляются подобные цепи - логически эквивалентные цепи зависимости, начинающиеся и заканчивающиеся в одних и тех же вершинах графа. В результате проводимой редукции логической системы из анализа исключаются избыточные отношения и зависимые переменные, связанные с внутренними вершинами подобных цепей.
На заключительном этапе проводится поиск вершин, порождающих конфликты. Это вершины, инцидентные ребрам обратной зависимости, а также вершины, образующие циклы предшествования. Согласно применяемым политикам реконсиляции и решениям пользователя, операции, соответствующие конфликтным вершинам, последовательно удаляются из журнала. Вместе с удаляемой операцией из журнала исключаются все зависимые операции с вершинами, располагающимися вдоль цепей прямой зависимости от исходной вершины. Для оставшихся вершин пересматривается их возможность порождать конфликты. Например, если удалить некоторую вершину из цикла предшествования, то оставшиеся вершины становятся неконфликтными относительно данной группы отношений. После разрешения конфликтов, оставшиеся в журнале операции упорядочиваются согласно отношениям предшествования. Полученная в результате транзакция удовлетворяет всем наложенным семантическим ограничениям и предусловиям, необходимым для корректного воспроизведения журнала.
Представленный метод был изложен в предположении строгих необходимых отношений зависимости и порядка между операциями транзакций. Он естественным образом обобщается на нестрогий случай в результате инициирования процесса семантической реконсиляции с наиболее полной системой ограничений и ее последовательного ослабления. Однако полученные результаты нуждаются в дополнительной валидации, а при выявленных нарушениях - и в возможной дополнительной коррекции. Поскольку коррекция вносит новые изменения, которые могут конфликтовать с операциями исходных транзакций, процесс должен быть повторен, начиная с этапа семантического анализа.
Организация более сложного итерационного процесса сама по себе не гарантирует нахождение решения. Однако решения, полученные таким образом, являются более значимыми, поскольку обеспечивают полноту представления результирующей транзакции. В случае неудачи метод допускает возвращение к предыдущим стадиям решения, учитывающим большее количество ограничений. Заметим, что тривиальные решения задачи всегда существуют, и применение метода в результате возврата к ее строгой исходной постановке гарантирует их нахождение.
Общий подход к реконсиляции
В соответствии с главным принципом оптимистической репликации, приложения, выполняющиеся в распределенной среде, находятся либо на этапе изолированного исполнения, либо на этапе реконсиляции. При изолированном выполнении приложение оперирует локальной репликой разделяемых данных, приводя их в некоторые новые состояния. Все выполняемые действия записываются в журналах транзакций, являющихся упорядоченными множествами локально применяемых операций. Все действия детерминированы и обратимы. Применение всех операций, занесенных в журнал, к начальной версии данных должно приводить к той же окончательной версии. И наоборот, применение обратных операций в противоположном порядке должно возвращать данные из конечного состояния в первоначальное состояние.Неважно, ведется ли журнал в приложении постоянно или реконструируется путем сравнения начальной и текущей версий данных. В этом отношении мы следуем смешанному классу методов (hybrid state-transfer and operation-transfer methods), охватывающему и анализ изменений в состоянии данных и контроль последовательностей выполнения операций в транзакциях. В ряде случаев, например, при определении и проверке предусловий для операций учет порядка их выполнения может быть исключен из анализа без потери содержательности результатов для приложения. Однако в дальнейшем мы будем рассматривать наиболее общий случай.
Будем считать, что транзакции корректны в том смысле, что они могут быть корректно воспроизведены на основе журналов и гарантированно приводят к семантически целостному и функционально значимому представлению данных. Это важное допущение мотивируется тем, что используемые приложения, запущенные на локальной станции и обрабатывающие локальную реплику данных, работают правильно. В этом предположении, если начальное состояние данных было корректно, то корректная транзакция должна порождать итоговое состояние, удовлетворяющее всем семантическим ограничениям целостности и несущее необходимый функциональный смысл, определяемый пользователем.
Одним из главных преимуществ обсуждаемого подхода является возможность сохранять свойства целостности при реконсиляции данных или, более точно, реконсиляции соответствующих журналов транзакций. Требование поддерживать семантическую целостность реплицированных данных рассматривается в нашем исследовании как базовый принцип функционально содержательной реконсиляции.
Отношения зависимости и порядка
Отношения зависимости между операциями D определяются логическими операторами отрицания и импликации следующим образом. Для операций t1, t2 T, если t1 → t2, то журнал должен содержать t2 при условии, что он содержит t1. Если ¬t1 → ¬t2, то в журнале должна отсутствовать операция t2, если в нем отсутствует операция t1. Эти отношения несимметричны, рефлексивны и транзитивны. Для операций t1, t2 T, если t1 → ¬t2, то в журнале не может присутствовать t2, если он содержит t1. Если ¬t1 → t2, то журнал должен содержать t2, если в него не входит t1. Эти отношения симметричны, не рефлексивны и не транзитивны. Эти четыре логические отношения с характеристическими функциями, приведенными в Таблице 1, рассматриваются как основные отношения зависимости. Также мы считаем полезным использование симметричных отношений эквивалентности t1 ~ t2 ≡ t1 → t2 
t2 → t1 и взаимоисключения t1 ⊕ t2 ≡ t1 → ¬t2 ¬t1 → t2. Отношение эквивалентности устанавливается между двумя операциями t1, t2 T и означает, что эти операции могут встречаться в транзакции T только совместно. Отношение взаимоисключения между t1, t2 T обязывает транзакцию T включать в себя либо t1, либо t2 и запрещает содержать обе эти операции или ни одну из них.| 0 | 0 | 1 | 1 | 0 | 1 | 0 |
| 0 | 1 | 1 | 1 | 1 | 0 | 1 |
| 1 | 0 | 0 | 1 | 1 | 0 | 1 |
| 1 | 1 | 1 | 0 | 1 | 1 | 0 |
Таблица 1.Характеристические функции бинарных отношений зависимости.
В некоторых случаях приходится рассматривать более сложные множественные отношения между операциями. В общем виде они представляются характеристической функцией D(t1, t2, t3, …) и соответствующей таблицей значений, подобной Таблице 1.
В качестве примера рассмотрим множественное отношение кардинальности D(n:m)(t1+,…, t+I+ , t1-,…, t-I-). Данное отношение связано с ограничениями кардинальности ассоциаций и размерности коллекций элементов данных в объектно-ориентированной модели.
Оно считается выполненным, если
n ≤ card( T+ ) - card( T- ) ≤ m, где
T+ = { ti+, i
D(n+1:n+1)(t1+,…, t1-,…) …D(m:m)(t1+,…, t1-, …).
| t1+ T | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| t2+ T | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| t1- T | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| t2- T | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| D(0:0) (t1+,t2+,t1-,t2-) | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
| D(1:1) (t1+,t2+,t1-,t2-) | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
| D(2:2) (t1+,t2+,t1-,t2-) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
Часто требуется удовлетворить некоторое ограничение c = с(x1, x2, …), выраженное алгебраическим образом с помощью соответствующей логической функции нескольких переменных. Если конкурентные транзакции содержат операции модификации элементов данных, являющихся фактическими параметрами функции ограничения, то возможным способом сохранить целостность является принятие всех операций модификации первой транзакции или всех операций модификации второй транзакции. В этом случае между операциями устанавливается отношение алгебраической зависимости Dc (t1', t2', …,t1'', t2'',…), где операции первой транзакции t1', t2'
T' и операции второй транзакции t1'', t2'' T' модифицируют элементы данных, на которые наложено ограничение c(x1, x2,…).
Будучи выполненным, данное отношение приводит к выделению классов эквивалентности для операций каждой транзакции и исключению ситуаций одновременного их применения в результирующей транзакции:
D c (t1', t2',…,t1'', t2'',…) ≡ t1' ⊕ t1''
t1' ~ t2' t2' ~ t3' … t1'' ~ t2'' t2'' ~ t3'' …Отношение порядка или предшествования операций в транзакции P определим следующим образом. Для операций t1, t2
T, если t1 ∠ t2, то операция t1 должна появиться до операции t2 (не обязательно непосредственно перед ней) в любом решении, которое одновременно содержит операции t1 и t2. Отношение порядка несимметрично, не рефлексивно, но транзитивно. Так как отношение подразумевает наличие обеих операций в одной транзакции, отношение t1 ∠ t2 может быть установлено только между теми операциями, которые не связаны отношениями зависимости t1 → ¬t2 и t1 ⊕ t2 непосредственно или косвенно через другие отношения.Обсуждаемые отношения являются строгими в том смысле, что если операции не удовлетворяют некоторым установленным отношениям, то транзакция необходимо становится некорректной, что означает невозможность ее выполнения или потерю целостности воспроизводимыми данными. В ряде случаев могут быть рассмотрены более слабые отношения, обозначаемые
D
и P, которые совпадают со строгими отношениями D, P за исключением того, что они имеют достаточный, но не необходимый характер для корректности транзакции. Другими словами, иногда они могут быть не выполнены, не нарушая условия корректности транзакции и целостности данных. Поскольку риск нарушения все равно остается, предварительные решения (транзакции и данные), полученные без учета подобных отношений, должны быть дополнительно проверены на более поздних этапах рассмотренного выше процесса реконсиляции.Понятие корректной транзакции
Пусть X - область значений, которые могут принимать данные рассматриваемой прикладной объектно-ориентированной модели, C(x) ≡ {ci(x) | i =1,..,I} - система ограничений, наложенных моделью на состояние x
Для некоторых ограничений ci (x) могут быть определены корректирующие методы rij
Если данные находятся в состоянии x
При этом не требуется, чтобы каждое действие tk Для применения каждое действие корректной транзакции должно удовлетворять соответствующему предусловию. Поскольку действия в транзакциях не подчиняются коммутативным свойствам, порядок их применения существенен как для выполнения предусловий, так и для конечных результатов. Поэтому вводимое понятие корректной транзакции предполагает выполнимость всех определенных предусловий для действий и учитывает порядок их следования. В дальнейшем рассматриваются только корректные транзакции за исключением, естественно, некоторых временных представлений журналов.
Теперь определим возможные виды отношений между операциями. Временный журнал транзакции T = T'
Примеры формального анализа транзакций
Обратимся к следующей демонстрационной модели, формально описанной на языке EXPRESS (см. Рис. 4). Модель описывает объектный тип данных A с вещественными атрибутами x, y, z, целочисленным идентификатором id и квалификационным именем q, представленным множеством из трех строк. Модель определяет также объектные типы данных B и C, содержащие необязательную и обязательную ссылки соответственно на экземпляр объекта типа A.Определение типа A содержит правила Wr1, Wr2, ограничивающие допустимую область значений атрибутов x, y, z, а также правило уникальности Ur1 для значений атрибута id, действие которого распространяется на всю популяцию объектов типа A.
Пусть начальное состояние данных x = {a
Рис. 4. Демонстрационная модель данных, формально описанная на языке EXPRESS
Аналогичные отношения t1' → t2', t1' ⊕ t2'', t1' ∠ t2', и t1'' ∠ t2'' могут быть установлены для операций в сформированном временном журнале T'
T'' = {t1' = del(a), t2' = wr(b1.ref, 0), t1'' = new(b1B), t2'' = wr(b1.ref, a), …}.
Отношение t1' → t2' вытекает из того, что удаление объекта a требует обнуления соответствующей ссылки b1.ref, указывающей на него. Отношение t1' ⊕ t2'' появляется, потому что операции удаления объекта a в первой транзакции и установки на него ссылки b1.ref во второй транзакции являются взаимоисключающими.
Для временного журнала T'
T'' = {t1' = rm(a.q,…), t2' = in(a.q,…), t1'' = rm(a.q,…), t2'' = in(a.q,…) …}, чтобы сохранить атрибут q в корректном состоянии, необходимо потребовать, чтобы количество элементов соответст-вующего множества было ровно 3. Предполагая, что начальное состояние было корректным и применение каждой транзакции не нарушает целостности, мы устанавливаем отношение кардинальности D(0:0)(t2'+, t2''+, t1'-, t1''-). Это означает, что количество добавляемых элементов равно количеству исключаемых элементов, и мощность множества остается неизменной.Рассмотрим отношения между операциями, порождаемые правилами ограничения области значений. Для корректности итоговой транзакции с временным журналом T'
T'' = {t1' = wr(a.x), t2' = wr(a.y), t1'' = wr(a.z), …} требуется выполнение отношения алгебраической зависимости DWr1(t1', t2', t1''). В этом случае в итоговую транзакцию включаются все участвующие в ограничении операции первой или второй транзакции, и ограничение будет гарантированно удовлетворено. Отметим, что данное отношение носит предположительный характер, являясь достаточным, но не необходимым условием корректности транзакции. Поэтому при необходимости оно может быть снято на этапе семантического анализа транзакции, но тогда связанное с ней ограничение обязано быть проверено на последующем этапе валидации. Аналогичный вывод справедлив для отношения DWr2(t1', t2', t1''). Однако более детальный анализ показывает, что данное отношение следует исключить из рассмотрения, так как модифицируемые в различных транзакциях атрибуты появляются в различных термах конъюктивной нормальной формы предиката ограничения области значений.Наконец, рассмотрим отношения, устанавливаемые для ограничения уникальности. Предположим, что в каждой транзакции создается объект типа A, и инициализируется его обязательный атрибут id. Журнал для представления транзакции выглядит следующим образом: T'
T'' = {t1' = new(a1A), t2' = wr(a1.id, id1), t1'' = new(a2A), t2'' = wr(a2.id, id2),…}. Чтобы удовлетворить ограничение уникальности значений атрибута id, в дополнение к отношениям импликации t2' → t1', t2'' → t1'' и предшествования t1' ∠ t2', t1'' ∠ t2'' следует установить отношение исключения t1' ⊕ t2''. Однако такое отношение может оказаться слишком сильным, так как присваиваемые значения идентификаторов могут различаться. Поэтому здесь следует применить нестрогую форму отношения. Заметим, что даже если в дальнейшем на этапе валидации будет обнаружено, что идентификаторы случайно совпали, существует возможность переназначить их с использованием корректирующих методов.Конечно, приведенные примеры не исчерпывают все содержательные случаи семантического анализа транзакций. Тем не менее, они описывают типовые ситуации, возникающие на данном этапе реконсиляции, и иллюстрируют возможности применения формального, основанного на спецификациях прикладной модели данных, подхода. Отметим только, что для определения алгебраических зависимостей между данными и установления соответствующих отношений между операциями транзакций могут быть использованы методы инкрементального анализа и верификации данных [, ].
Роль модельно-ориентированного подхода
Модельно-ориентированный подход становится важным доминирующим направлением в инженерии программного обеспечения, критичного по отношению к требованиям мобильности, интероперабельности, развертываемости в разнородных средах. Деятельность международных сообществ по разработке соответствующих информационных стандартов и многофакторных прикладных моделей, прежде всего, в рамках ISO 10303 (STEP - Standards for Representation and Exchange of Product Model Data) [] и OMG MDA (инициатива Model-Driven Architecture группы индустриальных компаний Object Management Group) [] способствует развитию этих тенденций.Вместе с тем, применение модельно-ориентированного подхода при построении прикладных интегрированных комплексов для проведения масштабных междисциплинарных проектов в науке и промышленности, обнаруживает ряд фундаментальных проблем. Прежде всего, это проблема синергетической организации работ с участием большого числа партнеров проекта, вовлеченных в единую творческую и производственную деятельность, но профессионально, организационно и географически отделенных друг от друга. Традиционные решения, использующие в качестве ключевых компонентов интеграции системы управления базами данных и системы документооборота, как правило, имеют довольно ограниченное применение. Они либо не обеспечивают целостность проектной информации, либо существенно ограничивают возможности участников работать одновременно, что критично сказывается на качестве, стоимости и сроках проведения работ.
Обеспечение эффективного мультидоступа к проектным данным при необходимой централизации управления ими и существенно распределенном, автономном и продолжительном характере проведения индивидуальных пользовательских сессий представляется в данном случае наиболее критичным. Предпринятые попытки ослабления базовых принципов ACID на основе идей последовательной целостности (serial consistency), использования версий данных (multiversion concurrency), применения специальных протоколов транзакций (transaction access patterns), а также разработки специальных механизмов альтруистических блокировок (altruistic locks) себя не оправдывают [].
Вместе с тем, хорошо известны примеры успешного применения в ряде приложений оптимистической репликации. Это популярные распределенные сервисы UseNet; персональные помощники PDA (Personal Digital Assistants); мобильные базы данных, включая широко известную реализацию Bayou; системы совместной разработки программного обеспечения, в частности, CVS (Concurrent Versions System). Однако в применяемых в них методах игнорируются сложные семантические зависимости между данными и не обеспечивается желаемая целостность итогового представления.
Например, реализуя типовые средства синтаксической реконсиляции текстовых документов, CVS не позволяет контролировать и, тем более, гарантировать семантическую корректность итоговых текстов программ на том или ином языке реализации. Однако, если в системах программной инженерии текстовые данные всегда могут быть скорректированы непосредственно программистами, в научных и промышленных приложениях, оперирующих со сложно структурированными моделями, их коррекция не может быть осуществлена усилиями пользователей.
В связи с этим естественной выглядит попытка разработки и применения модельно-ориентированного подхода к семантической реконсиляции с использованием формальных спецификаций модели данных. Подобные спецификации предоставляют дополнительные возможности для статического и динамического анализа зависимостей между элементами данных и выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции.
Исследования в этой области в настоящее время привлекают как коммерческие компании, так и многочисленные университетские коллективы.
Семантическая реконсиляция прикладных данных на основе моделей
В.А. Семенов, С.Г. Ерошкин, А.А. Караулов, И.В. Энкович,Труды Института системного программирования РАН
Семантический анализ транзакций
Процесс реконсиляции состоит в объединении журналов изменений с тем, чтобы построить новый журнал и, воспроизведя его, реконструировать согласованное представление реплицированных данных. В идеальном случае полученный журнал должен содержать все действия исходных журналов и приводить к представлению данных, которое бы удовлетворяло необходимым семантическим ограничениям и пользовательским требованиям. Тем не менее, простые приемы исключения и консолидации семантически подобных действий в совместном журнале не обеспечивают выполнения необходимых ограничений и нарушают целостность итогового представления данных.Вместо этого мы предлагаем использовать информационную модель данных для более детального анализа операций транзакций и применения методик группирования и упорядочивания для перманентной поддержки данных в целостном состоянии.
Типы данных и виды ограничений
Объектно-ориентированные языки моделирования, такие как EXPRESS, UML/OCL, ODL/OQL, предоставляют широкий спектр декларативных и императивных конструкций для описания структур данных и накладываемых на них семантических ограничений.В частности, в языке EXPRESS определяются простые типы данных с общепринятой семантикой: вещественный, целый, числовой, булевский, логический, строковый, двоичный строковый. Сложные типы охватывают четыре вида коллекций: списки, множества, массивы, мультимножества, а также перечисления, выборки и переопределяемые типы, уточняющие семантику основных типов. Для объектных типов предоставляются развитые механизмы множественного наследования, специализации атрибутов, полиморфного определения производных методов, декларации ограничений, позволяющие пользователям определять сложные модели данных.
На Рис. 2 представлена общая классификация типов, поддерживаемых языком EXPRESS. Полужирным курсивом отмечены исходные типы. Стрелки показывают отношения наследования между ними. Конструкции для определения типов пользователем отмечены обычным шрифтом.
Рис. 2.Классификация исходных типов языка EXPRESS
В зависимости от контекста определения различаются три основных вида ограничений: правила для простых пользовательских типов данных, локальные правила для объектных типов и глобальные правила для наборов объектных типов (Рис. 3).
Кроме неявно предполагаемых условий соответствия присваиваемых значений их типам, данные виды ограничений позволяют задавать:
Рис. 3. Классификация видов ограничений EXPRESS
Для получения более подробного описания можно обратиться к упомянутым выше стандартам, регламентирующим языки.
и прикладная проблема, тесно связанная
Семантическая реконсиляция - фундаментальная научная и прикладная проблема, тесно связанная с применением современных технологий оптимистической репликации в распределенных системах и имеющая индустриально важные приложения, такие как системы коллективной инженерии (concurrent engineering environments), мобильные базы данных, распределенные сервисы, семантические сети [].Использование в подобных приложениях оптимистической репликации позволяет отказаться от необходимой централизации управления распределенными информационными ресурсами, свойственной пессимистическим моделям транзакций, и обеспечить возможность эффективной одновременной работы пользователей и приложений с реплицированными версиями данных. Однако необходимость обнаружения и разрешения конфликтов в конкурентных транзакциях после их применения делают постановку задачи реконсиляции довольно нетривиальной. Требования корректности и полноты реконструируемой итоговой транзакции, а также условия семантической целостности результирующего представления данных существенно усложняют поиск допустимых решений.
В настоящей работе обсуждается предложенный подход к семантической реконсиляции с использованием формальных спецификаций модели данных. Предполагается, что спецификации представлены декларативным образом на объектно-ориентированных языках EXPRESS [], UML/OCL [], ODL/OQL [] (или на подобных им) и охватывают как структуры данных, так и заданные на них семантические ограничения.
На основе формального анализа конкурентных транзакций выявляются возможные отношения между элементами данных и операциями, и применяется логический вывод для их семантически корректного и функционально содержательного слияния. При подобном подходе операции транзакций рассматриваются как объекты системы посылок и заключений, а отношения зависимости и порядка между ними - как правила логического вывода. Выбранная система отношений позволяет, с одной стороны, промоделировать сложные семантические зависимости между операциями транзакций, а с другой стороны - привлечь для решения рассматриваемой задачи хорошо развитый аппарат математической логики, в частности, методы полисиллогистического вывода [] и интервальной темпоральной логики [].
С целью обобщения рассматриваются бинарные и множественные отношения, а также учитываются возможные альтернативные способы задания отношений в аналитической и табличной форме.
Обсуждаемый подход относится к так называемому смешанному классу методов и допускает конструктивную реализацию в составе распределенных систем с традиционными клиент-серверной и равнозначной P2P архитектурами на основе поддерживаемых протоколов транзакций. Он также реализуем в автономных приложениях, использующих файловый обмен данными, посредством непосредственного сравнения версий данных и реконструкции журналов изменений.
Подход обладает рядом важных достоинств, связанных с гарантированным обеспечением целостности прикладных данных, которые определяются масштабными, семантически сложными моделями, при относительно невысоких вычислительных затратах. Возможности формализованного и содержательного применения подхода к широким классам приложений оптимистической репликации делают его привлекательным для реализации перспективных систем коллективной инженерии с долгими транзакциями и мобильных информационных систем с неустойчивым соединением и прерываемыми сессиями.
посвящен обсуждению общих аспектов применения модельно-ориентированного подхода к построению прикладных интегрированных систем и необходимости ослабления фундаментальных принципов ACID (атомарности, целостности, изоляции и долговечности) для приложений оптимистической репликации. В описывается общая схема процесса семантической реконсиляции, а также на примере языка объектно-ориентированного моделирования EXPRESS приводится классификация типовых элементов данных и семантических ограничений. Проведение семантического анализа конкурентных транзакций на основе введенной классификации основных видов отношений зависимости и порядка между операциями обсуждается в . Особое внимание уделяется установлению отношений на основе формального анализа семантических ограничений в прикладной модели данных. Процесс декомпозиции и редукции задачи с помощью определяемого графа и матрицы реконсиляции рассматривается в .В приводятся конструктивные утверждения относительно корректности постановки задачи и поиска решений на основе эквивалентных преобразований матрицы реконсиляции. В заключении обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации.
ориентированный подход обладает рядом важных
Представленный модельно- ориентированный подход обладает рядом важных конкурентных преимуществ, главным из которых является строгое обеспечение целостности результирующего реконсилированного представления данных и, как следствие, возможность эффективного применения в приложениях, использующих технологии оптимистической репликации и оперирующих масштабными, семантически сложными моделями данных.Значительная универсальность, достигнутая за счет применения общего математического аппарата, не препятствует содержательному применению подхода к разнообразным классам приложений, включая системы коллективной инженерии с долгими транзакциями и мобильные информационные системы с прерываемыми сессиями. Благодаря использованию формальных методов статического анализа спецификаций прикладных моделей, удается преодолеть проблемы комбинаторного характера, свойственные многим другим методам. Важно отметить, что логический вывод является одним из наиболее затратных элементов предлагаемого подхода, поскольку число операций в конкурентных транзакциях и число установленных отношений между ними может быть значительно. Тем не менее, применение разреженных схем представления логических отношений и соответствующих матричных методов преодолевает эту проблему. Данный аспект является принципиально важным, поскольку позволяет существенно снизить вычислительную сложность и сделать возможным практическое применение подхода для важных научных и индустриальных приложений.
Управление проектами - статьи
Рефакторинг архитектуры
Как уже говорилось, потребность в изменении архитектуры может возникнуть в различных сценариях. В силу большой актуальности задачи изменения архитектуры, возникает интерес в организации методического и управляемого подхода к ее решению, а также сопровождающих ее инструментальных средств.Одним из наиболее успешных подходов к изменению существующего программного обеспечения является рефакторинг – подход, основанный на систематических трансформациях исходного кода. Рефакторинг – это изменение во внутренней структуре ПО, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения. В привычном понимании разработки ПО сначала создается дизайн системы, а потом пишется ее код. Со временем код модифицируется, и целостность системы, соответствие ее структуры изначально созданному дизайну постепенно ухудшается. Дальнейшее развитие системы постепенно сползает от направленной, проектируемой деятельности к хакерству. Рефакторинг представляет собой противоположную практику. С его помощью можно взять плохой, хаотический проект и переделать его в хорошо спроектированный код. Каждый шаг этого процесса чрезвычайно прост. Например, шагом может стать перемещение поля или метода из одного класса в другой, расщепление класса и т.д. Однако суммарный эффект таких небольших изменений оказывается кумулятивным и может радикально улучшить проект. Процесс рефакторинга является прямой противоположностью постепенной деградации кода системы [2].
При документации и каталогизации методов рефакторинга принято использовать полуформальную нотацию, в которой каждый из методов описан так называемым паттерном. Любой паттерн описывает и именует типовую задачу, которая постоянно возникает в работе, а также принцип ее решения, причем таким образом, что это решение можно использовать потом снова и снова. Паттерн именует, абстрагирует и идентифицирует ключевые аспекты структуры общего решения [6]. Помимо прочего, паттерны формируют словарь решений для данной проблемной области и позволяют двум специалистам в этой области именовать типовые решения и понимать друг друга, не объясняя каждый раз суть самих решений.
Рефакторинг объектно-ориентированного кода зарекомендовал себя как эффективный способ решения задач эволюции и сопровождения программ. Однако в настоящее время практически не существует исследований, посвященных рефакторингу на более высоком уровне абстракции – уровне архитектуры ПО. Соответственно, вызывает значительный интерес перенос данной методологии на более высокий уровень абстракции. Общей целью усилий по разработке и стандартизации методики изменения архитектуры, а также инструментальных средств поддерживающих эту методику является получение управляемого и предсказуемого процесса преобразования архитектуры.
Архитектура ПО и ее рефакторинг
В настоящее время не существует общепринятого определения термина “архитектура программного обеспечения”. В то же время, существует большое количество различных определений этого понятия, имеющих во многом схожий смысл. В качестве примера можно привести следующее определение: архитектура программного обеспечения - это первичная организация системы, сформированная ее компонентами, отношениями между компонентами и внешней средой системы, а также принципами, определяющими дизайн и эволюцию системы [3].Фазы архитектурного рефакторинга
Необходимо отметить еще одну специфическую черту рефакторинга архитектуры: для достижения промежуточных целей, возникающих в ходе архитектурного рефакторинга, как правило, приходится выполнять более одного шага. Эти шаги относятся к различным фазам решения поставленных архитектурных задач. Можно условно выделить следующие фазы архитектурного рефакторинга: фаза "раскопки" архитектуры, фаза трансформации архитектуры, фаза семантического анализа подсистем и фаза проецирования изменений модели на программный код. Более подробное рассмотрение фаз архитектурного рефакторинга целесообразно начать именно с проецирования изменений модели на программный код.Проецирование изменений модели на программный код. Как уже говорилось, для описания архитектурного рефакторинга представляется целесообразным использование структурных моделей. Модели извлекаются из программного кода автоматически, и каждому элементу модели соответсвует некоторое множество символов исходного кода программной системы. Таким образом, редактирование модели, обусловленное применением шагов рефакторинга архитектуры, может (и зачастую должно) быть спроецированы на реальный программный код системы. Действительно, при проецировании удаления блоков из модели необходимо определить множество строк и файлов, которое соответствует удаленному блоку в программном коде. После этого необходимо удалить из программного проекта выявленные строки и файлы. При проецировании на код переноса блока в модели переносятся соответствующие строки и файлы в исходном коде программной системы и т.д.
Проецирование на программный код системы шагов, выполненных в ходе некоторого архитектурного рефакторинга, хотя и является чисто механическим действием, тем не менее, позволяет извлечь практическую выгоду из проведенного анализа. Производимые таким образом трансформации можно рассматривать как архитектурно?управляемый рефакторинг программного кода.
"Раскопка" архитектуры. Шаги, относящиеся к этой фазе, характеризуются тем, что соответствующие действия, применяемые к модели, не ориентированы на последующее проецирование на программный код.
Они нужны только для понимания и структуризации модели.
Трансформация архитектуры. Для шагов, относящихся к трансформации архитектуры, в отличие от шагов фазы раскопки, типично последующее проецирование их на реальный код программной системы. Шаги этой фазы четко связаны с реальной модификацией кода системы и, в конечном счете, ориентированы на его улучшение. Следует также отметить, что часть методов рефакторинга архитектуры не может быть строго отнесена к одной из названных категорий (раскопка и трансформация). На практике это означает, что решение о проецировании этих шагов на код принимает разработчик, руководствуясь поставленной задачей.
Семантический анализ подсистем. Как правило, между шагами описанных выше фаз архитектурного рефакторинга предпринимаются шаги, которые можно отнести к фазе семантического анализа подсистем: по ходу трансформаций часто встает задача выявления смысловой нагрузки подсистем. Для решения подобных задач, даже в первом приближении, зачастую приходится исследовать реальный программный код (здесь опять-таки помогает точность модели), анализировать сигнатуры функций и комментарии, а при отсутствии последних и сам код функций. Задача специалиста, вовлеченного в процесс архитектурного рефакторинга, – по возможности минимизировать объем семантического анализа (например, путем удаления вспомогательных блоков) и сделать его последовательным и направленным.
Как представить архитектуру и ее изменения?
Специфика описания архитектуры и ее изменений заключается в том, что, в отличие от программного кода, архитектура не имеет явного представления, за исключением, может быть, тех случаев, когда она явно задокументирована. Однако даже в последнем, оптимистическом случае трудно гарантировать соответствие задокументированной архитектуры той фактической высокоуровневой логической структуре, которая на самом деле существует в системе.Способом описания архитектуры и ее изменений могут стать структурные модели. В настоящее время существует большое количество нотаций и инструментов, поддерживающих структурное моделирование ПО. Возможность автоматического извлечения моделей из кода гарантирует их точность и позволяет своевременно их обновлять. Эта возможность становится ключевой при выборе инструментария, поскольку соответствие модели фактической структуре существующего кода при моделировании архитектуры и ее изменений представляется исключительно важным для обеспечения точного и управляемого процесса.
Для дальнейшего исследования архитектуры программных систем в данной статье используется нотация структурного моделирования, принятая в инструменте KLOCwork Architect, который предоставляет возможность автоматического извлечения моделей из программного кода и их редактирования. Приводем краткий обзор этой нотации.
Модели программных систем, используемые в KLOCwork Architect (в дальнейшем модели) [4], отдаленно напоминают модели типа сущность-связь (Entity-Relation models). Говоря строго, они относятся к классу контейнерных моделей, подробно рассматриваемых в работе [5]. Основными элементами модели являются следующие элементы:
Архитектурный блок (Architecture Block). Модель KLOCwork Architect состоит из так называемых архитектурных блоков. Архитектурные блоки представляют в модели структурные элементы программной системы, вне зависимости от уровня абстракции, на котором идет моделирование. Архитектурные блоки обладают, по меньшей мере, двумя основными атрибутами: имя и тип.
Имена архитектурных блоков предопределяются именами тех структурных элементов системы, которые они представляют в модели. Типы архитектурных блоков существенно зависят от уровня абстракции, на котором происходит моделирование, и конкретной задачи, в рамках которой проводятся исследование архитектуры. Например, при моделировании систем, построенных в рамках каких-либо компонентных технологий, основным используемым типом архитектурных блоков являются “компоненты”. При моделировании системы сборки ПО основными используемыми типами являются “папки” и “файлы”.
Отношение (Relation). В модели KLOCwork Architect под отношением понимается односторонняя связь между парой архитектурных блоков. Так же, как и архитектурные блоки, отношения могут быть различных типов. В качестве примера можно привести следующие типы отношений:
Инстанциация: A инстанциирует B (блок A – функция, блок B – класс).
Между любой парой блоков в модели может существовать произвольное количество разнонаправленных отношений, при этом их типы также могут различаться.
Пример модели. В качестве иллюстрации рассмотрим микроскопическую тестовую систему на языке C и модель, автоматически полученную из нее системой Architect. Система имеет следующую структуру:
void a() {
int a = 0; a++; }
Для подобной системы извлеченная автоматически модель будет иметь следующую структуру:
Таблица 1.
Место паттерна выделения слоев в рефакторинге архитектуры
Как уже говорилось, рефакторинг архитектуры содержит шаги, которые можно сгруппировать по их назначению. Выделение слоев примечательно тем, что в разных контекстах может быть отнесено к разным фазам в рамках рефакторинга архитектуры.Значение паттерна для анализа. Паттерн выделения слоев может быть применен для чистого анализа (раскопки) архитектуры. Для этого имеется несколько оснований. Выделение слоев – это прием, который в известной степени позволяет сократить и сделать более направленным семантический анализ системы за счет структурного анализа, что, несомненно, хорошо, поскольку семантический анализ – значительно более ресурсоемкий процесс. При этом нет никакой необходимость отражения слоев на программный код и инфраструктуру его хранения. Например, при анализе архитектурного кода программной системы, написанной на Java, выделение слоев не предполагает обязательного выделения пакетов, соответствующих этим слоям. Если специалист, проводящий архитектурный рефакторинг, принимает решение все-таки не отображать слои в пакеты языка Java, то можно считать, что выделение слоев было применено для чистого анализа архитектуры.
Значение паттерна выделения слоев для улучшения системы. Выделение слоев – хорошая основа для улучшения системы. Как уже упоминалось, найти строгие слои в произвольной программной системе значительно труднее, чем найти слои с некоторыми допустимыми отклонениями, как, например, такие, которые были описаны в предыдущем разделе. Тем не менее, для каждого из допустимых отклонений известны побочные эффекты, которые можно устранять, по возможности приводя слои к строгим.
Отличия архитектурного и классического рефакторингов
При переносе методики рефакторинга на уровень архитектуры существует ряд особенностей, которые обуславливает изменение "облика" метода:Объекты. При переходе от классического рефакторинга к архитектурному меняются объекты, с которыми идет работа. В классическом рефакторинге сущностями, с которыми идет работа, являются такие элементы, как класс, экземпляр класса. Архитектурный рефакторинг применяется к системам и компонентам. В разных типах рефакторинга различаются также и виды связей, возникающих между объектами.
Масштабы изменений. Классический рефакторинг применяется в существенно меньших масштабах – обычно последствия применения отдельного паттерна классического рефакторинга ограничивается несколькими файлами. Паттерны архитектурного рефакторинга применяются к компонентам архитектуры. При проецировании этих паттернов обратно с уровня структурной модели на программный код изменения могут затронуть существенно больший объем существующего кода (подробно о проецировании изменений модели на код – в разделе 2.3.2).
Описание изменений. Методы классического рефакторинга можно проиллюстрировать статическими моделями языка и фрагментами кода. Для описания архитектурного рефакторинга представляется более удобным использовать специализированные структурные модели и инструментальные средства поддержки обратной инженерии.
Тестирование. В соответствии с [2] трансформации можно считать корректными, если они не приводят к изменениям поведения программной системы в целом. Наличие достаточно полного набора модульных (unit) тестов позволяет убедиться в корректности трансформаций. Именно это делает модульное тестирование одним из ключевых аспектов классического рефакторинга. Для архитектурного рефакторинга также встает задача автоматической проверки корректности трансформаций. Конечно, наличие модульных тестов повышает уверенность разработчика в корректности проведенных изменений даже при применении архитектурного рефакторинга. Тем не менее, на настоящий момент неизвестно, насколько эффективно модульное тестирование работает с методами рефакторинга архитектуры. Это, в частности, обуславливается разницей в масштабах изменений при классическом и архитектурном рефакторинге.
Паттерн
В этом разделе рассматривается основной паттерн выделения слоев – это всего лишь один из вариантов, представитель целого семейства паттернов выделения слоев. Подвидов у этого паттерна существует достаточно много, и каждый из них обладает своей спецификой. Эти подвиды и их особенности будут рассматриваться далее.Имя: выделение слоев.
Ситуация: на диаграмме представлены элементы, для которых верны следующие условия:
Рецепт: Объединить блоки в новый слой “n+1”. Отметим, что для двух произвольных слоев слой, обладающий большим порядковым номером, считается "вышележащим". Важно отметить, что если в результате применения паттерна было выделено n слоев, и еще остались блоки, которые в силу ограничений не смогли быть отнесены ни к одному из выделенных слоев и формально не могут быть выделены в новый слой, то эти блоки по-умолчанию считаются n+1 слоем, который в дальнейшем именуется "чердаком".
Примеры применения паттерна выделения слоев
Улучшение архитектуры и нестрогие слои. В работе [9] описывается случай, когда найденные нестрогие слои позволили выявить архитектурный дефект в программной системе toolbus, существенно затруднявший реализацию задачи, поставленной перед разработчиками. Программная система toolbus представляет для своих клиентов механизмы коммуникации. В системе используется набор стандартных сообщений, которые были реализованы на основе сокетов операционной системы и специализированного текстового протокола для обмена данными по сокетам (на рис 3 – за это отвечает слой “Layer 2: Protocol Implementation”). Чтобы изолировать тонкости текстового протокола от разработчиков, был реализован API системы, скрывающий как ее сокеты, так и передаваемые через них коды команд за набором процедур языка программирования (Layer 3: Toolbus API). Однако по мере развития в систему были добавлены вспомогательные механизмы (“Layer 4: Applications”). Именно эти механизмы и нарушали строгость слоистой структуры, поскольку они обращались к уровню работы сокетов в обход специфицированного API системы (связь от “Layer 4” к “Layer 3”).Рисунок 3. Архитектура toolbus
Поскольку перед разработчиками стояла задача смены текстового протокола, используемого в системе для обмена по сокетам, подобный дефект грозил переделкой всех стандартных механизмов системы. Архитектурный рефакторинг позволил избежать столь неприятной ситуации и впоследствии значительно сократить время, затрачиваемое непосредственно на кодирование.
Анализ архитектуры и поглощающие слои. Характерным примером, демонстрирующим пользу смягчения условий для поиска слоев с целью анализа архитектуры является ситуация, возникшая при анализе архитектуры Apache James 2.2. Apache James – это реализованный на Java мощный почтовый сервер масштаба предприятия, поддерживающий все наиболее распространенные современные почтовые протоколы и предоставляющий ряд дополнительных возможностей. После того, как для сервера Apache James была построена структурная модель, и в ней были выделены основные подсистемы, была предпринята попытка выделить в модели нестрогие слои.
При выделении слоев было разрешено поглощение СК. В результате была получена диаграмма 4 А). Эта диаграмма вполне осмыслена: на слое 1 оказались блокConstants.java, содержащий константы, используемые во всей системе, и блок Core, содержащий основные типы данных системы, такие как Message – сообщение, MessageHeader – заголовок сообщения и пр. Таким образом, слой 1 содержит основные определения системы. Слой 2 содержит authorization – систему контроля доступа, mailrepository – репозиторий писем, mailstore адаптер для mailrepository созданный для унификации работы с различными системами хранения и управления сообщениями, в том числе он может служить скрывать и mailrepository. Слой 3 – фактически, основной, поскольку содержит собственно ядро почтового сервера. На слое 4 располагаются вспомогательные механизмы для работы с почтовым сервером – система удаленного администрирования remotemanager и система fetch – облегчающая получение писем с сервера.
С другой стороны, попытка выделения нестрогих слоев, но без поглощения СК дала гораздо более слабый результат. Выделенные слои представлены на рис 4 Б). Из-за того, что в системе существует сильносвязанный компонент, в который входят блоки mailrepository и mailstore, на "чердак" попало большинство слоев системы, а дать слоям какое-либо внятное определение оказалось невозможно.
Рисунок 4. Анализ Apache James
Необходимо отметить, что СК, содержащий mailrepository и mailstore, свидетельствет о некоторой архитектурной проблеме. Как уже говорилось, mailstore – выступает как адаптер для mailrepository. Связь идущая от mailrepository к адаптеру свидетельствует о том, что изменение адаптера приведет к изменению адаптируемого объекта, что снижает гибкость архитектуры программной системы.
Рефакторинг архитектуры программного обеспечения: выделение слоев
Труды Института Системного Программирования РАН, 2004 г.
Слои в архитектуре ПО
Концепция слоев — одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. В среде сетевого взаимодействия протокол FТР работает на основе протокола ТСР, который, в свою очередь, функционирует "поверх" протокола IР, расположенного "над" протоколом Ethernet [7]. Итак, рассмотрим основные причины интереса к слоям архитектуры программных систем:Слои легко формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n – это компонент или набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.
Слои обладают простой и наглядной семантикой. Как правило, в архитектуре программной системы слои представляют уровни абстракции. Слой n+1 использует слой
n, следовательно, абстракция понятий слоя n+1, по меньшей мере, не ниже чем у слоя n, а в идеале – если архитектура системы эффективна, его уровень абстракции должен быть выше. Соответственно, слой n скрывает (инкапсулирует) логику работы с понятиями определенными на этом слое, позволяя, таким образом, слою n+1 реализовать работу с более сложными понятиями, организовать более сложную логику, используя выразительные средства нижележащего слоя.
Слои широко распространены. Действительно, достаточно большое количество программных систем, особенно если речь идет о программных системах масштаба предприятия (enterprise systems), имеют именно слоистую структуру. Конечно, достаточно часто встречается ситуация, когда строгая послойная структура системы нарушается – как правило, это является следствием эрозии архитектуры (архитектурным дефектом) и ее устранение в большинстве случаев способно принести ощутимые выгоды (эти аспекты рассматриваются далее).
Альтернативная реализация. Можно выбирать альтернативную реализацию базовых слоев – компоненты верхнего слоя способны работать без каких-либо изменений в нижележащих слоях [7], при условии сохранения интерфейсов.
Минимизация интерфейсов. Зависимость между слоями, то есть, фактически, интерфейсы, предоставляемые нижними слоями верхним, можно свести к минимуму [7]. Такая минимизация интерфейсов – позволяет увеличивать гибкость системы.
Схема архитектурных слоев обладает и определенными недостатками [7]:
Каскадные изменения. Слои способны удачно инкапсулировать многое, но не все: модификация одного слоя подчас связана с необходимостью внесения каскадных изменений в остальные слои. Классический пример из области корпоративных программных приложений: поле, добавленное в таблицу базы данных, подлежит воспроизведению в графическом интерфейсе и должно найти соответствующее отображение в каждом промежуточном слое.
Падение производительности. Наличие избыточных слоев нередко снижает производительность системы. При переходе от слоя к слою данные обычно подвергаются преобразованиям из одного представления в другое. Несмотря на это, инкапсуляция нижележащих функций зачастую позволяет достичь весьма существенного преимущества. Например, оптимизация слоя транзакций обычно приводит к повышению производительности всех вышележащих слоев.
Имя блока: test, тип:
Таблица 1Таблица 1
| Корневая диаграмма |  |
Содержит: |
| Диаграмма |  |
Содержит: |
| Диаграмма a.cpp |  |
Содержит: Иcходящее отношение в блок a с диаграммы a.h, тип DECLARED-BY |
| Диаграмма a.h |  |
Содержит: Входящее отношение из блока a с диаграммы a.cpp, тип DECLARED-BY |
Тактика применения
Тактика применения паттерна выделения слоев имеет два основных аспекта: масштаб и время.Масштаб. Выделение слоев можно применять на разных масштабах и уровнях абстракции. Важно понимать, что каков бы ни был уровень абстракции, на котором идет рефакторинг, всегда можно попытаться выделить слои и иметь достаточно хорошие шансы на успех; при этом не так важно, идет ли моделирование в терминах пакетов, компонентов, или даже файлов.
Более того, слои облегчают изменение масштабов абстракции, используемые для моделирования. Если в системе найдены слои, то изменение масштабов можно производить и вручную – несколько соседних слоев достояно легко объединяются в один слой, происходит укрупнение подсистем, с которыми идет работа. Понижение масштаба может быть достигнуто за счет разбиения одного слоя на несколько подслоев. Следует заметить, что это не всегда возможно, в отличие от объединения слоев, особенно без предварительной подготовки и вспомогательного рефакторинга систем разбиваемого уровня.
Время. Этот аспект касается того, когда нужно применять выделение слоев. Это достаточно хороший паттерн, чтобы с него начать анализ и рефакторинг архитектуры системы, особенно, если эрозия архитектуры не катастрофична. Выделение слоев ведет к тому, что рефакторинг архитектуры приобретает "направленность", задача сводится к меньшим подзадачам; теперь детальный семантический анализ можно применять только к тем слоям, которые имею непосредственное отношение к поставленной задаче. Тем не менее, как и всякий другой паттерн, выделение слоев особенно хорошо работает в связке с другими паттернами. Шансы на успех резко вырастут, если провести предварительную подготовку, применив как минимум "удаление мертвых блоков" и "инкапсуляцию приватных блоков", описанных в [9].
Виды слоев
Строгие слои. Это слои, описанные в разделе 2.1. Канонический вариант слоев, не допускающий никаких отклонений в строгой структуре и потому встречающийся относительно редко. На рис. 2 А) могут быть выделены следующие строгие слои: слой 1 – блоки с номерами 5, 6. Слой 2 – блоки 3, 4. Слой 3 – блоки 1, 2.Как уже упоминалось, систем с четкой послойной структурой, также известной как строгие слои, значительно меньше, чем систем с
псевдослоями – то есть со структурой, близкой к послойной, но с допустимыми отклонениями. Далее рассматриваются некоторые виды послойных структур, используемых для рефакторинга архитектуры ПО.
Нестрогие слои (Non-strict layers). Смягчение условий: нестрогие слои допускают связи от вышележащего слоя к нескольким нижележащим слоям (потенциально – ко всем), а не только к непосредственному соседу снизу. Архитектура с нестрогими слоями может быть как результатом эрозии, так и осознанным решением.
Последствия: возможным дефектом архитектуры с нестрогими слоями является нарушение абстракции. Подобные дефекты затрудняют анализ системы. Кроме того, изменения слоя в такой архитектуре значительно сложнее локализовать – волна изменений прокатится по всем слоям, работающим с изменяемым слоем, то есть, в пессимистическом случае, по всем вышележащим слоям.
На рис. 2 Б) показаны шесть нестрогих слоев – по одному блоку в каждом слое: слой 1 – блок 6, слой 2 – блок 5, слой 3 – блок 4 и т.д. В то же время, выделение строгих слоев даст значительно более грубую структуризацию: слой 1 – блок 6, слой 2 – блок 5. Все остальные блоки попадут на "чердак", так как дальнейшее выделение строгих слоев невозможно – блок 4 нарушает строгую структуру и обращается к первому слою в обход второго слоя. Все оставшиеся блоки используют блок 4 и, соответственно, тоже попадают на "чердак".
Поглощение сильносвязанных компонентов (СК).
Смягчение условий: уже рассмотренные виды слоев можно модифицировать, позволив включать в произвольный слой СК [8]. При таком подходе СК рассматривается, фактически, как атомарный элемент.
Без подобного смягчения условий как сам СК, так и все блоки которые могли бы попасть в вышележащие слои, будут отправлены на "чердак". Действительно, рассмотренные подходы не смогут расщепить СК на слои, и он автоматически попадает на чердак, так же, как и блоки, зависящие от него. Тем не менее, отнюдь не всегда СК на структурных диаграммах свидетельствуют о плохой архитектуре системы. Например, в системах с рассылкой сообщений достаточно часто встречается сильносвязанный компонент, подобный представленному на рис 1: источник событий "знает" о зарегистрированных в нем слушателях (listeners), слушатели знают о событиях (events), отправляемых источником, а в событии содержится ссылка на его источник. Таким образом, представляется удобным выделять слои и на тех диаграммах, которые содержат СК, именно поэтому было введено поглощение.
Рис 1. События, слушатели и источники событий.
Последствия: возможным дефектом архитектуры с поглощающими слоями может стать эффект "пропавшего слоя" – дефектная связь приводит к появлению СК, которые по смыслу должны находится на разных слоях.
На рис. 2 В) при использовании поглощения СК можно выделить те же слои, что и в случае применения строгих слоев к 2 А). Слой 1 – блоки 5, 6. Слой 2 – блоки 3, 4. Слой 3 – блоки 1, 2. Если применять обычный поиск строгих слоев, то все блоки окажутся на "чердаке".
На рис. 2 Г) при использовании поглощения СК можно выделить слой 1 – блок 6, слой 2 – блок 5, слой 3 – блоки 3, 4, слой 4 – блоки 1, 2. Если применять обычный поиск нестрогих слоев, блоки 1, 2, 3, 4 окажутся на "чердаке", то есть структуризация в таком случае будет значительно хуже.
Рисунок 2. Примеры диаграмм.
В последнее время наблюдается тенденция
В последнее время наблюдается тенденция к увеличению продолжительности жизненного цикла успешных программных проектов. Как следствие, растет объем унаследованного кода, поддерживаемого сообществом разработчиков [1]. Именно это объясняет исключительную важность задач, связанных с облегчением сопровождения и развития существующего программного кода. В то же время, этим задачам уделяется недостаточное внимание со стороны научного сообщества и разработчиков инструментальных средств. Как следствие, современные методики переоценивают значение начальной фазы жизненного цикла программной системы и практически игнорируют ее дальнейшую эволюцию. Таким образом, в настоящее время существует явный недостаток методик и эффективных инструментов поддержки работы с существующим кодом.В последнее время наметился перелом ситуации: стали вызывать значительный интерес вопросы систематического использования трансформаций как центрального организующего принципа процесса развития и сопровождения существующего программного обеспечения. Однако большинство исследователей рассматривает трансформации достаточно узко – как трансформации на уровне исходного кода – рефакторинг [2]. Тем не менее, в настоящее время практически не существует исследований, посвященных трансформации на более высоком уровне абстракции – уровне архитектуры ПО. В то же время, многие сценарии сопровождения и развития существующего кода подразумевают изменение архитектуры существующей системы. В связи с этим, большой интерес вызывает разработка методики и сопровождающих ее инструментальных средств, нацеленных на организацию предсказуемого и управляемого процесса изменения архитектуры ПО.
В данной работе рассматриваются один из основных методов рефакторинга архитектуры ПО – выделение слоев, а также его место в контексте рефакторинга архитектуры как многошагового итеративного процесса.
Выделение слоев
Имеющийся опыт рефакторинга архитектуры программных систем позволил выделить несколько групп приемов, используемых наиболее часто. Эти приемы переходят из одного процесса рефакторинга архитектуры в другой с небольшими модификациями или даже вовсе без них. Естественно, повторяющиеся решения заслуживают выделения в самостоятельные паттерны или группы паттернов. Пожалуй, одним из важнейших и наиболее употребимых паттернов рефакторинга архитектуры ПО является паттерн "выделение слоев", рассматриваемый в этой статье.Значение паттерна "выделение слоев" легко объяснимо - слои обладают целым рядом замечательных свойств, делающих их незаменимым инструментом структуризации системы.
Зачем менять архитектуру?
Потребность в изменении существующего программного обеспечения может возникнуть в ходе решения широкого круга задач по его модернизации. В общем случае изменения существующего программного обеспечения способны затронуть не только его код, но и все остальные артефакты, связанные с трансформируемой программной системой. Одной из наиболее существенных разновидностей здесь является изменение архитектуры программной системы. В качестве примеров можно привести следующие сценарии, требующие изменения архитектуры существующего ПО:Преобразования, обусловленные функциональными изменениями ПО. Желательно, чтобы внедрение новой функциональности не затронуло существующую логику системы. Также желательно, чтобы сложность внедрения новой функциональности в существующую систему не превышало существенным образом сложность реализации этой функциональности в рамках нового проекта. Хорошая архитектура позволяет достичь поставленных целей. Итак, изменение существующей архитектуры – хороший шаг на пути внедрения новой функциональности, к тому же облегчающий и дальнейшую эволюцию системы.
Смена платформы ПО. Крайне желательно, чтобы смена платформы ПО как можно меньше затронула существующий код, и чтобы можно было ограничиться изменениями только в узкой платформенно-зависимой прослойке системы. Выделение такой прослойки – архитектурная задача. Ее решение всегда сопряжено с необходимостью изменения архитектуры.
Преобразования, связанные с реорганизацией компании, ведущей разработку. Примером, такой реорганизации может стать аутсорсинг. Решение об использовании аутсорсинга - типичный шаг по оптимизации производства. К сожалению, этот шаг зачастую затрудняется проблемой выделения и передачи компонентов для внешней разработки. Изменение архитектуры программной системы способно облегчить решение этой задачи.
Список сценариев приводящих к потребности в изменении архитектуры существующего ПО на этом не исчерпывается: приведенные выше примеры призваны лишь продемонстрировать широкий спектр задач, которые обусловливают необходимость подобных изменений.
Выделение слоев является одним из
Выделение слоев является одним из ключевых паттернов для анализа и улучшения архитектуры. Слои позволяют упорядочивать архитектурные модели и, следовательно, упрощать их анализ. Кроме того, существуют различные разновидности слоев и различные тактики применения этого паттерна. С архитектурной точки зрения, с каждой из разновидностей слоев связаны определенные плюсы и минусы, что позволяет быстро находить и устранять различные архитектурные дефекты.В заключении необходимо отметить, что поиск блоков, которые могут быть выделены в слой на больших диаграммах, представляется затруднительной задачей. Тем не менее, решение такой задачи достаточно легко автоматизировать. Для автоматического поиска кандидатов на объединение в новый слой достаточно перебрать блоки исследуемой структурной модели и проанализировать направления их связей. В частности, при создании примеров для этой статьи использовались подобные средства автоматического поиска слоев, реализованные как плагины к KLOCwork Architect.
Управление проектами - статьи
Анализ и оценка приоритетности
Выявленные риски следует проанализировать. Анализ включает оценку вероятности риска и его возможных последствий в кратко- и долгосрочном плане.Кроме того, анализ рисков предполагает сравнение новых рисков с ранее выявленными. Новый риск может повторять или расширять один из ранее выявленных. В таком случае следует не включать его в список рисков, а уточнить описание и оценки выявленного раньше риска.
Если же риск новый, его нужно оценить. По результатам опросов и интервью или по аналогии с ранее выполнявшимися проектами для риска оценивается вероятность проявления и тяжесть последствий. К сожалению, в таких случаях редко удается получить сколько-нибудь точные численные оценки. Тем не менее обычно не составляет труда выбрать для риска одно из заранее определенных значений вероятности (например, из уже упоминавшегося ряда от 0,1 до 0,9) и целочисленное значение тяжести последствий (скажем, от 1 до 5). Сделать это проще, чем оценить последствия в реальных деньгах. Вместе с тем такой оценки обычно хватает для решения главной проблемы — выделения наиболее приоритетных рисков. В результате возможные показатели приоритета (произведения вероятности проявления риска на тяжесть последствий) будут варьироваться в пределах от 0,1 до 4,5 (см. таблицу).
Таблица. Возможные значения приоритетов рисков
| 0.1 | 0.3 | 0.5 | 0.7 | 0.9 | |
| 1 | 0.1 |
0.3 |
0.5 |
0.7 |
0.9 |
| 2 | 0.2 |
0.6 |
1.0 |
1.4 |
1.8 |
| 3 | 0.3 |
0.9 |
1.5 |
2.1 |
2.7 |
| 4 | 0.4 |
1.2 |
2.0 |
2.8 |
3.6 |
| 5 | 0.5 |
1.5 |
2.5 |
3.5 |
4.5 |
Как правило, риски с текущим значением приоритета меньше 1 (выделены зеленым) просто игнорируются. Риски со значением приоритета в диапазоне 1—2 оставляются в списке, но реальных действий по их устранению обычно не предпринимается. Основное же внимание уделяется рискам с приоритетом больше 2.
Если для определения вероятности и последствий рисков использовались качественные оценки, то и приоритетность рисков оценивается на качественном уровне. Например, можно игнорировать те риски, у которых вероятность или последствия пренебрежимые. А высокоприоритетными следует считать риски, у которых вероятность выше средней и последствия выше существенных.
Как правило, список приоритетных рисков для проекта ограничивают десятью или двадцатью (для очень больших проектов) наиболее значимыми. Если учитывать большее число рисков, это, с одной стороны, приведет к существенно большему расходу ресурсов, а с другой стороны, почти не скажется на вероятности успешного завершения проекта. Списки наиболее приоритетных рисков должны быть доступны для всех участников проекта.
Для рисков с высоким приоритетом в ходе анализа очень полезно определить показатели (метрики), которые позволяют судить о приближении момента проявления риска или о существенном изменении вероятности его проявления.
Диалог с оппонентом
Типичный диалог специалиста по управлению рисками (Специалист) с менеджером проекта (МП), которому предстоит внедрять управление рисками в своем проекте, выглядит примерно так.МП: Зачем нужно управлять рисками? Может быть, в нашем проекте их вообще нет?
Специалист: Вот признаки, которые часто указывают на рискованный характер проекта:
Однако риски — это не особенность каких-то специфических проектов. Любой проект без труда можно сделать крайне рискованным. Для этого достаточно:
МП: Тогда, может быть, лучше посмотреть, какие именно риски реализуются, и потом бороться с возникшими проблемами?
Специалист: Как правило, последствия риска — не фиксированная величина. Они зависят от момента, когда риск выявлен. Например, если бы мы заранее учли, что нам придется перейти на другую СУБД, то большую часть бизнес-логики мы бы перенесли на сервер приложений. И нам не пришлось бы переписывать столько хранимых процедур и триггеров.
Этапы освоения
На пути к освоению процесса управления рисками команды обычно проходят через определенные стадии. Понимание того, на какой стадии вы находитесь, поможет выбрать ориентиры для следующего шага.Стадия 1. Решение проблем
Эта стадия соответствует исходному положению дел. Люди заняты решением уже возникших проблем, о будущем никто не думает. С рисками, даже известными, никто ничего не делает, пока они не превращаются в реальные проблемы. Это связано, в частности, с тем, что даже руководители не уверены в своих оценках вероятности проявления риска и его последствий. Поскольку руководство не поощряет сообщения о рисках, большинство о них и не упоминает. Стандартные процедуры если и существуют, то только для преодоления рисков, ставших проблемами.
Стадия 2. Снижение последствий
Это стадия соответствует началу внедрения управления рисками. Руководство проекта уже само спрашивает: “А что может не получиться? Какие могут возникнуть проблемы? А какие будут последствия?”. Команда понимает, что такое риск. Но еще не всегда хватает опыта для того, чтобы обсудить все необходимые детали. На этой стадии руководство обычно предпочитает формировать резервные планы, чтобы использовать их, если основной план провалится.
Стадия 3. Предотвращение рисков
На этой стадии управление рисками перестает быть прерогативой руководства и становится всеобщим процессом. Руководство понимает, что управлением рисками нельзя заниматься в одиночку, к этому процессу все больше привлекается команда, а затем и заказчик. Если для предыдущей стадии характерно внимание к затратам и планам (а это обычно только внешние симптомы технических рисков), то сейчас упор делается на выявление технических источников риска. Управление рисками превращается из пассивного, основанного на ожидании внешних событий, в активный процесс выявления потенциальных рисков. Члены команды приобретают опыт в выявлении рисков, но, возможно, еще затрудняются с количественными оценками.
Стадия 4. Предвосхищение рисков
На четвертой стадии происходит переход от качественных оценок и методов к количественным.
При этом начинают использоваться метрики, позволяющие обнаружить проявления предсказуемых рисков. Члены команды и заказчик используют количественные оценки для правильного определения приоритетов. Используются специальные меры для снижения вероятности или тяжести последствий риска, а также для выбора альтернативных решений (сам выбор упрощается при наличии количественных оценок). С такой системой раннего предупреждения ожидаемые проблемы исключаются с помощью предварительных коррекций.
Стадия 5. Учет возможностей
Пожалуй, настало время заняться и положительными рисками. На этой стадии управление рисками позволяет управлять будущим. Риски теперь воспринимаются как шанс выполнить работу лучше, чем планировалось, и уложиться в меньшую сумму затрат. В управление рисками, как в борьбу за качество, включились все. Профессиональный уровень позволяет всем участвовать в обсуждениях и предлагать собственные решения. Участники проекта понимают, что не все заранее известно, что существуют оптимистичные и пессимистичные сценарии. Они осознают, что каждый их выбор ведет к определенным затратам, это помогает им выбирать лучшее решение. Управление рисками выходит за пределы исходной задачи и становится мощным оружием.
В заключение осталось пожелать всем успешно освоить все перечисленные стадии. А чтобы наверняка этого добиться — управляйте рисками!
Мониторинг рисков
К сожалению, управление рисками — это не одноразовое мероприятие. Вероятность и последствия однажды выявленных рисков и оценка их приоритетности могут в дальнейшем измениться; могут появиться и новые риски. Например, по мере накопления сведений об определенных инструментах и методах у исполнителей растет уверенность, что работы могут быть выполнены в срок. Или, наоборот, опыт сборки и тестирования предварительных версий системы, возможно, заставляет усомниться в достаточной ее производительности. Это значит, что данные о рисках должны регулярно обновляться. Повторный анализ рисков желательно провести таким образом, чтобы свежие сведения можно было использовать при планировании очередной итерации проекта.Специальный случай мониторинга — анализ показателей (метрик), которые могут указывать на приближение или скрытую реализацию одного из выявленных ранее рисков. Метрики должны вычисляться достаточно часто. Изменение значений свыше установленного предела должно быть поводом к внеочередному анализу и оценке рисков.
Некоторые практические рекомендации
Опыт управления рисками позволил определить несколько типичных приемов, как правило, существенно повышающих качество процесса.Формализация управления рисками. Борьбу с рисками нужно оформить официально и определить необходимые формальные процедуры. Для реализации процесса назначается ответственный. Составляется и регулярно обновляется план работ по управлению рисками. Ведется формальная база данных рисков или хотя бы их список. Проводится формальное отслеживание рисков. Регулярно формируются и доводятся до всех участников проекта отчеты о состоянии рисков. Результаты управления рисками активно используются в управлении проектом. Без такой формализации исполнители в текучке могут просто забыть о новой работе, либо не удается преодолеть негативное отношение участников разработки к процессу управления требованиями.
Выделение специальных резервов для нейтрализации рисков. Для борьбы с рисками заранее планируются резервы, включающие резерв времени (обычно порядка 10% от оцененного времени выполнения проекта); резерв денежных средств на дополнительный штат, инструменты, дополнительное время разработки; собственно резервный штат, включая список специалистов, которых можно быстро привлечь к работе.
Отсутствие резервов может вызвать очень тяжелые последствия вплоть до полной остановки работ по проекту. Объем резервов должен согласовываться с текущей оценкой рисков. При использовании части средств для борьбы с проявившимся риском объем резервов должен быть пересмотрен и при необходимости увеличен.
Эффективное использование резервов требует определенной подготовки. Необходимо готовить резервные планы, заранее учитывать сложность ввода новых специалистов в проект. Например, желательно подготовить в компании резерв сотрудников, знакомых с проектом хотя бы в общих чертах. Это могут быть, например, сотрудники, привлекавшиеся к рецензированию материалов проекта.
Использование формальных показателей (метрик) для управления рисками. Уже упоминавшиеся метрики — весьма действенное средство своевременного выявления и мониторинга рисков.
Имеется в виду, что метрики должны быть определены заранее и использоваться для формирования предупреждений. При выходе за предустановленные пределы значений (например, если первоначально запланированный объем кода превышен на 10%) или при выполнении особых условий (к заданному сроку не найден квалифицированный персонал) автоматически формируется предупреждение для управляющего персонала.
Определять критерии формирования таких предупреждений можно с помощью различных методов анализа временных рядов для “долгоиграющих” рисков. Формирование критериев в любом случае требует определенного опыта работы по управлению рисками и набора предварительной статистики.
В качестве показателей обычно используются метрики, связанные с бюджетом, размерами системы, ходом выполнения графика работ, количеством обнаруживаемых дефектов и скоростью их устранения.
Непрерывное управление рисками. Мы уже говорили об этом, но все же повторим. Чтобы управление рисками было действительно эффективным, надо осуществлять его на непрерывной основе в течение всего жизненного цикла проекта. Повторный анализ рисков позволяет уточнить оценки вероятности проявления и последствий. Регулярные отчеты о наиболее существенных рисках позволяют повысить качество управления проектами.
Отслеживание внешних зависимостей. Внешние причины, скажем, задержки поставки отдельных программных компонентов или оборудования, также часто выступают как весьма приоритетные риски проекта. Для их снижения требуются специальные меры, такие, как регулярный мониторинг хода разработки у поставщика или поиск альтернативных поставщиков. Кроме того, руководство фирмы должно понимать, что эти риски находятся вне компетенции участников проекта.
Основные понятия
Выполнение проектов, особенно если они связаны с разработкой программного обеспечения (ПО), — явно не детерминированный процесс. Новизна используемых технологий, сложность заданий, отсутствие у разработчиков необходимой квалификации — из-за этих и многих других факторов проекты часто идут не так, как планировалось. Один из приемов, повышающих вероятность успеха в таких условиях, — использование методов управления рисками. Традиционно под управлением рисками понимают процесс идентификации и анализа событий и ответа на них. При этом ставится цель максимизировать вероятность положительных событий и их последствия и минимизировать вероятность и последствия событий неблагоприятных. Впрочем, достаточно часто ограничиваются работой только с негативными событиями.Введем несколько формальных определений.
Риск — это событие, способное (в случае его реализации) оказать влияние на ход выполнения проекта. Риски существуют во всех проектах, но не всегда реализуются. Риск, который реализовался, превращается в проблему.
Воздействие, или последствие риска — влияние реализовавшегося риска на возможность выполнить определенные составляющие плана. Воздействие обычно касается стоимости, графика и технических характеристик разрабатываемого продукта. К примеру, при разработке ПО воздействие риска может привести к тому, что продукт перестанет удовлетворять заказчика в полной мере или даже станет непригодным. Воздействие часто имеет скрытый период — от момента проявления риска до появления результирующего изменения в системе. Для оценки воздействия риска обычно используют условные единицы или качественную шкалу (например, пренебрежимое, малое, существенное, большое, катастрофическое). Для работы с положительными рисками нужно соответствующим образом расширить шкалу.
Вероятность риска — вероятность, с которой данный риск превратится в проблему. Здесь также применима качественная шкала (пренебрежимая вероятность, малая и т. д. — вплоть до весьма вероятной). Но могут использоваться и численные значения (обычно выбирают некоторый набор типовых значений, например, 0,1; 0,3; 0,5; 0,7; 0,9).
Следует отметить, что событие, которое должно обязательно произойти, не является риском, и действия, которые необходимо в связи с ним предпринять, определяются в рамках обычного планирования и управления, а не управления рисками.
Управление рисками — это процедуры и действия, которые позволяют менеджеру выявлять, оценивать, отслеживать и устранять риски до или во время их превращения в проблемы. Риски желательно выявить как можно раньше и заведомо еще до того, как они превратились в проблему (обычно в этом случае принятие мер требует меньших ресурсов). После выявления риска необходимо принять решение об ответных действиях. Задача руководителя проекта — выбрать такие действия, которые позволят снизить вероятность неблагоприятного события или уменьшить его последствия в случае реализации риска. При этом желательно, чтобы расход ресурсов был минимальным.
Наиболее часто используются следующие стратегии борьбы с риском.
1. Избежать риска. Реорганизовать проект таким образом, чтобы он не зависел от данного события. Например, при разработке ПО можно исключить вызывающую сомнение функциональность. К сожалению, таким образом редко удается полностью удовлетворить заказчика.
2. Переадресовать риск. Исполнитель прибегает к своего рода страховке — если проявится риск, заказчик берет на себя оплату дополнительных работ. В случае реализации такого риска руководство компании обязуется привлечь к проекту еще некоторое количество сотрудников.
3. Согласиться с присутствием риска. Это не означает, что не надо ничего делать, а просто пассивно ждать реализации риска. Согласившись с присутствием риска, можно предпринять некие действия, направленные на снижение вероятности его проявления, уменьшение его последствий (например, предусмотреть такую архитектуру системы, которая позволит компенсировать потерю производительности) либо разработать план альтернативных действий (например, перехода на другую СУБД), который будет выполняться, если риск реализуется.
Список рисков — упорядоченный по приоритету список выявленных и отслеживаемых рисков.Приоритет определяется как произведение вероятности на величину воздействия (в условных единицах).
Основные проблемы
Управление рисками — несложный и нетрудоемкий процесс. Больших проблем с его внедрением теоретически быть не должно. Но, к сожалению, сказать, что он внедрен повсеместно, нельзя. И дело здесь не только в технических трудностях, но и в традициях, которые часто приходится при этом ломать.Если спросить у рядового разработчика или руководителя, почему в их фирме нет процесса управления рисками, можно услышать массу самых разных ответов. Тут будет и самое простое: “У нас нет рисков”, и более изощренные варианты: “Мы боремся с проблемами по мере их возникновения”, “Наше дело — разработка программы, а не заполнение бюрократических форм”, “Использование этого инструмента не рискованно. Так нам сказал поставщик”. Реальные же причины нелюбви к управлению рисками чаще всего кроятся в следующем.
Прежде всего руководство боится отойти от традиционной позиции “мы это обязательно сделаем”. Управление рисками предполагает, что могут быть и неудачи. А отсюда и следующая причина: руководство часто рассматривает управление рисками как способ, позволяющий подчиненным обосновать будущее поражение. Хотя реально речь идет как раз о мерах по повышению вероятности успешного выполнения проектов.
Руководители проектов тоже нередко побаиваются управления рисками. Они считают, что если заранее выявленный риск все-таки реализуется, это будет рассматриваться как их ошибка. Хотя реально такая ситуация обычно позволяет продемонстрировать, насколько удалось снизить потенциальные последствия риска с помощью превентивных мер.
Есть свои причины не любить управление рисками и у исполнителей. С одной стороны, можно опасаться, что на принесшего плохую весть повалятся все шишки за ее последствия. С другой — в условиях налаженного управления рисками пропадает необходимость в подвигах. А ведь так приятно чувствовать себя героем, спасшим проект от очередной проблемы!
Таким образом, внедрение управления рисками часто требует существенного изменения всей корпоративной культуры. Ниже мы рассмотрим в числе прочего некоторые методы и приемы, позволяющие ускорить этот процесс.
Планирование ответных действий
Для каждого из рисков, вошедших в список приоритетных, необходимо выбрать стратегию реагирования. Как уже говорилось, стратегия может быть направлена на то, чтобы “обойти” риск, застраховаться от него или смягчить его последствия. Иногда риск можно исключить полностью, отказавшись от одного-двух низкоприоритетных свойств системы. В других случаях можно попытаться использовать более зрелые или лучше известные разработчикам технологии.В случае внешних рисков, на которые практически невозможно как-то воздействовать, единственным ответом будет резервирование дополнительных ресурсов. Как говорят, на этот случай можно даже оформить страховку в страховой компании. Как минимум, следует оговорить потенциальный риск с руководством собственной компании и с заказчиком.
И, наконец, существуют риски, относящиеся к категории достаточно приоритетных и при этом поддающиеся воздействию. Это и есть основное поле битвы. Для таких рисков необходимо выбрать действия, которые помогут снизить вероятность наступления события и его возможные последствия.
Строго говоря, задача не в том, чтобы свести возможность проявления риска или его последствия к нулю. Если такое решение и достижимо, оно может потребовать слишком много ресурсов. Реальная цель — снизить вероятность и последствия проявления риска до приемлемого уровня.
Если вы уверены в пригодности вероятностной модели для ваших рисков и в точности ваших оценок, то для анализа принимаемых решений и выбора оптимального можно применить, например, байесов подход. Оптимальным будет решение, которое минимизирует среднюю стоимость выполнения проекта или максимизирует среднюю прибыль. Но для этого требуется перевести используемые условные единицы в деньги, и в деньгах же оценивать стоимость планируемых мероприятий по преодолению рисков.
Для рисков, не устраненных окончательно или не поддающихся "смягчению", нужно разработать хотя бы предварительный резервный план действий на случай их проявления (часто его называют “план Б”).
Для части рисков, обычно связанных с недостатком информации, можно явно указать действие, которое определит, проявится риск или нет. Например, чтобы понять, удастся ли интегрировать новую систему в уже существующую инфраструктуру, как правило, достаточно создать небольшой прототип новой системы. Он либо покажет, как должна осуществляться интеграция, либо заставит проявиться соответствующий риск. Типичный прием — запланировать такие действия на возможно более ранние сроки. Это позволяет, с одной стороны, менее спешно и более осмысленно предпринимать ответные действия, с другой стороны — раньше выявить новые риски, которые могут возникнуть после проявления уже известных.
Планирование управления рисками
В планировании управления рисками есть ряд главных моментов.Назначение ответственного лица. Отвечать за процесс должен один человек, который собирает сведения о возможных рисках, организует их анализ и формирует регулярные отчеты. Чаще всего это не требует полной занятости — ответственный может выполнять и другие роли в проекте. Планирование и выполнение действий, направленных на снижение рисков, остается в ведении руководителя проекта. Выделение специального человека, в чьи обязанности входит выявление рисков, и введение дополнительных премий тем, кто выявил риск, помогает бороться с негативным отношением к управлению рисками в команде.
Определение тактики и методов, применяемых в конкретном проекте для выявления, анализа и снижения рисков. Это может быть метод исключения рискованных решений или разработка запасных планов. Здесь же устанавливаются поощрения для сотрудников, указавших на реализовавшиеся риски или предложивших наиболее эффективные меры по их устранению и т. п.
Определение бюджета, предназначенного для управления рисками. Бюджет существенно влияет на ассортимент средств, которыми можно воспользоваться для преодоления рисков.
Планирование основных действий по управлению рисками и их привязка к жизненному циклу проекта (согласование сроков мероприятий, направленных на управление рисками, с основными производственными процессами).
Сведения об авторах:
Автор работает в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК, г. Москва.Закис Алексей – главный специалист управления методологии создания и сопровождения программного обеспечения.
Если Вас заинтересовал данный материал, то можете присылать вопросы по адресу: , .
Выявление рисков
Риски, с которыми приходится иметь дело в проектах разработки ПО, можно условно разбить на несколько типов:1. Технические риски, связанные с разработкой новых решений или изменением старых, направленным на повышение производительности или достижение принципиально новой функциональности.
2. Программные риски, связанные с приобретением или использованием ПО третьих фирм (если это приобретение не находится под должным контролем разработчиков и руководителей проекта).
3. Риски на этапе сопровождения системы, в том числе связанные с размещением ПО у заказчика, поддержкой, обучением и т. п.
4. Стоимостные риски, связанные с превышением затрат или проблемами финансирования проекта.
5. Риски сроков, связанные с необходимостью ускорить разработку из-за внешних причин.
6. Риски неудовлетворенности заказчика.
Чтобы определить риски проекта, обычно используются следующие четыре метода.
Исторический анализ. Сравнение данного проекта с аналогичными, выполненными ранее. Вчерашние проблемы часто остаются рисками в новых проектах.
Аналитический метод. Включает такие технологии, как моделирование, анализ по схеме "причина-результат", анализ таблиц истинности и т. д.
Совещания, посвященные выявлению и оценке рисков. Как правило, они проводятся с использованием мозгового штурма. Если число участников проекта невелико, они все приглашаются на совещание. В противном случае собирают только лидеров групп и ведущих разработчиков.
Индивидуальные интервью. Проводятся как с руководством проекта, так и с рядовыми участниками. По желанию интервьюируемых они могут остаться анонимными и не упоминаться как “источники” риска. Сотрудники могут даже присылать свои сообщения анонимно по электронной почте — анонимность позволяет избежать опасений, что “принесшего дурную весть накажут”.
Каждый выявленный риск необходимо документировать, записав суть риска и причины, которые могут его вызвать.
Задачи управления рисками
Процесс управления рисками разделяется на несколько составляющих. Специалисты несколько расходятся во мнениях по поводу их числа и классификации, но, на наш взгляд, достаточно полным можно считать следующий перечень.Планирование управления рисками. План должен описывать общие подходы к управлению рисками в проекте и основные действия, которые придется выполнять.
Выявление рисков. Необходимо определить те ситуации или события, которые могут вызвать отрицательные последствия для проекта. Участники проекта выявляют риски на основе своего опыта, приобретенного в предыдущих проектах или на предыдущих стадиях данного проекта. Выявленные риски тщательно документируются.
Анализ и оценка приоритетности рисков. Выявленный риск следует проанализировать, чтобы определить его потенциальное влияние на расходы, график работ и т. д. Для каждого риска оценивается также вероятность, с которой он может реализоваться. Приоритет риска определяется на основе произведения его вероятности на возможные последствия (выражаемые величиной ожидаемого ущерба).
Планирование ответных действий. Для каждого риска определяются шаги, необходимые для снижения вероятности проявления риска и его последствий. Выполнение планов не входит в процесс управления рисками, оно осуществляется в рамках основных процессов разработки. Для борьбы с рисками можно планировать не только действия, но и соответствующие резервы (деньги, время, люди).
Мониторинг рисков. Цель данной меры — изменение приоритетов и планов преодоления рисков при изменении их вероятности и последствий, а также своевременное выявление рисков, которые реализуются в данный момент. По сути представляет собой повторение шагов выявления и анализа рисков.
Рассмотрим перечисленные задачи более детально.
Управление проектами - статьи
Алгоритм построения машин состояний по диаграммам последовательностей
Сделаем обзор алгоритма построения машины состояния, работающего в случае анонимных ролей:Кратко опишем эти фазы.
Фазы синтаксического разбора и построения графов диаграмм зависят от синтаксиса их записи. В результате для каждой диаграммы обзора взаимодействий строится внутреннее представление графа, который состоит из диаграмм и связей между ними, задающих их последовательность. Для диаграмм последовательностей строятся события (и так называемые псевдособытия) и связи, задающие их последовательность на данной оси. Для inline-конструкций и ссылок на другие диаграммы строятся псевдособытия. Также строятся связи между множествами событий (и псевдособытий) на разных осях, если они взаимосвязаны - т.е. для пар событий посылки-приема сообщения, псевдособытий, соответствующих началам и концам ссылок на другие диаграммы, началам и окончаниям inline-конструкций.
Для объединения поведений в соответствии с графом использования (через ссылки) диаграммами друг друга выбирается диаграмма самого верхнего уровня (считается недопустимым случай рекурсивных ссылок диаграмм друг на друга), и, начиная с этой диаграммы, рекурсивно применяется подстановка поведения используемых в ней диаграмм. После этого производится объединение поведений, заданных различными диаграммами: для каждой пары следования фрагментов взаимодействия происходит построение связей между псевдособытием "конца" каждой оси из предшествующего фрагмента с псевдособытием "начала" оси последующего фрагмента.
По срезам модели, построенным для каждого объекта системы взаимодействий, строятся автоматы: каждое событие среза отображается в переход автомата по этому событию, а каждая связь между событиями на одной оси - в состояние автомата.
Для псевдособытий строятся пустые переходы.
После этого производится преобразование автоматов в эквивалентные детерминированные автоматы, после чего полученные автоматы структуризируются в соответствии с требованиями машин состояний.
Таким образом, в полученной машине состояний событиям соответствуют те элементы диаграмм взаимодействия, которые носят конструктивную семантику - т.е. посылка и прием сообщения, выполнение действия, порождение объекта. Элементам, семантика которых носит характер ограничений, как, например, конструкции временных ограничений, инварианты, соответствуют некоторые атрибуты событий, задающие условия, невыполнение которых означает динамическую ошибку.
Описанный алгоритм реализован для MSC-диаграмм в синтезаторе Bridge, разработанном в Институте системного программирования РАН совместно с компанией Klocwork. По построенным автоматам может генерироваться модель системы на языке SDL (очень близком к протокольным машинам состояний UML), прототип системы на языках Си/C++ или Java, тесты для системы на языках TTCN и PPL.
Для рассмотренного в начале примера спецификации системы обмена данными будут сгенерированы (с точностью до имен состояний) автоматы, изображенные в форме машин состояний на Рис. 15.
Рис. 15. Машины состояний для объектов модельной системы обмена данными.
Степень аппроксимации исходных сценариев автоматными моделями, построенными таким образом, обсуждается в работе [].
Формализация понятия роли
Этот раздел посвящен уточнению понятия роли для последующего использования этого понятия в моделях. Сначала мы рассмотрим свойства ролей, рассматривающиеся в литературе, а затем обозначим контекст использования нами этого понятия в сценариях взаимодействий.Использование ролей в сценариях взаимодействия
,Труды Института системного программирования РАН
Сценарий взаимодействия описывает поведение системы через описания взаимодействий некоторых объектов. Такими объектами выступают компоненты системы и внешние объекты, называемые акторами (actors). Обычно в сценарии взаимодействия подразумевается уникальность каждого объекта системы, т.е. предполагается, что описываются физически различные экземпляры объектов. Однако в ряде случаев это приводит к дублированию при описании сценариев. В работе предлагается расширить аппарат сценариев взаимодействия, разрешив использование ролей объектов. Роль соответствует некоторому срезу поведения определенного физического объекта. При таком подходе к описанию поведения возникает задача композиции поведения объектов в различных ролях. В данной статье рассматривается возможность систематического использования понятия роли в сценариях и исследуются средства, позволяющие строить общее поведение для объектов моделируемой системы по их поведению в различных ролях. Для представления сценариев используется модель взаимодействий UML (UML Interactions). В качестве абстрактных моделей для описания общего поведения объектов рассматриваются автоматные модели и модели, основанные на сетях Петри, в нотации UML (машины состояний и активности соответственно).
в этой спецификации есть некоторая
Следует отметить, что в этой спецификации есть некоторая неопределенность, связанная с тем, что в самом начале взаимодействия не задан способ выбора роли (Sender или Receiver) объектом типа Node. Эта неопределенность может приводить в данном случае к тупиковым ситуациям в функционировании системы, когда объекты совместно начинают выполнять роль Receiver, в результате чего бесконечно ожидают приема сигнала.Такое расширение композиции через конструкции продолжения дополнительно обеспечивает следующую заслуживающую внимания возможность. Рассмотрим систему, состоящую из вычислителя (Calculator), который может вычислять функции f1 и f2 и терминалов (Terminal), обращающихся к нему за вычислением этих функций. Пусть терминал должен запрашивать вычисление функций, чередуя f1 и f2, а вычислитель должен обладать возможностью производить вычисления функций в любом порядке. Поведение этой системы может быть описано с помощью диаграмм, представленных на Рис. 11.
Рис. 11. Спецификация системы вычислителя с несколькими терминалами
Тогда в соответствии с правилом композиции описанное здесь поведение для терминала может быть проиллюстрировано обзорной диаграммой взаимодействий, изображенной на Рис. 12.
Рис. 12. Поведение вычислителя
В рассмотренном варианте задания композиции элементы, собственно специфицирующие эту композицию, оказываются инкапсулированными внутрь описания отдельного взаимодействия. Это приводит к снижению наглядности описания системы.
Помимо этого, использование такой нотации привносит некоторую автоматоподобную семантику описания, причем в рамках каждого отдельного объекта системы, что не слишком соответствует логике нотации моделей взаимодействий и увеличивает вероятность создания внутренне противоречивых моделей.
Композиция через конструкции "продолжения"
Спецификация UML предлагает дополнительный способ композиции поведения через конструкцию продолжения (continuation) осей. Семантика таких конструкций носит характер "склейки" поведения по меткам: после фрагмента взаимодействий, заканчивающегося конструкцией продолжения с именем "X", допустимо продолжение по тем ветвям следующего фрагмента взаимодействий, которые начинаются с конструкции продолжения с тем же именем "X". Это может быть проиллюстрировано примером, взятым из спецификации UML: диаграмма Continue со ссылкой на диаграмму Question (Рис. 8) эквивалентна диаграмме, представленной на Рис. 9.
Рис. 8. Пример из спецификации UML: композиция с помощью конструкции "продолжения"
Рис. 9. Пример из спецификации UML: результат композиции с помощью конструкции "продолжения"
Для целей композиции поведения объектов в различных ролях разрешим использование конструкции продолжения не только в варианте, когда она покрывает все оси объектов, участвующих во фрагменте взаимодействия. Кроме того, дополнительно будем использовать следующее правило композиции: на диаграмме, следующей за данной диаграммой, в качестве возможных осей, которые соответствуют продолжению описания поведения, задаваемого осью на данной диаграмме взаимодействий (следование задается переходом между диаграммами на обзорной диаграмме), рассматриваются оси с тем же типом, роль же может быть другой. Естественно, что в качестве продолжения при исполнении выбирается лишь одна ось, в соответствии с выполнением предусловий для данного объекта.
Тогда можно рассмотреть спецификацию системы обмена данными, представленную на Рис. 10, которая будет эквивалентна исходной (Рис. 2), в предположении, что объекты A и B в исходном случае - это узлы некоторого одного типа Node.
Рис. 10. Спецификация модельной системы обмена данными с помощью конструкций "продолжения"
Данная спецификация задает поведение объектов типа Node. Каждый вариант взаимодействия в этой спецификации описан один раз для своего набора ролей, однако несколько утеряна наглядность, присущая диаграммам взаимодействия, вследствие необходимости отслеживать имена меток конструкций продолжения.
Композиция через параметризацию диаграмм по осям
Рассмотрим альтернативный вариант композиции, в котором используется параметризация диаграмм.Спецификация UML не говорит явно о возможности параметризации имен осей, однако заметим, что стандарт MSC позволяет задавать имена осей в качестве параметров MSC-диаграммы.
Будем считать параметризацию осей возможной. Тогда, используя ее, рассматриваемую модель обмена данными можно описать с помощью диаграмм, представленных на Рис. 13.
Рис. 13. Спецификация модельной системы обмена данными с помощью параметризации диаграмм по осям
Можно рассматривать статическую и динамическую семантику параметризации. Для статического случая результат соответствует макроподстановке диаграммы вместо ссылки на нее; динамическому случаю соответствует вызов поведения некоторой подсистемы. Связывание фактического параметра, соответствующего некоторому объекту определенного типа, и формального параметра, соответствующего роли в данном взаимодействии, означает вовлечение (acquirement) этого объекта в данную роль. В зависимости от семантики параметризации можно говорить либо о статическом "обладании" объектом своими ролями, либо о динамическом "принятии" в роли; это согласуется с различиями архитектурного моделирования ролей.
Заметим, что в данном случае пришлось продублировать описания ссылок на описания протоколов; вместо этого можно попытаться явно описывать задающие значения параметров потоки объектов между диаграммами,.
Композиция через задание потоков объектов
Снимем некоторые ограничения обзорных диаграмм взаимодействия, приблизив их к диаграммам активности. Рассмотрим возможность ограничения на потоки объектов между диаграммами путем задания их типа. Для этого мы будем использовать символы объектов на дугах диаграмм. Мы будем считать, что такой переход может сработать для маркера, если он поставлен в соответствие объекту, имеющему тип, который соответствует типу, указанному на этом переходе (в качестве вариантов можно рассматривать как строгое соответствие, так и соответствие какому-либо более общему типу). Для переходов с отсутствием такой спецификации предполагается, что они могут срабатывать для маркеров любого типа.
Рис. 14. Спецификация модельной системы обмена данными с помощью явного задания потоков объектов
По смыслу такое описание (рис. 14) сходно с параметризацией, но с явным указанием входных и выходных потоков фактических параметров. Применение таких потоков позволило избежать дублирования ссылок, но при этом сделало более сложным само описание композиции.
Композиция поведения в разных ролях
В данном разделе будут рассматриваться подходы, позволяющие решать задачу описания построения композиции поведения в различных ролях. Для этого будут рассмотрены некоторые расширения семантики диаграмм взаимодействия. Прежде чем перейти к рассмотрению расширений, уточним семантику обзорных диаграмм взаимодействия.Отображение в другие модели
Необходимость композиции поведения объектов в различных ролях приводит к еще одному источнику нежелательного поведения системы, не отраженного в сценарной модели; мы столкнулись с одним из таких примеров в предыдущем разделе. Как говорилось во введении, аппроксимация поведения модели взаимодействия другими моделями может помочь выявить пробелы в понимании требований к системе. Ниже мы рассмотрим возможность отображения модели последовательностей в две другие модели UML, позволяющие описывать поведение системы - это автоматные модели (машины состояний) и активности.Модель машины состояний хорошо подходит для описания поведения отдельного объекта. Для описания систем, состоящих из некоторого набора взаимодействующих объектов, используются модели, представляющих собой набор таких машин состояний, каждая их которых дает описание поведение отдельного объекта системы. При этом предполагается, что существует некоторое окружение (среда поддержки), которое отвечает за передачу сообщений между экземплярами таких машин. Это окружение относится уже к платформо-зависимому уровню системы, сами же машины достаточно просто отображаются в код, поэтому такие модели широко используются для прототипирования. С другой стороны, в таких моделях утеряны явные связи между отдельными объектами системы, модели же активностей, моделирующие как потоки управления, так и потоки данных в системе, позволяют исследовать поведение системы не покомпонентно, а в целом. Поэтому интерес представляет отображение в обе эти модели.
Отображение в модель активностей
Диаграммы активностей, используя семантику, сходную с семантикой сетей Петри, хорошо описывают работу системы в целом, так как явным образом моделируют и передачу сообщений. Построение моделей активностей UML по сценариям, описанным с помощью моделей взаимодействий, могло бы позволить производить статическую проверку требований к системе.Соображения о возможности построения отображения из моделей взаимодействий UML в модели активностей основываются на возможности использования для обзорных диаграмм взаимодействия семантики в стиле сетей Петри, а также возможности отображения отдельных взаимодействий в активности, что продемонстрировано на Рис. 19.
Рис. 19. Отображение взаимодействий в активности
Отметим, что существуют работы, в которых рассматриваемся формализация исполняемой семантики взаимодействий через сети Петри - см. [].
Результат фазы интеграции в алгоритме построения машин состояний, описанном в предыдущем разделе, практически соответствует диаграмме активности и может быть отображен в нее.
Можно рассматривать вопрос и о структурировании диаграмм активностей в соответствии с имеющимися сценариями и общими в них ролями.
Также возможно отображение машин состояний в диаграммы активностей []. Можно сделать предположение, что существо различия между моделью активностей, построенной по UML-взаимодействиям, и моделью активностей, построенной по машинам состояний, которые сгенерированы из тех же UML-взаимодействий, заключается в том, что моделирование передачи сообщений в первом случае происходит отдельными потоками сообщений между активностями посылки и приема, а во втором представляет собой некоторый общий поток, соответствующий каналу передачи. В этом случае модель активностей потенциально может являться некоторым базисом для сравнения поведений.
Отображение в модель машин состояний
Для спецификации поведения объектов системы применяются подходы, основанные на событийных автоматах; в таком случае поведение каждого компонента системы задается расширенным конечным автоматом. Событийные автоматы довольно легко отображаются в код на целевых языках; кроме того, существуют такие распространенные нотации как SDL [] и машины состояний UML, в которых используется семантика автоматов.Под машинами состояний (State Machines) мы понимаем расширенные конечные автоматы в алфавите событий, возможных в системе. Для этих автоматов должны выполняться некоторые дополнительные требования, которые заключаются в выделении некоторых типов состояний автомата, различающихся видами событий, по которым возможны переходы из этих состояний. Эти виды следующие:
Состояния ожидания автоматов соответствуют собственно состояниям машин, остальные состояния автоматов соответствуют так называемым псевдосостояниям.
Расширение алгоритма синтеза при использовании средств для композиции ролей
В настоящее время для приведенного алгоритма в синтезаторе Bridge реализовано расширение, заключающееся в возможности использования параметризованных ссылок; в том числе, параметризованы могут быть и оси диаграммы. Для этого на фазе интеграции поведений в момент подстановки копии диаграммы, на которую идет ссылка, производится замена формальных параметров на фактические; по существу, это соответствует выполнению параметризованной макроподстановки.Для возможности построения композиции с помощью конструкций продолжения требуется некоторое расширение алгоритма, позволяющее производить такую "склейку" осей.
Рассматриваемые расширения алгоритма синтеза касаются фаз подстановки и построения срезов.
Роли в моделях взаимодействия
Описание взаимодействий в виде диаграммы последовательностей представляет собой набор осей (lifelines), некоторым образом сопоставляемых объектам, каждая из которых задает порядок наступления определенных событий для соответствующего объекта и выполнения им некоторых действий.Мы будем придерживаться следующего соглашения об использовании синтаксиса именования оси:
<идентификатор_оси> ::= [<имя_элемента>] [: <имя_класса>]
(причем <идентификатор оси> не может быть пустым).
Трактоваться <идентификатор_оси> будет следующим образом: <имя_элемента> обозначает имя роли объекта, которому данная ось ставится в соответствие, а <имя_класса> - тип объекта. В случае, когда опущено имя роли, предполагается, что объект играет некую, так называемую, анонимную роль. Если опущено имя класса, предполагается, что тип объекта может быть произвольным.
В качестве близкого к реальным системам примера рассмотрим модель сети мобильной связи, в которой есть телефоны (Telephone), передатчики (Transmitter) и центральный коммутатор (Switch). Для такой системы можно выделить следующие протоколы:
Мы не будем описывать полную сценарную спецификацию для этой системы, однако приведем ее некоторые возможные сценарии (Рис. 1): запрос на установление соединения (Connection), передача данных (Transmitting), смена станции (Relocation).
Рис. 1. Сценарии системы мобильной связи
По приведенным сценариям видно, что для, например, телефонного аппарата абонента (Telephone) существуют, по крайней мере, такие роли как:
Рассматривая эти роли, можно уже указать на важность построения композиции поведения - ясно, например, что роли Sender и Receiver могут выполняться аппаратом после ролей Caller или Callee, причем роли Sender и Receiver могут выполняться аппаратом одновременно.
Поведение, соответствующее роли Migrator, аппарат может выполнять одновременно с любой другой из этих ролей. На этом примере видно, что задание композиции поведения объектов в разных ролях может быть важно для адекватного описания поведения как системы.
Далее, во избежание громоздкости, в качестве модельного примера будет рассматриваться следующая спецификация достаточно простой системы, ее можно считать сильным упрощением описанной системы мобильной связи.
Итак, рассмотрим систему обмена данными (Рис. 2), состоящую из двух узлов A и B, которые могут по очереди обмениваться сообщениями с данными (data) до тех пор, пока один из них не пошлет сообщение о завершении серии обменов (stop).
Рис. 2. Спецификация модельной системы обмена данными
По существу, в рассматриваемой спецификации имеются только два различных взаимодействия (Рис. 3; здесь опущены конкретные имена типов объектов) - это протокол передачи данных и протокол завершения обмена данными; для данного модельного примера эти протоколы тривиальны.
Рис. 3. Взаимодействия в системе обмена данными.
Протокол передачи данных описывает поведение двух сторон - объекта, играющего роль отправителя данных (DataSender), и объекта, играющего роль получателя данных (DataReceiver). В контексте завершения сеанса передачи можно говорить о роли объекта, инициирующего завершение (TerminationInitiator), и роли объекта, извещаемого о завершении (TerminationAcceptor). В этом примере следует обратить внимание, на то, что, прибегая к абстрагированию, можно говорить не об описании поведения объектов, а об описании поведения ролей, которые объекты могут выполнять.
В данной спецификации эти протоколы пришлось продублировать для вариантов разных сочетаний объектов A и B и их возможных ролей.
Теперь рассмотрим следующие два вопроса:
С использованием понятия ролей эти вопросы могут быть переформулированы следующим образом:
При успешном решении этих задач выделение понятия роли в сценариях позволит избежать дублирований при их описании. Случаи осмысленного выделения ролей, соответствуют ситуациям, когда в описаниях сценариев имеются:
Роли в сценариях взаимодействия
Говоря об описании взаимодействий в системе, можно предложить следующее определение роли: роль - это абстракция агента или компонента системы в рамках его ответственностей в некотором взаимодействии. По сути, в результате такого абстрагирования, мы получаем некоторый срез поведения объекта. Ответственности участников взаимодействия определяются логикой описываемого сценария.В модели взаимодействий UML при описании некоторого сценария каждой роли естественно сопоставлять оси с одинаковым именем на различных диаграммах. В контексте некоторого упрощения метамодели взаимодействий UML (Рис. 5) взаимосвязь ролей с моделью взаимодействий можно проиллюстрировать диаграммой, представленной на Рис. 6.
Рис. 5. Фрагмент упрощенной модели взаимодействий UML
Рис. 6. Роли в метамодели взаимодействий
Список литературы
| 1. | UML 2.0 Superstructure Specification FTF. October 8, 2004, OMG Document: ptc/04-10-02 (convenience document). |
| 2. | B. Bollig, M. Leucker, T. Noll. Generalised Regular MSC Languages. Proceedings of the 5th International Conference on Foundations of Software Science and Computation Structures (FOSSACS '02), Grenoble, France, 2002. |
| 3. | B. Jonsson, G. Padilla. An Execution Semantics for MSC-2000. SDL 2001: Meeting UML, 10th International SDL Forum Copenhagen, Denmark, 2001. |
| 4. | ITU Recommendation Z.120 Message Sequence Charts (MSC-2000). International Telecommunication Union (ITU), Geneva, 1999. |
| 5. | F. Steimann. On the Representation of Roles in Object-Oriented and Conceptual Modelling. Data & Knowledge, Volume 35, Issue 1, October 2000. |
| 6. | R. K. Wong, H. L. Chau, F. H. Lochovsky. A Data Model and Semantics of Objects with Dynamic Roles. Proceedings of the Thirteenth International Conference on Data Engineering table of contents, 1997 |
| 7. | F. Steimann. Role = Interface: a merger of concepts. Journal of Object-Oriented Programming 14:4, 2001 |
| 8. | M. Fowler. Dealing with Roles. Working Draft (http://martinfowler.com/apsupp/roles.pdf), July 1997. |
| 9. | E. A. Kendall. Aspect-Oriented Programming for Role Models. Lecture Notes Computer Science, Vol. 1743, 1999. |
| 10. | G. Georg, R. B. France. UML Aspect Specification Using Role Models. OOIS 2002: Object-Oriented Information Systems, 8th International Conference, Montpellier, France, 2002. |
| 11. | M. Becht, T. Gurzki, J. Klarmann, M. Muscholl. ROPE: Role Oriented Programming Environment for Multiagent Systems. Proceedings of the 4th IFCIS Conference on Cooperative Information Systems (CoopIS'99), Edinburgh, Scotland, September 1999. |
| 12. | ITU-T Recommendation Z.100 System Description and Definition Language (SDL-2000). International Telecommunication Union (ITU), Geneva, 1999. |
| 13. | N. Mansurov, D. Vasura. Approximation of (H)MSC semantics by Event Automata. SAM'2000 workshop, Grenoble, France, 2000. |
| 14. | St. Heymer. A Semantics for MSC Based on Petri-Net Components. SAM 2000, 2nd Workshop on SDL and MSC, Col de Porte, Grenoble, France, 2000. |
| 15. | Z. Hu, S. M. Shatz. Mapping UML Diagrams to a Petri Net Notation for System Simulation. Proceedings of the 16th International Conference on Software Engineering & Knowledge Engineering (SEKE'2004), Banff, Alberta, Canada, 2004. |
Структуризация поведения по ролям
Построение структурированной модели машин состояний делает их более масштабируемыми, что расширяет возможности дальнейшего применения получаемых моделей. Наличие взаимосвязи между структурой этой модели и структурой исходной модели взаимодействий дает возможность более тесно сочетать использование обеих этих моделей при описании поведения системы, что позволяет рассматривать поведение системы с разных точек зрения.Далее мы рассматриваем вариант расширения алгоритма синтеза, заключающийся в структуризации поведения по ролям, т.е. генерации иерархической структуры, состоящей из машин состояний, в которых происходит вызов других машин состояний (т.е. подмашин) в соответствии с использованием ролей. Для этого вместо подстановки поведения, соответствующего роли, для каждой роли генерируется конструкция вызова подмашины, которая состоит из:
Для рассматриваемого примера обмена данными такие подмашины весьма тривиальны (Рис. 16).
Рис. 16. Подмашины состояний, соответствующие поведению объектов в различных ролях
Другими словами, каждая подмашина состоит просто из отрезка перехода между состояниями по событию принятия или посылки соответствующего сигнала. В данном случае производить такую инкапсуляцию не слишком целесообразно. Тем не менее, если протокол пересылки носит более сложную форму, то такая группировка может быть гораздо более значимой.
Конкретное представление такой иерархии можно рассмотреть в контексте задачи генерации прототипа архитектурной модели системы. Существуют различные способы структурной реализации ролей. Тривиальный способ заключается в простой комбинации всех поведений; простая подстановка именно этому способу и соответствует.
В качестве менее тривиального способа структурной реализации ролей можно рассмотреть шаблон, соответствующий использованию ролевого объекта в работе [] (Рис. 17).
Рис. 17. Шаблон "ролевой объект" для представления ролей в структуре системы
Если в системе существует поведение, связанное с некоторой ролью, то для такой роли заводится интерфейс Role и реализация этого поведения - Role_Impl. Если объекты типа Class могут выполнять эту роль, то такой класс должен быть унаследован от интерфейса Role, и он должен агрегировать объект типа Role_Impl, который по своей сути соответствует экземпляру роли. Поведение же, соответствующее данной роли, должно делегироваться в Class из Role_Impl.
Для примера с передачей данных, если считать типы объектов A и B разными, структура системы будет описываться диаграммой на Рис. 18.
Рис. 18. Машины состояний для объектов модельной системы обмена данными, структурированные по ролям
Этот пример показывает, что по описанию взаимодействий может быть автоматически построен и прототип архитектурной модели системы, структура которого соответствует логике исходных сценариев.
Свойства ролей
В литературе понятие роли используется преимущественно в контексте моделей данных и в архитектурных моделях. В таких работах исследуются средства структурной композиции свойств объекта из свойств его ролей; нас же будет интересовать, прежде всего, объединение функциональности, соответствующей поведению в различных ролях. Тем не менее, сами свойства ролей, как в структурном, так и в поведенческом аспектах сходны. Основываясь на обзоре, произведенном в [], отметим следующие свойства ролей:Эти свойства ролей прослеживаются и в сценариях.
Подчеркнем различие между классами и ролями:
Удобно различать понятие роли и экземпляра роли - по аналогии с различением понятий класса и экземпляра класса. Под существованием во время выполнения (run-time) экземпляра роли мы будем понимать факт выполнения экземпляром агента или компонента системы данной роли в процессе некоторого взаимодействия.
В процессе функционирования системы каждый из ее объектов выполняет (или играет) некоторую роль (возможно, несколько ролей одновременно); таким образом, можно говорить о существовании экземпляров ролей (одного или нескольких, если объект выполняет сразу несколько ролей одновременно), соответствующих объекту в каждый момент времени. В случае отсутствия явного выделения роли объекта можно говорить о выполнении им некоторой анонимной роли.
Метамодель, иллюстрирующая эти соотношения, может быть описана диаграммой, представленной на Рис. 4.
Рис. 4. Метамодель, описывающая соотношения между ролями, классами и их экземплярами
Абстракция роли достаточно исследована с точки зрения ее структурной реализации, например, модели данных, использующие роли [], связь понятия роли и интерфейса [], шаблоны реализации ролей []; однако с точки зрения объединения поведения в различных сценариях роли практически не исследуются.
Произведем краткий обзор шаблонов для представления ролей, рассматриваемых в работе []:
Структурировать описание поведения можно различным образом; при рассмотрении поведений, соответствующих различным ролям в рамках некоторой архитектурной ролевой модели, можно достичь соответствия между ролями в их структурном и поведенческом понимании.
Уточнение семантики композиции
Каждая диаграмма последовательностей естественным образом предполагает наличие постоянного контекста описываемого взаимодействия, т.е. в ней описывается своего рода транзакция взаимодействия объектов. Набор осей задает классы объектов и их возможные роли, которые они могут выполнять.В дальнейшем под обзорными диаграммами взаимодействия, мы понимаем соответствующие диаграммы UML (UML Interactions Overview Diagrams), им родственна нотация высокоуровневых диаграмм MSC (High-level MSC, HMSC).
Обзорные диаграммы взаимодействия декларируются в спецификации UML как вариант диаграмм активностей, однако же, это отражено лишь в нотации.
Спецификация UML определяет семантику этих диаграмм декларативно; для целей сравнения поведений имеет смысл определить их исполняемую семантику - как вариант семантики диаграмм активности. Семантика же диаграмм активностей определяется в UML в стиле семантики сетей Петри, т.е. через поток маркеров (tokens) по графу, состоящему из мест, переходов и дуг, их соединяющих. В рассматриваемом случае этим местам соответствуют активности, каждая из которых описывается диаграммой взаимодействия, а переходам соответствуют условные и параллельные ветвления потока маркеров.
Для определения поведения сопоставим каждому объекту набор маркеров. Каждому маркеру ставится в соответствие экземпляр некоторой роли, выполняемой объектом; понятия маркера и экземпляра роли, таким образом, можно в определенном смысле отождествлять. Нахождение маркера для экземпляра роли в некоторой активности, означает, что объект, которому соответствует этот экземпляр роли, участвует во взаимодействии, описываемом сопоставленной этой активности диаграммой взаимодействия. Состояние объекта определяется набором ролей, которые он исполняет, т.е. соответствующим множеством экземпляров ролей и их состояниями. Состояние всей системы определяется текущей разметкой диаграмм маркерами.
Возможность активации перехода для маркера означает, что для объекта, соответствующего этому маркеру одновременно:
Предусловие зависит от вида такого события следующим образом:
При активации перехода происходит перемещение маркера: маркер, соответствующий данному объекту, убирается из активности, в которой он находился, а в активность, в которую ведет сработавший переход, помещается маркер, соответствующий той роли, которую объект будет в ней выполнять. В случае перехода с распараллеливанием маркеры помещаются во все активности, в которые ведут ветви перехода. Для перехода, объединяющего параллельные ветви, условиями его срабатывания являются наличия маркеров, соответствующих одному и тому же объекту.
Отметим, что такое описание композиции поведения объектов сходно с использованием сетей Петри для описания композиции ролей, предложенном в [], где рассматривалась программная среда для разработки приложений, основанных на агентной архитектуре.
Рассмотрим теперь следующие методы описания композиции поведения в различных ролях
предложенный консорциумом OMG, направлен на
Модельно-ориентированный подход (Model Driven Architecture, MDA), предложенный консорциумом OMG, направлен на достижение интероперабельности разрабатываемых систем. В нем используется идея разделения бизнес-логики проектируемой системы и конкретной технологии ее реализации. Для описания бизнес-логики используются платформо-независимые модели проектируемой системы. В рамках этого подхода основополагающую роль играет построение моделей системы, проверка их корректности и отображение в модели других уровней. Для унификации моделирования различных аспектов системы в рамках подхода MDA предлагается использовать универсальную нотацию - язык UML [].На ранних фазах проектирования программных системы, особенно на фазе анализа требований, с успехом используется сценарный подход, заключающийся в определении вариантов использования (use cases) системы и описания сценариев ее поведения в каждом таком варианте. Каждый сценарий представляет собой описание последовательности взаимодействий, направленной на достижение некоторой цели. Сценарии могут быть заданы с помощью какой-либо нотации, позволяющей описывать поведение, однако, как правило, для описания сценариев используются нотации, обладающие высокой степенью наглядности.
Построение формализованной сценарной модели позволяет производить как статический анализ требований, так и генерировать исполняемый прототип системы для динамического исследования системы; тем самым достигается возможность проверки требований.
Для построения поведенческих моделей в языке UML 2.0 существуют следующие средства:
По сути, взаимодействия UML обеспечивают абстракцию трасс системы, активности - абстракцию потоков (управления и данных) в системе, а машины состояний - абстракцию последовательности состояний для каждого компонента системы.
Взаимосвязь с аспектами
Использование ролей близко соотносится с аспектно-ориентированным программированием. Под аспектом понимается некоторый срез системы, который объединяет функциональность ее различных частей, соответствующую некоторому классу задач. Таким образом, отчетливо видна связь между описанием сценариев системы и ее аспектами поведения, так как по существу каждый сценарий является описанием какого-либо аспекта системы; при этом каждому аспекту соответствует некоторый набор ролей - эта связь отражена на диаграмме, представленной на Рис. 7.
Рис. 7. Взаимосвязь ролей и аспектов с взаимодействиями UML
Исследования взаимосвязей в использовании ролей и аспектов можно найти, например, в [] и [].
В статье было продемонстрировано, что,
В статье было продемонстрировано, что, в отличие от традиционной интерпретации, каждое описание взаимодействий может трактоваться как ориентированное не на собственно объекты, а на роли, выполняемые ими в данном взаимодействии. Для более широкой применимости моделей взаимодействий и более формального их использования можно использовать рассмотренный аппарат для оперирования этими ролями.В данной работе показано, как можно адаптировать имеющуюся нотацию UML для описания ролей, прежде всего, в плане задания их композиции. Для этого было рассмотрено использование конструкций продолжения и расширение возможностей параметризации UML-взаимодействий, однако у каждого из этих способов имеются свои недостатки. Следует отметить, что композиция через конструкции продолжения ближе к машинам состояний, так как семантика этих конструкций близка семантике к переходам на метку; композиция же через параметризацию - ближе по смыслу к семантике UML-активностей, так как она тем или иным образом задает потоки объектов.
В качестве модели для абстрактного выполнения были рассмотрены машины состояний UML, которые удобны для целей симуляции и генерации прототипа компонентов системы. Было рассмотрено расширение алгоритма синтеза машин состояний по UML-взаимодействиям на случай использования композиции различных ролей, и указаны те из этих расширений, которые поддерживаются разрабатываемым инструментом Bridge, позволяющим автоматически производить подобный синтез. Кроме этого, была обозначена возможность отображения модели UML-взаимодействий в модель активностей, которая удобна для анализа поведения системы в целом. Анализ моделей, поведение которых дает аппроксимацию поведения, задаваемого описаниями требований к системе в виде моделей взаимодействий, обеспечивает возможность выявлять пробелы в понимании требований к системе.
Другим результатом экспериментов с новой нотацией является вывод о том, что при композиции различных ролей, как и вообще при композиции сценариев, могут возникать неопределенности.
В статье был приведен типичный пример возникновения неопределенности с выбором роли, в результате которого у системы может существовать поведение, приводящее к тупиковой ситуации.
Еще одним следствием использования ролей при использовании для описания сценариев модели взаимодействий является достижение взаимосвязи с аспектно-ориентированным программированием.
В качестве развития данной тематики имеет смысл рассмотреть следующие задачи:
Управление проектами - статьи
"Естественный отбор" руководителя проекта
Гаврилов Н. Н., к.т.н., доц. РЭА им. Г.В. ПлехановаКозлов А. С., к.э.н., доц. ГУУ
Матвеев А. А., аспирант ИПУ РАН, сотрудник ПМСОФТ
Рост крупного бизнеса – результат естественного отбора.
Джон Рокфеллер
Качества, необходимые руководителю проектом
Можно с уверенностью сказать, что руководитель проекта должен, прежде всего, обладать основными качествами руководителя. Рассмотрению основных качеств и требований к руководителю посвящено множество работ. Для нас же гораздо больший интерес представляет выявление специфических качеств, которые необходимы управляющему проектом в связи со спецификой проектной деятельности. В качестве «специфики» проектной деятельности будем, в соответствии с PMBOK [3], рассматривать свойства временности и уникальности проектов.С учетом временного характера выполнения проекта руководитель проекта должен быть чрезвычайно мобильным. При этом он,
Уникальность проекта диктует необходимость владения междисциплинарными знаниями и навыками, в отличие от руководителей функциональных организаций, который может являться профессионалом только в одной области.
Для иллюстрации такой ситуации введем качественные показатели «требования проекта» и «квалификация руководителя проекта». Под понятием «требования проекта» будем понимать совокупный уровень знаний и навыков, необходимых для успешной реализации проекта. Под понятием «квалификация руководителя проекта» будем понимать совокупный уровень знаний и навыков, которыми обладает руководитель проекта на определенный момент времени. Требования проекта и квалификация руководителя проекта – это динамичные характеристики.
Графическая иллюстрация понятий «требования проекта» и «квалификация руководителя проекта» приведена на рисунке 1.
Рисунок 1. Качественные соотношения динамики требований проекта и квалификации руководителя проекта
Введем предположение, что по мере выполнения проекта его требования сначала возрастают за счет постоянного уточнения и детализации требований к продукту, услуге, цели проекта.
Для того чтобы быть руководителем проекта, необходимо иметь соответствующую квалификацию и постоянно ее повышать. С другой стороны, для управления конкретным проектом необходим профессионал соответствующей квалификации.
Так как для выполнения конкретных проектов требуются вполне определенные предметные и междисциплинарные знания и навыки. И, естественным образом, возникает вопрос: «Сколь глубокими и широкими должны быть знания и умения руководителя проекта?». Очевидно, что для сложных проектов требования достаточно высоки и разнообразны. Один человек вряд ли может быть профессионалам во всех областях. Решением этой проблемы является формирование команды проекта, состоящей из профессионалов в различных предметных областях, на которые распространяются требования проекта. При этом руководитель проекта должен реализовывать интегрирующие и синергетические функции. Сама же команда проекта, помимо реализации задач управления проектом, должна выполнять функции «инкубатора» будущих руководителей проектом и включаться в систему «естественного отбора».
Таким образом, необходимо учитывать еще одну специфическую особенность проектной деятельности – командную работу. Проект реализуется «временной» командой исполнителей, собираемых только для реализации целей каждого конкретного проекта и руководитель проекта должен эффективно выполнять функцию управления таким «временным» образованием – это еще одно существенное отличие руководителя проекта от функционального руководителя.
Совокупность свойств временности и уникальности проектной деятельности, а также необходимость командной работы, с одной стороны обуславливают требования к организации работы временных коллективов, а с другой – к необходимости объективного и непрерывного оценивания деятельности специалистов различного профиля.
С точки зрения командной работы в проекте, команду управления проектом можно сравнить с симфоническим оркестром, а руководителя проекта – с дирижером. В оркестре выделяются первая скрипка, другие солисты.
При этом, не обязательно, чтобы все музыканты были виртуозами, а дирижер может и не уметь сам виртуозно играть на всех музыкальных инструментах. Но все музыканты должны играть по одной партитуре, вступать в требуемые моменты времени, а дирижер должен слышать и координировать всех музыкантов во время исполнения музыкального произведения. В то же время, в характере и стиле исполнения музыкального произведения симфоническим оркестром отражаются особенности личности дирижера, понимание им музыкального произведения, возможности исполнителей.
С учетом всех особенностей проектной деятельности, руководитель проекта должен уметь:
Основные вопросы отбора и формирования руководителей проектов
Основываясь на практическом опыте можно сказать, что далеко не все люди (зачастую даже те, которые занимают должность руководителя проекта) могут в полном объеме и эффективно выполнять действия, необходимые для успешной реализации проекта. Конечно же можно с уверенностью сказать, что руководителем проекта может быть каждый сотрудник, который:Список этих качеств можно продолжать и дальше, но возникает вопросы: является ли наличие перечисленных качеств достаточным для руководителя проекта, какие качества являются принципиальными, можно ли овладеть этими качествами, и если можно – то как. Можно поставить два ключевых вопроса:
В докладе мы попытаемся дать ответы на эти вопросы.
Подготовка и отбор руководителей проектов.
После рассмотрения специфических особенностей, характерных для управления проектами, давайте рассмотрим систему подготовки и отбора руководителей проектов. По нашему мнению, можно выделить следующие основные формы подготовки специалистов по управлению проектами:Приведенные уровни подготовки, как правило, последовательно следуют друг за другом (сначала обучение в вузе, затем повышение квалификации, получение дополнительного образования и обучение в процессе работы), но могут налагаться и пересекаться. Схематически этот процесс представлен на рисунке 2.
Рисунок 2. Структура системы подготовки и отбора руководителей проектов
Абитуриенты отбираются вузом по ряду критериев. Поступив в высшее учебное заведение, он может еще и не вполне осознавать своего будущего. Отобранные вузом студенты овладевают базовыми знаниями и приобретают основные навыки, получают опыт решения учебных задач. Все это позволят им более или менее успешно начать самостоятельную трудовую деятельность и определяться в своей специализации. Далее, если специалист отбирается для участия в управлении проектом, то для обеспечения его успешной работы может потребоваться овладение новыми знаниями и навыками.
Продолжая работать в команде управления проектом, специалист получает практический опыт. Работая в уникальных по своей сути проектах, специалист должен постоянно совершенствоваться и стремиться к получению новых знаний и навыков. Соответствующее обучение специалистов команды проекта может организовываться, либо в форме получения второго высшего образования, либо в форме повышения квалификации. В ряде случаев специалисту может потребоваться пройти специализированные курсы для овладения специальными навыками и изучения опыта в специализированных областях. И, наконец, для достижения высших ступеней мастерства руководителю проектов требуется обмен опытом на специализированных семинарах или при более неформальном общении с коллегами в профессиональных клубах управляющих проектами.
Официальное обучение рассматривается как базисная предпосылка успешной профессиональной деятельности, полуофициальная форма оказывается полезной в ее начале, а неофициальная учеба специалиста по управлению проектами продолжается в течение всей его работы.
Процесс подготовки руководителей проектов включает как прохождение профессиональной подготовки и обучение, так и получение практических навыков в процессе работы в составе команд проектов. Схематически структура отбора и подготовки руководителей проектов представлена на рисунке 3.
Рисунок 3. Структура системы отбора и формирования управляющих и команды проекта
Итак, процесс «естественного отбора» руководителей проектов можно определить, как самоопределение и прохождение через ступени социального, профессионального и прочих отборов со стороны внешнего окружения и команды проекта, а также постоянное самосовершенствование и повышение квалификации.
Привлечение кадров в сферу управления проектами
Сейчас, все больше и больше компаний начинают вести активную деятельность, направленную на то, чтобы привлечь внимание, как своих действующих сотрудников, так и будущих (студентов), к управлению проектами как к области профессиональной специализации. Ими устраиваются семинары, оказывается содействие при подготовке учебных программ, организуются круглые столы, формируются элементы проектно ориентированных организационных и т.д.Каждый специалист по управлению проектами должен быть заинтересован в притоке новых, хорошо подготовленных и способных кадров. Он может содействовать этому следующим образом:
Содействие специалиста в привлечении кадров оказывается более эффективным, если он сам хорошо осведомлен о последних достижениях в области управления проектами.
Ступени профессионального роста руководителя проектов
Ступени профессионального роста руководителя проектов круты и многочисленны. Подъем по ним может быть долгим и трудным, а порой - и опасным. Не все из начинающих восхождение достигают вершины, но достигшие могут по праву считаться героями, ибо они с честью преодолели все испытания трудного подъема и теперь сверху могут видеть больше и помогать остальным.
Сегодня проектный подход все шире проникает в управленческую практику. Все большее количество организаций начинает рассматривать себя через призму проектно-ориентированной деятельности. Потребность в профессиональных руководителях проектов все более возрастает. Растет и дефицит этих специалистов. Поэтому, наиболее актуальной становится проблема подготовки и отбора руководителей проектов. В связи с этим возникают вопросы о возможности создания системы, которая бы содействовала отбору и формированию профессионалов в области проектного управления.
Если процесс отбора и формирования функциональных руководителей высшего и среднего звена достаточно ясен, то в сфере подготовки руководителей проектов пока остается больше вопросов, чем ответов. Хотя этой проблеме и уделяется достаточно внимания, однако на настоящий момент времени отсутствуют четкие критерии отбора и подготовки руководителей проектов. Отчасти это объясняется и тем, что управление проектами, сочетающее массу междисциплинарных знаний и навыков, в России является относительно молодым направлением, применяемым чуть более 10 лет.
Любую деятельность человека, равно как
Любую деятельность человека, равно как и всю его жизнь можно рассматривать, как проект. Следовательно, принципы, законы и механизмы естественного отбора, действующие в жизни, могут быть перенесены на вопросы отбора руководителей проектом. Причем этот отбор должен происходить, как с учетом специфических требований проектной деятельности, так и с учетом требований успешности работы в команде.Успешные руководители организаций, а также руководители проектов и члены команд проектов должны быть заинтересованы в создании эффективной и гармоничной системы «естественного отбора» профессионалов в области проектной деятельности, ибо это среда их «обитания».
В систему «естественного отбора» должны органично войти учебные заведения, а также государственные структуры контроля, лицензирования и социального обеспечения.
Управление проектами - статьи
Daily Scrum Meeting
Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга - поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга.Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды
Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например
Демо и ревью спринта
Рекомендованная длительность: 4 часаКоманда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению.
Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет.
Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. Подготовка к митингу не должна занимать у команды более 2-х часов.
Команда (Team)
В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.Обязанности команды таковы:
Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2.
Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками - разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи.
Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы.
Обзор методологии SCRUM
,Certified Scrum Master
Process Architect и Agile Coach
Компания
Источник:
Независимое некоммерческое сообщество, объединяющее ИТ-профессионалов, занимающихся или интересующихся гибкими методологиями разработки ПО
Остановка спринта (Sprint Abnormal Termination)
Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла.После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы.
Планирование спринта, митинг первый
Участники: команда, Product Owner, Scrum Master, пользователи, менеджементЦель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.
Артефакт: Sprint Backlog
Планирование спринта, митинг второй
Участники: Скрам Мастер, командаЦель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.
Артефакт: в Sprint Backlog появляются задачи
Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.
Планирование спринта
В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.Планирование спринта состоит из двух последовательных митингов.
Product Backlog
Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем памяти"
Рис. 2.
Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.
Product Owner
Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.Обязанности Product Owner таковы:
Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.
Роли
В методологии Scrum всего три роли.Скрам Мастер (Scrum Master)
Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.Основные обязанности Скрам Мастера таковы:
Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.
ScrumMaster может также помогать Product Owner создавать Backlog для команды
Sprint Backlog
Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.
Рис. 3. Пример Spint Backlog
Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.
Рис. 4.
Спринт (Sprint)
В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).
Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.
Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.
Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.
одна из самых популярных методологий
Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота. Scrum по-настоящему прост, его можно описать в одной короткой статье, что я и постараюсь сделать в этом обзоре.Управление проектами - статьи
Еще раз о пользе отчетов
При любой технологии производства, отчеты - один из самых полезных видов документации. Сделайте отчеты стандартом в вашей организации, вне зависимости от ее размера и рода деятельности. При этом постарайтесь использовать наиболее простую и удобную для ваших сотрудников форму, для того, чтобы не усложнять им жизнь.я привожу список возможных документов,
Подводя итоги, я привожу список возможных документов, разрабатываемых в рамках вышеописанного технологического процессаОбщая управляющая документация:
Управляющая проектная документация:
Другая управляющая документация:
Общие рекомендации по организации процесса разработки
Прежде, чем озаботиться созданием основ технологии, необходимо по максимуму решить все организационные проблемы. В литературе часто рассматривается вопрос организации рабочей среды в компании-разработчике ПО, однако, для компании, в которой отдел разработки совсем небольшой (1-3 человека), многие из этих рекомендаций покажутся излишними. Тем не менее, таким компаниям рекомендации нужны не меньше. Из своего опыта я могу рекомендовать следующее:При современном подходе к разработке ПО весьма высоко ценится легкость коммуникации. Несомненно, прекрасно, когда разработчик может, сделав два шага, уточнить у непосредственного заказчика способ решения проблемы, входные данные или что-либо еще, но, посадив менеджера по продажам и разработчика за соседние столы, вы самое малое в четверть снизите продуктивность труда последнего.
Проект с большой долей вероятности выйдет из-под контроля, если разработчики будут выполнять такие, пусть даже срочные, распоряжения. Требования не будут фиксироваться, тесты не будут производиться, модификации будут осуществляться на ходу, разработчики будут вынуждены под давлением давать слишком оптимистичные оценки трудозатрат и всегда чувствовать себя неуспевающими, так как никто не будет знать, сколько работы они выполнили.
Практика показывает, что задачи по сопровождению-разработке ПО возникают постоянно в течение дня, обстоятельства почти всегда требуют немедленного выяснения. Если вы имеете двух разработчиков, пусть они по очереди общаются с представителями заказчика, если у вас есть специально выделенный для этого менеджер - пусть общается он. Проблема здесь в том, что административные функции (выяснение обстоятельств проблем, степени их важности, взаимодействие с заинтересованными лицами) требуют оперативности, в то время как техническая реализация запросов, наоборот, наиболее эффективна при возможности сосредоточиться на проблеме на длительное время.
Постоянное отвлечение внимания разработчика, кроме снижения эффективности работы, имеет еще один отрицательный результат: трудность адекватной оценки фактических трудозатрат. Между тем, без фиксирования фактических затрат, разработчик теряет навык делать правильные оценки.
Не привлекайте разработчиков к секретарской работе. Разработчики часто ответственные и пунктуальные люди - у менеджеров, при всем к ним уважении, часто нет времени. Не чувствуя характер работы разработчика они могут, безо всякой задней мысли, скинуть половину звонков на них.
Если вы, конечно, не боитесь потерять разработчика. Помните, разработчик чрезвычайно ценит свою квалификацию. Хороший разработчик всегда сможет найти себе новую работу, а вы вряд ли легко найдете нового разработчика. Это в крупных организациях с развитым процессом разработки разработчика можно заменить без значительных затрат - а в такой небольшой компании, которая описывается здесь, разработчик может быть единственным носителем знаний о функционирующих программных продуктах, или вообще их единственным автором.
В изменяющемся мире бизнеса, например, в телекоммуникационном бизнесе, число задач, связанных с поддержкой существующих систем остается примерно постоянным. Небольшие изменения в существующем ПО требуются регулярно. В процессе разработки нового ПО число систем, которые необходимо сопровождать, растет. Что получается? Суммарное число задач растет со временем. Если разработчик говорит, что он перестает справляться с объемом задач, скорее всего это так. Возьмите еще одного человека, либо закажите разработку и сопровождение части ПО другим организациям.
Как руководитель, вы не можете быть в курсе всех последних изменений в мире разработки ПО. Вы можете считать, что человеку, который умеет программировать учиться больше не надо, вполне достаточно опыта, получаемого в процессе работы.Однако если разработчики не будут в курсе последних технологий, ваше ПО устареет очень быстро и станет сдерживающим фактором на пути к новым завоеваниям рынка.
Какой бы небольшой ни была ваша компания, такой документ просто необходим. Как минимум, он необходим разработчику, для того, чтобы знать, с кем контактировать по какому вопросу
Я не могу утверждать, что данный список является полным, и вполне вероятно, что можно дать еще некоторые рекомендации, такие, как, например, обеспечить разработчиков всем необходимым аппаратным и программным обеспечением. Дело в том, что я даю рекомендации относительно лишь тех пунктов, которые вызывали наибольшие проблемы в период моей работы в компании описываемого уровня.
Описание специфики разработки
Как следствие, процесс разработки ПО в таких компаниях в силу объективных причин достаточно примитивен. Многие технологические процессы отсутствуют или присутствуют в сильно упрощенном варианте. Тем не менее, и такими процессами необходимо управлять и гарантировать приемлемое качество их выполнения.
Планирование реализации требований
Планировать реализацию требований можно в какой угодно форме, однако, мне кажется, что если требований достаточно для того, чтобы спланировать хотя бы одну итерацию, лучше планировать итерацию. Суть итерации заключается в том, что она вмещает в себя полный цикл всех мероприятий по реализации требований: от проектирования архитектуры до поставки новой версии разрабатываемого ПО. При таком подходе в конце каждой итерации мы получаем работоспособный продукт, хоть и с частично реализованной функциональностью. Это позволяет уже через очень короткое время получить первый отзыв заказчика о продукте, подтвердить правильность выбранной реализации, контролировать сроки разработки и, возможно, даже предоставить заказчику для использования наиболее важную функциональность. Для более подробного изучения итеративного процесса разработки я предлагаю обратиться к соответствующей литературе, здесь я постараюсь перечислить некоторые конкретные рекомендации по планированию итераций.Я всегда планировал двухнедельные итерации и, по моему мнению, это достаточно подходящий размер, потому что за две недели можно сделать не так уж мало, и, в то же время, можно достаточно часто получать результаты и своевременно корректировать ход разработки.
Только не пытайтесь спланировать все рабочее время на проектную деятельность. По моим наблюдениям, даже в компании-разработчике ПО у программистов средняя проектная занятость достигает максимум 6 часов в день. Остальное время уходит на организацию работы, деловую переписку, сборку версий, поиск информации в Интернете, установку обновлений, новых версий программ и просто общение. В случае совмещения нескольких обязанностей, я бы не рискнул планировать более половины времени на разработку. Таким образом, приблизительная оценка может быть такой:
| 4 часа в день * 2 недели * 5 дней * 2 разработчика = 80 человеко-часов на итерацию |
Поспешу заверить, что это не так уж мало, как может показаться
Такие оценки следует доверить разработчику - он лучше всех представляет, сколько времени может потребоваться на реализацию каждого требования. Не спланировав время на выполнение требований, невозможно спланировать итерацию
Это необходимо для того, чтобы анализировать, насколько точны оценки, даваемые разработчиком, для того, чтобы оценивать, сколько может потребоваться времени на реализацию похожей функциональности, а главное, это показатель, который фиксирует актуальный объем занятости группы разработки на итерацию на вашем предприятии. Это основная цифра, из которой надо исходить, планируя следующую итерацию
Будет полезно составить технологическую инструкцию, описывающую технологию разработки ПО на стадии планирования конкретно на вашем предприятии.
Основными пунктами такой инструкции могут быть:
Как и до этого, я рекомендую на начальном этапе включать в такую инструкцию только основные, совершенно необходимые шаги. Ключевым критерием должна быть уверенность, что вы сможете добиться исполнения перечисленных шагов.
Результатом процесса должны стать утвержденные требования к системе, с указанием планируемых трудозатрат, с расставленными приоритетами и распределенные по итерациям.
Важно как можно раньше выяснить, кем представлен каждый из классов пользователей при сборе требований, кто назначает приоритеты требованиям и т.д.
Очень важно выяснить, кто должен быть оповещен при выпуске версий!
Если версии не доходят до заинтересованных лиц, нет смысла в их частом выпуске
Как показывает практика, бывает так, что люди, заинтересованные в продукте узнают о его разработке только после окончания последней. В этот момент выясняется, что их требования не учтены. Будьте уверены, вам придется реализовать и эти требования, но на поздних этапах работы над проектом, что станет причиной существенных сложностей.
Убедите всех участников обсуждения в том, что их пожелания важны и будут рассмотрены. Только спустя некоторое время работы над проектом, я стал понимать, что некоторые из участников обсуждений не представляли, насколько значимы их предложения для остальных. Как следствие, многие пожелания не высказывались по причине того, что людям казалось, что их пожелания не будут рассмотрены
По опыту общения с людьми, заинтересованными в проекте, я могу сказать, что у каждого из них, скорее всего, будет свое видение важности реализации каждого из требований. Часто эти люди не могут договориться между собой. Не берите на себя ответственность за то, чтобы решать, чье мнение важнее: это не ваша забота. Пусть руководитель определит, что наиболее приоритетно в его бизнесе
В вышеуказанной инструкции опишите, что должно выполняться в следующих случаях:
Так как заказчик, скорее всего внутренний, вы должны быть готовы в любом из этих случаев идти ему на встречу. Предусмотрите то, как вы будете перераспределять задачи и относитесь к этому с легкостью. Единственное, что не рекомендую делать - это сдвигать сроки завершения итераций - иначе они поплывут, и планирование в какой-то момент прекратится.
Даже если вы спланировали завершить итерацию через две недели, поставьте промежуточную версию уже через неделю.Предупредите, что версия может содержать ошибки и не должна использоваться в реальных задачах. Не настаивайте на том, чтобы заказчик смотрел эту версию в работе. Однако, если заказчик заинтересован в продукте и у него найдется время, он сможет вам что-то подсказать или найти ошибку до того, как вы найдете ее сами (если найдете). Таким образом, вы сможете ненавязчиво привлечь заказчика к тестированию
Приучите заказчика и себя к тому, что он (заказчик) может в любой момент ознакомиться с ходом работы и еще раз оценить зафиксированные результаты планирования
Направления улучшения данного процесса:
Разработка требований
По данному вопросу существуют хорошая и гораздо более подробная и глубокая, чем данная статья, литература. Здесь я опишу тот минимум работы, который, по моему мнению, нужно выполнить для того, чтобы в организации появился повторяемый процесс управления требованиями.В качестве таких источников могут выступать:
При этом не следует ограничивать всех вышеперечисленных действующих лиц какими-либо форматами или средствами. Будьте готовы, что при необходимости требования будут озвучены устно или по телефону, будут отправляться письмом или по ICQ, при чем в том виде, в котором удобно тому, кто данное требование высказывает. В разработке требований будут участвовать самые нетехнические специалисты или даже не специалисты. Главное здесь добиться следующего:
Может случиться так, что по разным причинам, вы окажетесь не вовлеченными в процесс обсуждения разрабатываемой системы, и не будете иметь информации о проводимых совещаниях и их результатах. Вместо этого вы будете иметь дело с уже написанными документами. Такое вполне может произойти, если ваша основная позиция - разработчик и считается, что ваша задача - исполнять требования, а не тратить время на их обсуждение. Такое может случиться, если компания имеет несколько территориально удаленных филиалов. В любом случае, постарайтесь убедить руководство в том, что вам, как лицу, осуществляющему планирование и управление процессом разработки, необходимо участвовать в таких обсуждениях
Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:
Это касается как высокоуровневых требований, так и конкретных технических деталей. Если требование или пожелание к системе принято в процессе дискуссии, фиксируйте, кто принимал участие в дискуссии. Это позволит при необходимости выяснить детали, причины требований непосредственно с тем, кто данное требование высказал. Кроме того, вы сможете проанализировать, чьи требования учтены, а чьи - нет.
Определите тех лиц, кто должен утверждать требования. Не приступайте к разработке до того момента, пока требования не утверждены. Сделайте это правилом и не отступайте от этого никогда, иначе вы будете постоянно переделывать одну и ту же функциональность и убирать следы сделанных изменений
В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| # | User Story | Comments | Priority (1,2...) | Realize in iteration # | Realize in version # | Man-hours estimated | Man-hours used |
Направления улучшения данного процесса:
Своими силами: управление процессом разработки ПО небольшой командой специалистов
,В любой организации существует необходимость в том, чтобы автоматизировать некоторые, свойственные только ей процессы. В случае, когда потребность в создании специального ПО существенно влияет на бизнес, такое ПО может быть заказано для разработки в сторонних компаниях. Однако зачастую организация вполне способна справится с автоматизацией своими собственными силами - с помощью небольшой группы разработки (от одного до трех человек). Риск заключается в том, что управление процессом разработки в этом случае может лечь на плечи людей, основная специальность которых не связана напрямую с такой деятельностью - программистов, инженеров других специальностей или менеджеров, не знакомых со спецификой разработки ПО. Это может быть первый опыт такого рода для данной организации. При этом не менее важно обеспечить приемлемый уровень качества процессов, связанных с разработкой.
Эта статья написана на основе опыта, полученного мной за год работы менеджером проекта и разработчиком ПО в небольшой телекоммуникационной компании. В ней рассматриваются основные процессы, связанные с разработкой ПО, которые я смог выделить и формализовать. Я стараюсь дать основные рекомендации, которые могут быть полезны при управлении разработкой ПО в такого рода компаниях.
Чтобы стало более понятно, о чем идет речь, для начала я постараюсь дать общую картину производства в области разработки и сопровождения ПО в компаниях, профиль которых не связан напрямую с разработкой ПО.
Управление запросами на поддержку
Процесс разработки и планирования реализации требований, описанный выше, более подходит при разработке нового ПО или существенных доработках существующего, когда требований достаточно много, они взаимосвязаны и относительно невелики по объему. В случае возникновения запросов на поддержку существующего ПО, часто приходится иметь дело с единичными, не связанными друг с другом и достаточно крупными изменениями. Примером такого запроса может служить, например, запрос на модификацию существующих в системе отчетов или запрос на изменение способа обмена данными со сторонней организацией.В связи с вышеуказанными особенностями, для управления запросами на поддержку в большей степени может подойти несколько отличный от принятого для управления требованиями способ работы и формат документов. Рекомендации тут следующие:
Рекомендуемое содержание данного документа:
Даже если с текущей документацией на проект у вас не все в порядке, фиксация запросов на поддержку в таком виде позволит вам в некоторой степени восполнить этот пробел. Если вам необходимо определить, какая документация должна создаваться в первую очередь - вы можете смело приступить именно к фиксации вышеуказанных пунктов
Хороший вариант - создать документ приблизительно следующего содержания:
| 1 | 2 | 3 | 4 |
| Status | To be executed before | Finish date | |
| On consideration | |||
| Resolved | |||
| On schedule | |||
| Rejected |
Упомянутых статусов ("На рассмотрении", "Выполнено", "На исполнение", "Отменено") может быть вполне достаточно, чтобы контролировать ход работ. Точное время для выполнения запроса назначать не обязательно, достаточно указать дату, когда запрос должен быть выполнен. Полезным наверняка окажется учет фактической даты окончания работ над запросом
Тут, как и при планировании итераций полезной может стать инструкция, описывающая технологию управления запросами на поддержку. Данный документ по структуре будет практически аналогичным инструкции, определяющей технологию разработки ПО на стадии планирования. Что касается содержания, то одно из отличий проявляется в том, что кроме роли разработчика и заказчика, можно выделить отдельную роль руководителя. Если в случае с требованиями, подразумевается, что руководитель уже дал согласие на начало работ по проекту, а требования утверждает заказчик в лице человека, ответственного за такие решения, то в случае с запросами на поддержку, решение о принятии запроса на исполнение может и не быть принято в силу различных причин
Направления улучшения данного процесса:
Выделение основных процессов
Когда организационные проблемы решены на достаточном уровне, можно сконцентрироваться на процессе разработки.Несомненно, вряд ли в этом случае удастся реализовать какой-либо тяжеловесный процесс разработки, и литература по данному вопросу, скорее всего, не сильно поможет, но формализовать существующие процессы и сделать их более эффективными постараться стоит.
Мое мнение состоит в том, что основная рекомендация, которую здесь можно дать, звучит так: "Ничего лишнего". Если вы имеете возможность начать с малого, формализуйте только те процессы, которые можете формализовать и создавайте только те документы, которые будут использоваться.
Наиболее вероятно, что вы сможете выделить следующие процессы:
На каком-то этапе даже этих процессов будет достаточно. Далее в статье я более подробно разберу процессы, связанные с планированием и управлением проектами и процессом разработки в целом, и попытаюсь дать рекомендации по формализации этих процессов.
Структурное руководство проектом. Серебряная пуля?
 Издательство: КУДИЦ-ОБРАЗ |
ООО ИК СИБИНТЕК "Кстати, если вампиры на вас все же нападут, [...] с серебряными пулями лучше не баловаться. Ерунда все это, сам пробовал"Емец Д.А. Таня Гроттер и трон Древнира |
Оказывается, серебряная пуля для ИТ проектов появилась уже 10 лет тому назад! А теперь про нее можно прочитать и по-русски. Вот только так ли она действенна, как принято считать?
Увы, разработка программного обеспечения остается одним из самых рискованных занятий. Процент неуспешных проектов, в том числе не уложившихся в сроки или бюджет, наиболее высок именно в области информационных технологий и именно среди проектов, связанных с разработкой ПО. Можно долго рассуждать, почему проекты проваливаются. А можно подумать о том, почему же часть проектов все-таки выполняется успешно. И по второму пути идут очень и очень многие. Существует масса рекомендаций касательно того, как нужно выполнять проект, чтобы "наверняка" или "почти наверняка" выполнить его в срок, в рамках бюджета и удовлетворить все пожелания Заказчика.
Чтобы тебя заметили в такой ситуации, новая методология должна называться как-то очень необычно. Ну, например, "эКСтремальное Программирование", "Кристально ясная", или хотя бы "Рациональный Унифицированный Процесс". А что делать, если новый метод называется просто "Структурное руководство проектами"? Ничего выдающегося... Приходится придумывать запоминающееся название для книги, описывающей вашу методологию.
Именно так и поступил Фергус О'Коннэл, дав своей книжке с достаточно скучным названием "Как успешно руководить проектами" подзаголовок "Серебряная пуля". Собственно, под этим названием она и известна среди англоязычных специалистов. А теперь ее можно прочитать и по-русски (Фергус О'Коннел. Как успешно руководить проектами. Серебряная пуля. М.: КУДИЦ-ОБРАЗ, 2003. - 288 с.).
Для тех, кто не знает. Серебряная пуля - это не только радикальное средство от вампиров.
Этот термин достаточно давно и активно используется в ИТ как символ технологического прорыва, который позволит разрабатывать ПО намного быстрее и качественнее. Дело в том, что Фред Брукс в 1987 году опубликовал очень широко известную статью под названием "No Silver Bullet" - "Серебряной пули не существует" - в которой доказывал, что нет и не предвидится никакого существенного прогресса в процессе разработки программного обеспечения.
Назвать книгу с описанием своей методологии "Серебряная пуля" - это серьезная претензия. И нельзя сказать, что она необоснованна. Как-никак, на английском первое издание "Серебряной пули" вышло в 1993 году. На русский язык книга переведена с третьего издания, вышедшего в 2001 году. Значит, интерес к ней не пропал. Значит, в ней действительно есть что-то важное и полезное, не потерявшее своего значения за 10 лет достаточно бурного развития ИТ. Но, с другой стороны, ведь и спустя десять лет мы говорим все про те же проблемы...
Сам автор говорит, что он написал книгу не про Методологию, а просто про методологию. В чем разница? Чем структурное управление проектами отличается от многочисленных методологий разработки ПО, хотя бы от упомянутых выше?
Самое главное отличие состоит в том, что это книга написана для руководителей проектов. И ТОЛЬКО для руководителей проектов. В ней нет попыток объять необъятное и дать рекомендации и ценные указания всем участникам разработки. Конечно, никто не запрещает читать ее аналитикам или программистам. Но в узко профессиональном смысле они не найдут там почти ничего, адресованного именно им. Зато если вы руководите проектами или собираетесь этим заниматься, то эта книга для вас. В ней описано, что должен сделать человек, руководящий проектом. В каком порядке. И как проверить, что он сделал все как надо.
Суть структурного руководства проектами заключена в 10 этапах, через которые нужно пройти, выполняя проект:
И если вы сумеете выполнить их, успех вашему проекту гарантирован.
При внешней простоте формулировок и некотором сумбуре (часть перечисленных этапов являются скорее принципами, которых нужно придерживаться, чем стадиями разработки в традиционном понимании) здесь скрыты очень серьезные вещи.
Начнем по порядку с первого этапа. Начиная любой проект, вы должны явно представлять, чего вы хотите добиться. Собираетесь ли вы просто заработать на жизнь себе и семье, выполнив проект с минимально необходимым качеством и, соответственно, с минимально необходимыми усилиями? Хотите ли вы освоить новые технологии? Или вы хотите, чтобы этот проект стал переломным в вашей карьере? Для вашей организации?
А что получат от участия в проекте остальные его участники? А что получит Заказчик? Чему будет радоваться он?
Сформулировав для себя ответы на эти, казалось бы, лирические вопросы, вы сможете соотносить каждый свой шаг с реальными целями. И оценивать его именно с этой точки зрения. Приближает ли он вас к достижению цели или ведет в сторону от нее?
Конечно, думать о чем-то, кроме текущих задач, может только достаточно опытный руководитель. Но если вы не будете пытаться, вы этому никогда и не научитесь. Зато, освоив этот прием, вы сможете значительно успешнее планировать работы, решать проблемы с мотивацией (как это теперь называется) ваших сотрудников, договариваться с Заказчиком и многое другое.
Второй этап, я думаю, уже вызвал возмущение среди многих приверженцев современных методологий, которые выучили, что "водопад - это плохо" (имеется в виду водопадный стиль разработки, когда сначала осуществляется анализ, потом последовательно проектирование всей системы, разработка кода, сборка и комплексная отладка). Но обратите внимание на этап 9! Основной особенностью структурного управления проектами является то, что задачи, которые необходимо выполнить для выполнения проекта, выявляются как можно раньше. Как только вы поняли, что вам придется это делать - запишите! Вот, собственно, и вся суть этапа.
При этом, как и в большинстве современных методологий, разработка ведется итерациями. На ближайшую итерацию (обычно, длительностью от 4 до 6 недель) составляется точный и детальный план. На остальные - более общий и приблизительный. Но если вы знаете, что через три итерации вам придется настраивать СУБД для обеспечения максимальной производительности системы, то и запишите это прямо сейчас! У вас будет лишнее время, чтобы подумать, кто и как будет выполнять это работу.
Третий этап (скорее, это все-таки принцип) я, честно говоря, считаю одним из самых принципиальных с точки зрения успешного выполнения проекта. По мнению автора, всякая попытка разделить руководство проектом между несколькими людьми, например, разделив его на техническое и административное, и даже просто наличие слишком сильного неформального лидера в коллективе приводят почти со 100 процентной вероятностью к провалу проекта. Но не менее пагубно сказывается на проекте и любое нежелание руководителя брать ответственность на себя. Руководитель проекта должен помнить днем и ночью, что он отвечает за все! Совсем необязательно и даже совсем нежелательно Руководителю делать все самому. У него есть более важные занятия. Но в любом случае, перед Руководством и Заказчиком за все в проекте отвечает именно он! Я бы добавил, что если вы не согласны отвечать за все, лучше не занимайтесь руководством проектами. Найдите себе более спокойное занятие вроде укрощения диких зверей или одиночных плаваний через океан.
Пожалуй, я бы добавил к данному разделу, что Руководитель проекта должен обладать достаточными полномочиями. Мало того, чтобы все управление проектом шло через единственного Руководителя. Этот Руководитель должен обладать существенными правами в части формирования цели и планов выполнения проекта, возможности непосредственно договариваться с Заказчиком, поощрения и наказания участников и много чего еще. Только в таких условиях единоличная ответственность за выполнение проекта не раздавит, а мобилизует руководителя проекта.
Четвертый этап можно считать развитием принципов предыдущего. У каждого дела внутри проекта должна быть фамилия. Это позволяет более-менее равномерно загрузить сотрудников. Это гарантирует персональную ответственность за выполнение каждой задачи. Здесь, конечно, имеется в виду ответственность внутри команды, для внешнего мира Руководитель отвечает за все.
Возможных исполнителей для каждой задачи можно разделить на несколько категорий. Лучший вариант, если человек заведомо может и при этом хочет выполнить именно эту задачу! Несколько хуже, если его приходится уговаривать (возможно, в следующий раз уговоры не подействуют). Если он недостаточно квалифицирован, но, тем не менее, готов взяться за задачу - его можно обучить (если на это есть деньги и время). Значительно хуже, если он не хочет за нее браться или не может с ней справиться даже после обучения. Хорошо, если для такого сотрудника есть другие задачи, которыми он хочет и может заниматься. Если нет - увы!
При назначении исполнителей необходимо учитывать их общую загрузку. Возможно, человек, на которого вы рассчитываете, уже участвует в других проектах. Или выполняет какие-то другие обязанности. Значит, в вашем проекте он не сможет участвовать пять дней в неделю.
И еще один момент, о котором часто забывают. Административная работа тоже требует времени! И чем больше участников в проекте, тем больше времени нужно на администрирование. Соответственно, и нагрузку на себя руководитель должен планировать с учетом административных задач. Чтобы сократить объем административных задач для Руководителя (например, если он превосходит естественные возможности) можно ввести среди участников проекта внутреннюю структуру и назначить руководителей групп. В этом случае административную работу придется планировать и для них. Причем учтите, что если у вас нет обученных и проверенных руководителей групп, в начальный период вам придется тратить на работу с ними существенно больше времени, чем на рядовых подчиненных!
Пятая стадия - планирование резерва.
Как бы тщательно вы ни планировали, в проект надо заложить определенный резерв на случай непредвиденных ситуаций. Увы, руководство и Заказчики редко соглашаются с этим тезисом. Возможный вариант преодоления такой ситуации - подготовьте несколько планов с разным временем выполнения, штатом и бюджетом (но каждый с запасом). Пусть лучше они выбирают из предложенных планов, а не ковыряются в единственном. Так больше шансов на то, что они не будут возражать против резервов.
А помимо резервов стоит иметь заранее заготовленные планы, что вы будете делать, если что-то пойдет не так. Впрочем, это обычно называется управлением рисками. И в любом руководстве по управлению рисками все это описано более детально.
Пятая стадия знаменует завершение планирования очередной итерации. Теперь пора браться за выполнения планов. И здесь правила не сложнее.
Стадия шесть. Определите, кто из исполнителей требует какого контроля с вашей стороны. Идеальный исполнитель выполняет все, что ему поручили. За другими приходится следить, контролировать скорость выполнения, помогать принимать технические решения... С первыми работать приятно. А с остальными - необходимо. Увы, надо больше времени уделять тому, что необходимо. Таким образом, стадия переходит в принцип: "уделяйте больше внимания тем, кому ваша помощь необходима".
Стадия семь. А здесь, наоборот, принцип превращается в набор работ. Вы должны знать все, что происходит в проекте. И поэтому рабочий день Руководителя начинается с того, что он выясняет, завершены ли работы, которые должны были быть завершены. Начаты ли работы, которые должны были быть начаты. И у кого какие проблемы возникли.
Кроме того, в понедельник хорошо собрать всех (или хотя бы руководителей групп, если проект слишком велик) и обговорить планы на неделю. А в пятницу подвести итоги недели.
Ну а еще нужно контролировать ход проекта по косвенным признакам. Если люди получают удовольствие, - скорее всего, все идет нормально. А вот если есть проблемы в личных отношениях, никто не радуется, то это подозрительно.
Даже если проект пока идет по графику.
Стадия восемь. Информация о ходе выполнения проекта должна быть доступна всем: участникам проекта, Руководству и Заказчику. Может быть, не все должны знать все в полном объеме. Но лгать нельзя никому. Идеальное решение, это еженедельный отчет. Желательно сделать его многоуровневым. Так чтобы на самом верхнем уровне можно было получить ответ на вопрос "Проект в графике?". А на нижнем - сведения по отдельным задачам.
Если все в курсе состояния дел по проекту, то все и действуют адекватно этому состоянию. То есть, если вдруг обнаружилось некоторое отставание, то участники хорошо сработавшейся команды стараются повысить производительность или задержаться после конца рабочего для даже не рассчитывая на оплату сверхурочных. Кстати говоря, и с Заказчиком проще договориться о продлении сроков проекта, если он был в курсе возникавших проблем.
И так до конца итерации. Потом повторить все с самого начала. Не забудьте проверить, не изменились ли ваши цели! Спланируйте следующую итерацию. И выполните ее.
И вот после последней итерации вы, наконец, завершили этот проект! Как пишут в рекламе, вы это заслужили! Но пока все еще в памяти, не забудьте подвести итоги. Что оказалось не так, как вы предполагали изначально? Почему?
На этом книга не заканчивается. В ней приведена масса же конкретных рекомендаций по другим достаточно важным проблемам, часто встающим перед руководителями проектов. Это особенности работы при необходимости одновременно вести несколько проектов. Это принципы разработки и рецензирования планов проекта. Это способы снятия напряжения, приемы разрешения проблем и принятия решений, ведения переговоров и многое другое. И в заключение достаточно полный курс для освоения MS Project.
Надо отметить, что для иллюстрации этапов и принципов управления проектами автор использует много интересных примеров из истории экспедиций Амундсена и Скотта к Южному полюсу и из истории Гражданской войны в США.
Но вернемся к началу.
Сумел ли автор найти серебряную пулю? Неужели разработка ПО остается рискованной только потому, что не все прочитали эту книгу?
Честно говоря, странное ощущение осталось у меня после этой книги. С одной стороны, ну что здесь нового? Все содержание книги можно пересказать в одной фразе. Тщательно управляйте проектом!!! Именно так, с тремя восклицательными знаками. И это - чудодейственная серебряная пуля?
А с другой стороны, разве этого не достаточно, чтобы гарантировать успех? Ведь успешные проекты были во все времена, с использованием всех методологий разработки. И отличались они ни чем иным, как наличием качественного управления. Оно часто было практически незаметно. Начальник не драл глотку и не стучал кулаком по столу. Просто каждый знал, за что отвечает лично он. Когда он должен это сделать. И чем будет заниматься после.
А если вдруг происходило какое-то неприятное и вроде бы совершенно непредвиденное событие, то оказывалось, что к нему все в существенной мере уже готовы. А недостающие детали быстро уточняются и доводятся до всех участников. И проект, лишь слегка поскрипывая на, казалось бы, непреодолимых буераках, весело катит вперед к успешному завершению.
Но если все так просто, то почему же мы никак не забудем про проекты, не уложившиеся в график, в смету, а то и вовсе завершившиеся пшиком? И даже не исследовательские, экспериментальные, прорывные, а такие скромные, типовые проекты...
Потому, что научить правильному стилю руководства очень сложно. Если вы прочитали книжку по UML, то, худо-бедно, вы будете рисовать и понимать UML диаграммы. Если вы прочитали руководство по IDEF1, вы будете понимать диаграммы в нотации IDEF1. А если вы прочитали книжку по структурному управлению проектами, вы, конечно, можете выучить 10 стадий. Но не факт, что вы сумеете их применить.
Вы не верите? Начнем с ключевой стадии. Готовы ли вы признать, что, если проект провалился, то это именно вы лично как руководитель проекта привели его к провалу?
На словах все мы готовы согласиться с тем, что Руководитель должен отвечать за проект.
А на деле часто думаем примерно так: "Но ведь я хороший! Это вот только подчиненные мне достались так себе, если не сказать прямее… Иванов в три раза дольше, чем было запланировано, возился со своим модулем! А Петрова вообще в декрет ушла! А кем я ее заменю? А Сидоров? Ну, переназначили его пять раз на новую задачу до того, как он предыдущую доделал. Но ведь это для проекта так нужно было, а он обижается! И после этого, вы скажете, что я плохо руководил, и поэтому проект затянулся на три года вместо шести месяцев? Да дали бы мне нормальных программистов, я бы... А если я планы не писал, так это для того, чтобы больше времени самому программировать. Если бы не я, вообще неизвестно, закончили ли бы мы этот проект хоть когда-нибудь!"
К сожалению (для проектов, но к счастью для нас самих), человеку свойственно оправдывать самого себя. Поэтому подчиненные валят все на начальников, а начальники - на подчиненных. И далеко не у всех хватает характера и навыков реально проанализировать "А что я сделал не так? А как это можно было сделать лучше?" И еще у меньшего числа людей получается после честных ответов на эти вопросы в следующий раз действительно сделать все лучше, чем в предыдущий. А то ведь тоже нередко можно услышать: "Нет, писать детальные планы - это не для меня!"
Так что серебряные пули есть. Просто они не всем помогают. И если у героя, которому принадлежат слова, взятые в качестве эпиграфа, с ними ничего не получилось, то надо еще разбираться, в чем проблема: в пулях или в герое.
Если же вы все-таки сумеете переломить себя и тщательно спланировать проект… Пусть даже не в MS Project, и даже не на бумаге, а в голове по дороге на работу… Если вы будете помнить, кто из разработчиков чем занят, и тщательно продумывать, кому какую следующую работу лучше назначить… Короче, попробуйте, а вдруг у вас получится!
Ну и еще одно замечание. Даже с самыми замечательными серебряными пулями, чтобы проект был выполнен качественно и в срок, нужно много пота.В том числе от Руководителя проекта. Не скажу, что это гарантирует успех. Скажу по-другому, это делает успех возможным.
Так что не надейтесь, что, прочитав эту книгу, вы получите чудодейственное средство, с помощью которого вы решите все ваши проблемы. Но знакомство с ней позволит вам если не качественнее выполнять ваши обязанности, то, по крайней мере, сравнить свои навыки и привычки как руководителя с опытом неплохого специалиста.
Управление проектами - статьи
Анализ и трансформации исполняемых UML моделей
Волкова Е.Д., Страбыкин А.Д.,Труды Института системного программирования РАН
Анализ исполняемых UML-моделей
С целью выявления особенностей использования конечных автоматов UML в реальных промышленных проектах было проведено статистическое исследование набора моделей. Все рассмотренные модели описывают поведение системы с использованием конечных автоматов, по которым можно сгенерировать исполняемый код.Конечные автоматы UML могут описывать поведение следующих элементов исполняемых моделей:
В зависимости от своего происхождения, все исследованные модели UML можно разделить на два класса:
Исполняемые UML-модели второго класса в основном описывают различного рода коммуникационные системы (то есть такие классы систем, для моделирования которых предназначен язык SDL). Исполняемые модели первого класса в связи с универсальностью языка UML описывают гораздо более широкий спектр систем.
Характеристика конечных автоматов
Общая статистика по исследованным моделям представлена в . Перечисленные модели были заимствованы из реальных проектов коммерческих компаний. Для сбора и анализа необходимой информации был разработан дополнительный модуль к промышленной среде UML-моделирования Telelogic Tau G2.Ожидалось, что модели, используемые в реальных проектах, будут иметь достаточно высокий уровень сложности. Тем не менее, более 90% от всех описанных автоматов содержат не более трех состояний, а доля автоматов без состояний (включающих только один начальный переход) близка к 75% (рис. 1). Причем доля таких автоматов растет вместе с размером модели.
Рис. 1. Количество состояний в конечных автоматах
Следует отметить, что автомат без состояний практически не обладает семантикой автомата и может использоваться только в качестве одной из форм записи некоторой последовательности действий, выполняемой в процессе во время начального перехода. Более того, текстовый синтаксис кажется намного более удобным средством для подобных спецификаций. Таким образом, оказывается, что в промышленных проектах примерно в половине случаев конечные автоматы используются не по своему прямому назначению. Причиной этому может служить недостаточный уровень владения инструментом у разработчиков модели или же, например, требование унифицировать все описания поведенческих аспектов системы с использованием для этого конечных автоматов.
На основе полученных данных использование конечных автоматов без состояний может быть объяснено следующим образом. В рассмотренных моделях операции практически не обладали семантикой состояний, поэтому 99% операций описывались автоматами без состояний, вырождаясь в императивную последовательность действий. Таким образом, использование автоматов для спецификации операций, как правило, не оправдано, и, тем не менее, широко применяется на практике.
Рис. 2. Количество состояний в конечных автоматах, реализующих классы
Если рассмотреть автоматы, реализующие классы, то распределение количества состояний значительно изменяется (рис. 2).
Для спецификации классов практически не используются автоматы без состояний, в то время как преобладают автоматы, имеющие одно состояние. Такая структура характерна для классов, не обладающих сложной внутренней логикой, а реализующих некоторый сервис для других компонентов системы. В единственном имеющемся состоянии, которое очень часто носит имя "Idle" или "Wait", класс ожидает запроса на выполнение какой-либо операции. Получение запроса инициирует срабатывание перехода, в процессе которого выполняются необходимые действия. По завершении обработки класс вновь возвращается в исходное состояние.
Автоматы, специфицирующие иерархические состояния, составили чуть менее 2% от всех обнаруженных автоматов и были найдены всего лишь в нескольких из рассмотренных моделей, что позволяет сделать вывод об их достаточно редком использовании, несмотря на их выразительную мощность. Причиной тому может служить тот факт, что составные состояния не являлись частью языка SDL до его версии SDL-2000. Большинство крупных промышленных моделей SDL, впоследствии трансформированных в UML, было разработано до того, как появился новый стандарт SDL-2000.
На рис. 3 приведена статистика количества переходов, которые могут сработать в каждом из состояний автомата. И здесь снова 84% процента состояний достаточно просты в понимании, так как имеют не более 6 переходов. Однако состояния с большим числом переходом могут заметно затруднить понимание автомата, а их доля приближается к 15%; более того, как правило, эти состояния являются ключевыми в понимании алгоритмов, заложенных в конкретный автомат.
Рис. 3. Количество переходов из состояния
Таким образом, в среднем автомат, реализующий класс, содержит 3 состояния и около 12 переходов и 4 диаграмм, при этом около 90% автоматов содержат не более 6 состояний, и, следовательно, их понимание не должно вызывать серьезных затруднений у разработчиков. Однако внутренняя логика работы системы, как правило, реализуется оставшимися 10%, среди которых встречаются автоматы, насчитывающие до 30 состояний.
Вполне очевидно, что умственные затраты на понимание такого автомата достаточно велики; соответственно, значительно затрудняется процесс его модификации, поиска ошибок и проч. Поэтому средства, уменьшающие сложность автоматов, сохраняя их внешние свойства, действительно востребованы на практике.
Рис. 4. Распределение количества символов на диаграммах
Анализ диаграмм состояний показал (см. рис. 4), что в среднем автомат, реализующий класс, включает в себя 3-4 диаграммы, каждая из которых содержит около 9 символов и 9 линий, что не должно в значительной степени препятствовать пониманию. В то же время для 10% автоматов, описывающих внутреннюю логику работы системы и содержащих более 6 состояний и переходов, количество диаграмм, на которых описан автомат, возрастает до пятидесяти, что очень сильно затрудняет понимание целостной картины работы системы.
Img12b.shtml
Рис. 12. Краткое описание всего конечного автомата
Используемые конструкции
Для повышения уровня выразительности и упрощения описания сложных систем в состав средств описания конечных автоматов UML был включен ряд специальных конструкций. Их использование позволяет во многом упростить и сократить описание сложных автоматов, и поэтому одной из целей проведенного исследования было выявление характера использования подобных конструкций. Далее приведен обзор полученных результатов.За счет использования операторов ветвления в действиях, выполняемых при срабатывании перехода в автомате, один и тот же переход может в различных условиях перевести автомат в различные состояния. Максимально возможное использование ветвления означало бы наличие в каждом состоянии не более чем одного перехода для любого сигнала. В этом случае выбор состояния, в которое перейдет автомат, происходил бы в процессе интерпретации действий, приписанных переходу. Результаты статистического исследования приведены на рис. 5.
Рис. 5. Ветвистость переходов
Как и следовало ожидать, большинство переходов не разветвляются, а около 90% из них имеет не более трех ветвей. Однако 3% переходов, имеющие более 5 ветвей, могут заметно усложнить понимание логики работы системы. Абсолютный максимум составил 21 ветвь в одном переходе.
Использование графического синтаксиса позволяет проводить графическую декомпозицию диаграмм состояний - распределять сложные автоматы по нескольким графическим сущностям, не упрощая при этом структуру автомата. Этот подход позволяет облегчить процесс понимания деталей работы сложного автомата, однако затрудняет восприятие автомата как единого целого, что немаловажно для понимания логики работы сложной системы.
Одним из средств графической декомпозиции UML являются метки. Они позволяют графически отделить участки диаграммы состояний, чтобы, например, перенести их на другую диаграмму или расположить отдельно на исходной диаграмме. Кроме того, введение меток способствует повторному использованию фрагментов диаграмм, так как переход на единожды описанную метку может быть выполнен многократно из различных частей автомата.
Статистика использования меток приведена на рис. 6.
Рис. 6. Распределение переходов на метки
Распределение количества команд перехода на метки очень похоже на распределение количества ветвей. В обоих случаях наиболее простые варианты (одна ветвь и отсутствие переходов на метки) обеспечивают около 60% случаев, а следующие по сложности варианты (две ветви и одна команда перехода на метку) - около 20%, в то время как остальные варианты имеют по 3-4%. Однако в автоматах встречались и переходы, перегруженные командами перехода на метки. Для некоторых переходов в автомате максимальное количество команд перехода на метку превысило 20.
Чтобы избежать дублирования переходов для различных состояний, можно использовать несколько приемов. В UML в символе состояния можно перечислить несколько имен состояний, и тогда все переходы, выходящие из этого символа, будут относиться ко всем перечисленным состояниям. Кроме того, если в качестве имени состояния указать символ "*", то переходы, выходящие из этого символа, будут относиться ко всем состояниям автомата. Также имеется возможность исключить определенные состояния из множества состояний, описываемого символом "*". Умелое использование этих возможностей позволяет значительно упростить описание переходов, применимых более чем к одному состоянию. Результаты статистического исследования показали, что символ * присутствует в 12% символов состояния, что свидетельствует о достаточно активном использовании этой подстановки и необходимости более детального изучения вариантов ее использования и возможных трансформаций с выделением или заменой символа "*".
Кроме того, при описании состояния, в которое должен быть совершен переход, UML позволяет использовать символ "-", означающий состояние, в котором был инициирован исходный переход. Согласно статистике более трети символов состояния содержит символ "-". Это снова свидетельствует об удобстве и востребованности этой конструкции, а также о необходимости исследовать затрагивающие ее трансформации.
Пример "Мобильный телефон"
Продемонстрируем применение трансформации "Выделение части конечного автомата в метод" на одном из конечных автоматов системы Mobile, моделирующей работу мобильного телефона.В исходной системе конечный автомат представлен на 28 диаграммах, каждая из которых описывает ровно один переход (рис. 11).
Рис. 11. Исходный вид конечного автомата
Такое представление не позволяет понять цельную структуру конечного автомата. Для упрощения понимания была создана дополнительная диаграмма, схематично описывающая весь конечный автомат, иллюстрирующая все состояния и переходы со всеми ветвлениями (рис. 12).
Рис. 12. Краткое описание всего конечного автомата
Приведённый алгоритм позволяет найти и выделить из данного конечного автомата три метода. На первом шаге в метод Initialize() выделяются четыре последовательных состояния (рис. 13).
Рис. 13. Выделение метода Initialize
На втором шаге выделяется метод TalkingThePhone() (рис. 14), после чего становится возможным выделить ещё один метод, который назовём Working().
Рис. 14. Выделение метода TalkingThePhone
Обратим внимание на то, что выделение метода Working возможно только после выделения метода TalkingThePhone. Процесс применения трансформации итеративный. Поиск частей конечного автомата, которые можно вынести в отдельный метод, можно автоматизировать.
В результате применения трансформаций исходный конечный автомат сильно упростился и свободно помещается на одной диаграмме (рис. 15). Теперь он содержит только одно состояние (вместо четырнадцати состояний в исходном автомате) и вызов двух методов.
Рис. 15. Результат трансформации
Выделены три метода Initialize(), TalkingThePhone() (рис. 16) и Working() (рис. 17), содержащие 4, 5 и 4 состояния соответственно.
Рис. 16. Метод Working
Рис. 17. Метод TalkingThePhone
Tab1.shtml
| Aircraft Simulator | Симулятор самолета | UML | 371 | 1 | 2 | 0 | 0 | 34 |
| Central Interface | Система контроля доступа | UML | 253 | 4 | 0 | 1 | 8 | 24 |
| IOS Algorithms | Система ввода/вывода | UML | 1 611 | 11 | 41 | 2 | 70 | 203 |
| Llama Simulator | UML | 894 | 6 | 2 | 0 | 31 | 126 | |
| MMI | UML | 3267 | 17 | 20 | 0 | 45 | 112 | |
| MV-IOS6 | UML | 675 | 5 | 0 | 0 | 14 | 118 | |
| 3gN | UML | 8660 | 12 | 175 | 0 | 2708 | нет инф | |
| ATM and Banklib | Банкомат | SDL | 144 | 4 | 1 | 0 | 4 | 12 |
| Local Exchange | SDL | 178 | 3 | 5 | 0 | 2 | 13 | |
| Access Control | Система контроля доступа | SDL | 281 | 8 | 1 | 0 | 10 | 34 |
| DEL_REL | SDL | 190 | 3 | 2 | 0 | 21 | 22 | |
| Inres | SDL | 121 | 4 | 0 | 0 | 4 | 15 | |
| Mobile | Мобильный телефон | SDL | 772 | 14 | 0 | 0 | 27 | 156 |
| Pager | Пейджер | SDL | 161 | 3 | 4 | 0 | 4 | 14 |
| cc_layer | SDL | 1066 | 3 | 19 | 0 | 45 | 39 | |
| common Executor | SDL | 1396 | 5 | 39 | 0 | 12 | 89 | |
| 1xevdo | SDL | 21817 | 21 | 482 | 0 | 350 | 1457 | |
| ATC_ENV | SDL | 5710 | 17 | 62 | 0 | 867 | 226 | |
| CpCallm | SDL | 67295 | 9 | 760 | 0 | 2262 | 1009 | |
| S | SDL | 380 | 1 | 9 | 0 | 0 | 34 | |
| SS_RCS | SDL | 20572 | 3 | 94 | 0 | 175 | 547 | |
| Tarif_c7 | SDL | 881 | 2 | 25 | 0 | 4 | 104 | |
| DC2000_5 | SDL | 19420 | 33 | 226 | 0 | 447 | 1483 | |
| 23 модели | 7 - UML 16 - SDL | 152 М | 189 | 1969 | 3 | 7110 | 5871 | |
| В среднем: | 6.6 М | 8 | 86 | 0 | 309 | 267 |
Таблица 1. Общая статистика по исследованным UML-моделям.
1 В колонке "пассивные типы данных" учитывались следующие типы: пассивный класс, тип данных (datatype), перечислимый тип (enum), синоним типа (syntype), объединение (choice)
Типичные способы построения конечных автоматов
Анализ полученной выборки не выявил каких-либо стандартов или "правил хорошего тона" при разработке конечных автоматов. Единственным "паттерном" можно считать применяемую одной из компаний методику, когда при описании автомата для каждого перехода из заданного состояния используется отдельная диаграмма, и еще одна диаграмма используется для всех общих описаний. Естественным недостатком такого подхода является сложность получения целостного представления о моделируемом автомате по причине разрозненности отдельных диаграмм, описывающих состояния.Трансформация "выделение метода" для конечных автоматов UML
Идея трансформации "Extract method" состоит в создании нового метода и переносе части исходного автомата в добавленный метод. Данная трансформация во многом аналогична известному рефакторингу "Extract Method" для объектно-ориентированных языков программирования, описанному в каталоге Фаулера []. Суть традиционной трансформации состоит в выделении участка кода и перемещении его в другой метод. Это позволяет сделать код исходного метода более понятным и повышает вероятность повторного использования выделенного метода.Для корректного выполнения традиционного рефакторинга "Extract method" требуется тщательный анализ потока данных в выделяемом участке кода, так как все используемые переменные должны быть переданы в метод в качестве параметров, а все изменения переменных должны быть тем или иным образом возвращены исходному методу, если измененные переменные используются в нем далее.
Для первичного рассмотрения проблемы выделения метода в автомате эту проблему можно обойти следующим образом. Если используемая переменная является атрибутом автомата или сущности, содержащей автомат, то она будет видна и в выделенном методе и, следовательно, ее не нужно передавать в качестве параметра. Если же используемая переменная является локальной для действий, выполняемых в переходе, то при перенесении всех действий перехода в выделяемый метод определение локальной переменной и все ее использования будут также перенесены. Для выделения метода, в который помещаются не все действия, выполняемые в переходе, требуется дополнительный анализ потока данных.
Следует подчеркнуть исключительную важность автоматизированной поддержки рефакторинга при проведении подобных преобразований, ибо сложность проводимого анализа будет способствовать ошибкам.
Идея, лежащая в основе традиционного рефакторинга "Extract method", может быть применена к конечным автоматам несколькими способами.
При создании сложных инженерных систем
При создании сложных инженерных систем принято использовать приемы моделирования. Сложность большинства создаваемых сегодня программных систем не уступает сложности многих инженерных сооружений, поэтому моделирование программных систем является весьма актуальной задачей. Более того, в таких концепциях, как MDA (Model Driven Architecture - архитектура на основе моделей) и MDD (Model Driven Development - разработка на базе моделей), моделям отводится центральная роль в процессе создания программного продукта. Основной идеей этих концепций является представление процесса создания программного продукта в виде цепочки трансформаций его исходной модели в готовую программную систему.Почти во всех инструментальных средствах, воплощающих идеи MDD, в качестве языка моделирования используется язык UML (Unified Modeling Language - унифицированный язык моделирования), целиком или какие-либо его части.
UML - это язык, предназначенный для визуализации, специфицирования, конструирования и документирования программных систем. Слово "унифицированный" в названии языка означает, что UML может использоваться для моделирования широкого круга приложений от встроенных систем и систем реального времени до распределенных web-приложений. Выразительные средства языка позволяют описать систему со всех точек зрения, имеющих отношение к разработке и развертыванию.
В свете инициатив MDA и MDD роль моделей в жизненном цикле программного обеспечения (ПО) претерпевает значительные изменения. Если ранее моделирование рассматривалось как одно из удобных средств документирования, и, соответственно, жизненный цикл моделей был близок к жизненному циклу артефактов документации, то в последнее время работа с моделями становится все более похожа на работу с исходными кодами. Подобный подход ставит перед исследователями новые задачи исследования применимости к моделям методик и приемов работы, используемых для работы с исходными кодами. Одной из таких методик является рефакторинг.
Рефакторинг - это изменение внутренней структуры ПО, имеющее целью облегчить понимание и упростить модификацию, но не затрагивающее при этом наблюдаемого поведения.
Рефакторинг, как набор методик преобразования программ, помогает решать две глобальные задачи: облегчение процесса повторного использования каких-либо компонентов программной системы и снижение расходов на поддержку и сопровождение системы. Первые рефакторинги появились в результате обобщения опыта нескольких экспертов в области объектно-ориентированного проектирования. В этом отношении рефакторинги достаточно близки к широко известным на сегодняшний день паттернам проектирования.
Существует много исследовательских работ и публикаций, посвященных методам и алгоритмам применения рефакторинга. Полноценная поддержка рефакторинга ставит перед производителями следующий ряд задач:
По каждому из указанных пунктов ведутся научные разработки, но лишь в немногих из них учитывается специфика UML.
Анализ существующих UML моделей, приводимый в данной статье, показывает, что их структура сложна для понимания и содержит недостатки, которые можно было бы устранить путём проведения эквивалентных трансформаций. Особое внимание уделяется анализу и поиску методов рефакторинга для конечных автоматов языка UML, которые являются основой для полностью автоматической генерации исполняемого кода по UML-моделям. На базе проведённого анализа и выявленных недостатков описывается новая трансформация, специфичная для UML.
Выделение в метод части конечного автомата
Рассмотрим определение части конечного автомата, представленное на рис. 7.
Риc. 7. Часть автомата, допускающая выделение метода
Выбрав часть перехода вместе со следующим состоянием, можно выделить метод, в которую войдет часть состояний конечного автомата, начиная с состояния Y. Будем называть такую трансформацию Extract Sub State Machine.
Применимость данной трансформации связана со следующим свойством. Состояния, переносимые в выделяемый метод, перестают принадлежать исходному автомату и, следовательно, команды перехода, приводящие из состояний исходного автомата в состояния, перенесенные в выделенный автомат, некорректны. Такие команды перехода (смены состояния) должны быть заменены командами вызова выделяемого метода. Однако у автомата, реализующего метод, может быть только одна входная точка, поэтому либо все такие команды должны осуществлять переход в одно и то же состояние, либо можно использовать целочисленный параметр для передачи номера того состояния, с которого должно начаться выполнение метода. Но введение такого параметра и добавление его обработки в начальном переходе усложняет выделяемый автомат и затрудняет его понимание.
Для обработки обратных переходов из состояний выделенного метода в состояния исходного автомата может быть применен следующий прием. Все состояния исходного метода, в которые можно попасть из выделяемого метода, нумеруются последовательными натуральными числами. Все команды перехода, ведущие из состояний выделяемого метода в состояния исходного, заменяются командами возврата из метода, использующими в качестве возвращаемого значения номер того состояния, в которое должен был бы осуществиться переход. После замены тела выделенного метода его вызовом возвращаемое им значение присваивается новой локальной переменной, и после возврата из метода оно анализируется для определения состояния, в которое должен был осуществиться переход. Описанный прием, хотя и позволяет при выделении метода не накладывать ограничений на количество обратных переходов, на практике зачастую только затрудняет понимание автомата, что противоречит целям проведения рефакторинга.
Часть автомата, выделенная в метод, обладает следующей семантикой: получив сигнал Sig3(), автомат выполняет некоторые действия, начиная с состояния y, по завершении которых возвращается в состояние x. Подобная логика близка по смыслу к вызову метода: выполнение задачи с последующим возвратом в исходное состояние. Именно это и служит основанием для выделения метода.
В результате преобразования выделяется структурная единица автомата - метод, а диаграмма, описывающая конечный автомат, уменьшается, что упрощает его понимание Результат преобразования представлен на рис. 8. Выделенный метод показан на рис. 9. Выделенный метод можно использовать повторно для уменьшения дублирования кода.
Существует несколько частных случаев трансформации Extract Sub State Machine.
Во втором случае выделение метода корректно при выполнении следующих условий:
В рассматриваемом случае преобразованный автомат будет выглядеть так, как показано на рис. 10
Рис. 10. Результаты применения второго варианта трансформации
Таким образом, задача трансформации моделей
Таким образом, задача трансформации моделей UML является достаточно актуальной. Проведенные исследования подтвердили гипотезу о возможности улучшения структурных качеств и упрощения понимания моделей, применяемых в реальных промышленных проектах. Это ставит перед исследователями задачи поиска новых трансформаций, в которых учитывается специфику моделей UML. Для оценки применимости и полезности трансформаций необходимо продолжение работы по формализации подмножества конечных автоматов UML, описанию семантики их выполнения, а также создание инструментальных средств, автоматизирующих сбор необходимой информации и процесс трансформации моделей.Управление проектами - статьи
Аннотация.
Модельно-ориентированный подход к разработке ПО позволяет решить проблемы, связанные с постоянно увеличивающимся количеством технологических платформ, а так же может ускорить разработку и интеграцию систем. Но он станет по настоящему эффективным только когда будут разработаны программные инструменты для его поддержки, что в свою очередь требует разработки технологии автоматизированной трансформации моделей ПО. В данной статье рассмотрены различные подходы к разработке такой технологии, а так же предложен язык программирования, предназначенный для описания трансформаций объектных моделей.Язык описания трансформации
Описание трансформации представляет собой один или более блоков трансформации. Каждый блок имеет уникальное имя и состоит из последовательности правил трансформации. В заголовке блока может быть также указан параметр, определяющий порядок выполнения этого блока. Ниже приведены фрагменты синтаксической нотации языка трансформации, заданной с помощью расширенных БНФ (форм Бэкуса-Наура). transformation::=Каждое правило имеет уникальное имя и состоит из секции выборки, определяющей, в каких случаях применимо правило, и секции генерации, в которой задаются действия, совершаемые при применении правила.
transformation_rule::= rule
Секция выборки состоит из последовательности операторов выборки. Каждый оператор выборки объявляет новую переменную, называемую переменной выборки. Имя этой переменной должно быть уникальным в пределах данного правила, а область значений - множество элементов модели, задаваемое с помощью навигационного выражения. Кроме того, секция выборки может содержать уточняющие условия - логические выражения, в котором могут использоваться переменные выборки, объявленные вышестоящими (в рамках правила) операторами выборки.
select_section::= (
Навигационное выражение - это последовательность направлений навигации, начинающаяся с имени ранее объявленной переменной (назовём её базовой переменной), в качестве разделителя используется символ "/". Направление навигации - это имя ассоциации в метамодели UML, соответствующей трансформируемой UML-модели (если в трансформации участвует несколько моделей с разными метамоделями, то метамодель определяется по тому, на элемент какой модели указывает начальная переменная).
nav_expression::=
При вычислении навигационного выражения происходит последовательный переход от одного UML-элемента к другому по ассоциации метамодели, соответствующей очередному направлению навигации, начиная со значения базовой переменной. Под кардинальностью направления навигации будем понимать множественность (multiplicity) соответствующей ассоциации метамодели. Если кардинальность очередного направления навигации больше единицы и существует неоднозначность в выборе элемента модели для перехода, то переход осуществляется по всем вариантам, то есть в результат включаются все подходящие элементы. Формально результат вычисления навигационного выражения можно описать с помощью индукции:
Таким образом, результатом вычисления навигационного выражения является список из всех возможных элементов модели, которых можно достичь из начального элемента, определяемого значением базовой переменной, по заданным направлениям перехода. У навигационного выражения можно выделить следующие характеристики:
Кардинальность выражения равна 1, если кардинальность всех направлений навигации равна 1. Кардинальность определяется статически, по метамодели.
Навигационное выражение может начинаться с любой ранее объявленной локальной или глобальной переменной. Под локальными переменными понимаются переменные, объявленные в исполняемом на данный момент правиле. Разумеется, в каждом конкретном операторе допустимо использовать только локальные переменные, объявленные в вышестоящих (в описании правила) операторах: так как выполнение правила происходит сверху вниз, локальные переменные, порождённые нижестоящими операторами, на момент выполнения текущего оператора ещё не инициализированы. Глобальными переменными являются имена моделей, участвующих в трансформации. Очевидно, что навигационное выражение самого первого оператора выборки каждого правила может начинаться только с глобальной переменной, так как ни одна локальная переменная ещё не объявлена.
Секция генерации - это последовательность операторов создания, изменения или удаления элементов модели. Оператор создания элемента позволяет добавить новый элемент модели в последовательность элементов, оператор удаления - исключить элемент из списка. Соответствующие навигационные выражения указывают на изменяемый список и определяют тип добавляемого элемента. Кардинальность навигационного выражения должна быть больше 1. Оператор изменения позволяет менять значение того или иного поля данных или атрибута; при этом навигационное выражение указывает на изменяемый элемент (и кардинальность выражения должна быть равна единице). Также существуют операции добавления в список уже существующего элемента и исключения элемента из списка; они предназначены для использования в тех случаях, когда в метамодели имеются циклы или один и тот же метаэлемент доступен сразу по нескольким ассоциациям: в таких случаях для формирования модели может оказаться недостаточно операций создания и удаления элементов.
generate_section::= (
Механизмы уточнений правил и шаблоны
Для улучшения структуры языка трансформации в него добавлено понятие уточнения правил. При описании любого правила можно объявить, что оно уточняет одно из ранее объявленных правил в рамках того же блока трансформации. Для этого в заголовке правила после его имени указывается имя уточняемого правила. Возможно создание многоярусных древовидных иерархий за счёт дальнейшего уточнения уточняющих правил и создания нескольких уточняющих правил для одного уточняемого. При написании операторов выборки уточняющего правила помимо переменных, объявленных в предыдущих операторах данного правила могут использоваться все переменные выборки из уточняемого правила, а при написании секции генерации - все переменные секций выборки и генерации уточняемого правила.transformation_rule::= rule
Уточняющее правило применимо в тех случаях, когда выполняются все условия из следующего списка:
Применение уточняющего правила заключается в выполнении операторов секции генерации. После выполнения секции генерации происходит замена трансформационной связи, порождённой применением уточняемого правила, на расширенную трансформационную связь, включающую как старые переменные, так и переменные, объявленные уточняющим правилом. Трансформационная связь при этом именно расширяется за счёт добавления новых полей, старые же поля сохраняются, по аналогии с классическим механизмом наследования. Такая трансформационная связь будет соответствовать как выборкам из совокупности трансформационных связей, нацеленных (с помощью навигационного выражения) на связи, порождённые уточняемым правилом, так и выборкам из связей, порождённых уточняющим правилом. Применение уточнений позволяет структурировать совокупность трансформационных связей и создавать древовидные иерархии наследования среди связей. Так как трансформационные связи можно использовать в описаниях других правил, подобные иерархии позволяют более эффективно описывать трансформации, а также задавать трансформации, которые было бы невозможно задать по-другому.
Шаблон - это специальная разновидность правила, описание которого начинается с ключевого слова "abstract". Сам по себе шаблон не применим никогда, вне зависимости от его секции выборки. Но на основе шаблона за счёт механизма уточнения можно создавать новые правила, которые уже могут быть применены при соответствии выборки и трансформируемой модели. Как и при применении обычных уточнений, использование шаблонов позволяет структурировать совокупность трансформационных связей для её последующего использования в других правилах трансформации. Возможно создание шаблонов как уточнений других шаблонов, но нельзя создать шаблон, являющийся уточнением обычного правила.
Полнота языка трансформации моделей.
Важным требованием к языку описания трансформаций при его использовании в MDA является универсальность - возможность описать с его помощью любое преобразование из PIM в PSM для любой технологии. Причём необходимо учитывать не только все существующие технологии, но и те, которые будут разработаны в будущем. Это означает, что язык должен позволять задавать любые отображения моделей. Будем считать, что все метамодели связны, то есть любой элемент метамодели достижим из корневого элемента метамодели с помощью навигационных выражений.Теорема 1. С помощью предложенного языка трансформации можно задать любое однозначное отображение моделей.
Для доказательства нам понадобятся две леммы.
Лемма 1. Для любой конечной модели можно написать правило, которое бы было применимо к ней и не применимо к любой другой модели.
Доказательство.
Применимость правила определяется его секцией выборки. Приведём алгоритм построения нужной нам секции выборки, которая бы соответствовала определённой модели a и не соответствовала никакой другой. Для каждого элемента модели ri из a построим оператор выборки forall ri from model/nav_expression, где nav_expression - навигационное выражение, позволяющее выбрать данный элемент (и все остальные элементы того же типа) в модели. Для каждого атрибута ej со значением fj построим уточняющее выражение where ri/ej=fj. Для каждой относящейся к данному элементу связи sj с кардинальностью 1 добавим уточняющее условие where ri/sj=rk, где rk - элемент модели, на который указывает связь. Для каждой связи sj с кардинальностью больше 1, которая связывает данный элемент с элементами rj1…rjn, добавим уточняющее условие where (rj1 belongsto ri/sj) and … and ( rjn belongsto ri/sj) and ((ri/sj exclude rj1 exclude rj2 … exclude rjn)=null) (если связь sj пуста, то есть n=0, то такое уточняющее условие вырождается в where ri/sj=null). Если создать такие операторы выборки и уточнения для всех элементов модели a, то полученная секция выборки будет удовлетворять необходимым свойствам: она применима к модели a и не применима ни к какой другой.
Лемма 2. Для любой модели можно написать правило, которое бы при выполнении создавало эту модель.
Доказательство этой леммы элементарно. Секция генерации позволяет императивно описывать процесс создания модели элемент за элементом. Поэтому для того, чтобы правило генерировало определённую модель a, следует в секцию генерации добавить операторы создания для каждого элемента модели и инициализировать все атрибуты и ссылки их значениями, взятыми из модели.
Доказательство теоремы 1.
Пусть есть множество исходных моделей A и множество генерируемых моделей B, и отображение U, которое каждой исходной модели ставит в соответствие определённую генерируемую модель. Необходимо доказать, что это отображение можно задать с помощью правил трансформации, то есть что ∃T: ∀ a∈A T(a)=U(a), где Т это описание трансформации, а T(a) - результат применения этой трансформации к модели a из A.
Будем строить это описание трансформации следующим образом. Представим отображение U в виде множества пар вида (,). Для каждой такой пары (a,b) в описание трансформации добавим правило специального вида.
Его секция выборки должна быть применима только на модели a, причём ровно один раз. То, что такая секция выборки возможна, доказано в лемме 1. А для того, чтобы правило никогда не применялось дважды (это могло бы случиться, если модель a обладает симметрией), добавим уточняющее условие вида where rules/rule_name=null, где rule_name - имя данного правила. После первого применения правила соответствующее множество трансформационных связей будет не пусто, а условие - ложно, что гарантированно не допустит повторного применения правила.
Секция генерации этого правила при выполнении должна создавать модель b со всеми содержащимися в ней элементами. Существование такой секции генерации доказано в лемме 2.
Итак, правило такого вида будет порождать модель b, если исходная модель - a, и не будет делать ничего (ни разу не будет применено), если исходная модель отлична от a.
Если создать такие правила для всех пар из исходного отображения U и объединить их в блок трансформации, то полученное описание трансформации T и будет искомым. Порядок следования и выполнения правил в блоке может быть любым. Доказательство того, что T- искомое описание трансформации, элементарно:
Возьмём произвольную модель a из множества исходных моделей, ей однозначно соответствует некоторая модель из множества генерируемых моделей, назовём её b. То есть выполняется U(a)=b. Тогда в описании трансформации T содержится правило t, соответствующее паре моделей (a,b), то есть t(a)=b. Так как отображение U однозначно, никаких других правил, применимых к модели а, в описании T не существует. Тогда T(a)=t(a)=b=U(a). Так как a - произвольная исходная модель, доказано что ∀ a∈A T(a)=U(a), то есть построенное нами описание трансформации T задаёт отображение U.
Доказательство окончено.
Существенным недостатком данной теоремы является то, что не гарантируется конечность описания трансформации, то есть если отображается бесконечное множество моделей, то и количество правил трансформации будет не ограничено. Даже если ограничить максимальное число элементов в модели, описание трансформации всё равно может быть бесконечным. Например, существует бесконечно много моделей, состоящих ровно из одного класса без атрибутов и операций, и различающихся только именами класса. Разумеется, на практике такое описание трансформации, состоящее из бесконечного количества правил, реализовано быть не может. Поэтому необходимо знать условия, при которых бы гарантированно существовало конечное описание трансформации.
Определение. Структурой модели назовём набор её элементов и связей между ними, без учёта значений атрибутов. Будем говорить, что две модели (определённые на общей метамодели) имеют общую структуру, если существует взаимно однозначное соответствие между элементами этих моделей, сохраняющее тип элемента и связи между элементами. На практике это означает, что модели имеют одинаковые элементы и связи между ними, но возможно разные значения атрибутов.
Определение. Будем называть модель конечной, если она состоит из конечного числа элементов метамодели. На практике, очевидно, все модели конечны.
Теорема 2. Пусть существует однозначное отображение U(x) множества исходных моделей A на множество генерируемых моделей B, и пусть все модели конечны. Пусть структура любой генерируемой модели зависит только от структуры исходной модели, но не от значений её атрибутов (то есть для любых исходных моделей a1 и a2 с общей структурой их образы U(a1) и U(a2) так же должны иметь общую структуру). И, наконец, пусть значение любого атрибута генерируемой модели может быть выражено как функция от исходной модели с использованием только алгебраических, строковых и теоретико-множественных операций. Тогда существует конечное описание трансформации T, задающее отображение U, причём это описание трансформации всегда выполнимо за конечное время.
Доказательство.
Множество исходных моделей A разобьём на минимальное число групп так, чтобы все модели внутри группы имели одинаковую структуру (то есть отличались только значениями атрибутов). Число таких групп будет конечно, так как по условию число элементов в любой модели конечно, а из конечного числа элементов можно составить конечное число моделей с различной структурой. Так как структура генерируемой модели зависит только от структуры исходной модели, отображение такой группы оператором U так же будет состоять из моделей с одинаковой структурой. Назовём её структурно однородной группой. Следовательно, отображение U можно представить в виде конечного множества отображений U1…Un, каждое из которых отображает структурно однородную группу моделей в структурно однородную группу. Представим это множество отображений в виде конечного множества пар (a, b=U(a)), где a и b - группы моделей с одинаковой структурой. Так же как и в доказательстве теоремы 1, построим правило трансформации для каждой такой пары.
Секция выборки строится аналогично теореме 1, за исключением того, что не добавляются уточняющие условия на значения атрибутов, так как правило пишется сразу для группы моделей и следовательно эти значения не определены.
В секции генерации, так же как и в доказательстве теоремы 1, явным образом используем операторы создания элемента и установления связей между ними. Так как модели в группе имеют общую структуру, генерация элементов и связей одинакова для всех моделей группы. А вот значения атрибутов для разных моделей могут отличаться, поэтому уже невозможно явно присвоить значения атрибутов. Но по условию теоремы, значение любого атрибута r из генерируемой модели bi∈ b может быть представлено как r=f(ai), где аi∈a, а f() - функция, которая может быть выражена через простейшие операции. Функция f() одна и та же для всех аi∈a. Следовательно, если для каждого атрибута r использовать оператор присваивания r=f(a), можно задать значения атрибутов сразу для всех bi∈b.
Итак, полученное правило t будет применимо ко всем моделям группы a, и ни к каким другим. При этом генерируемая модель всегда будет иметь структуру, соответствующую группе b, а значения атрибутов будут соответствовать отображениям конкретной исходной модели, то есть t(ai)=U(ai). Объединив множество таких правил для всех групп, получим описание трансформации T и ∀ а∈A T(a)=U(a). Число правил в описании трансформации равно числу групп моделей с одинаковой структурой. Так как число групп конечно (при условии что все модели конечны), описание трансформации T конечно. Так как для любой исходной модели при трансформации применяется ровно одно правило и только один раз, порядок применения правил в блоке трансформации T не влияет на результат. То есть мы можем назначить линейный порядок, в таком случае трансформация гарантированно завершится за конечное время. Все утверждения теоремы доказаны.
Замечание: на самом деле не обязательно наличие одной общей функции, выражающей атрибуты. Достаточно, чтобы значение каждого атрибута для всего множества генерируемых моделей задавалось с помощью конечного числа функций, представимых с помощью простейших операций над элементами, связями и значениями атрибутов исходных моделей.
Доказательство аналогично доказательству теоремы 2. Но вместо того, чтобы строить отдельное правило для каждой структурно однородной группы, эти группы следует сначала разбить на подгруппы так, чтобы значения атрибутов всех моделей в подгруппе выражались в виде одинаковых функций. Так как общее число функций, задающих атрибуты, конечно, то и число подгрупп будет конечно. Построив правило трансформации для каждой подгруппы так же, как и в доказательстве теоремы 1, и объединив все эти правила в единый блок трансформации, получим искомое описание трансформации.
Условия теоремы 2 можно смягчить ещё больше, но, к сожалению, невозможно совсем от них избавиться, придя к условиям теоремы 1 и сохранив гарантированную конечность описания трансформации. В частности, если значения атрибутов генерируемой модели не выражаются с помощью элементарных операций, то единственный способ задать такое отображение - перечисление. Если множество возможных значений атрибута бесконечно, то и количество правил трансформации, необходимых для задания такого перечисления, будет бесконечно большим. Однако описания трансформаций для большинства практических задач могут быть успешно заданы с помощью предложенного языка трансформации. Необходимо отметить, что используемый в доказательстве теорем метод построения описаний трансформации не рекомендуется для применения на практике, он крайне громоздок и использован только для формального доказательства полноты языка трансформации.
Практическая реализация инструмента трансформации
В настоящее время ведутся работы по практической реализации прототипа инструмента трансформации, поддерживающего описанный выше язык. В целях упрощения работы было принято решение сделать прототип, поддерживающий только одну метамодель (метамодель классов, показанную на ), однако при этом используются универсальные решения, которые можно легко перенести на любую другую модель и внедрить в инструмент поддержку любых метамоделей. На данный момент инструмент поддерживает работу только с парой моделей - исходной и генерируемой, но его функциональность будет расширена для поддержки одновременной трансформации нескольких моделей. Для внешнего представления UML на данный момент используется собственная текстовая нотация, но в будущем планируется включить в инструмент трансформации модуль, позволяющий импортировать и экспортировать модели в XMI-представлении. Это позволит интегрировать инструмент трансформации с различными средами UML-разработки, поддерживающими этот стандарт.Отдельной и пока не решённой задачей является создание UML-редактора, который мог бы поддерживать соответствие между моделями при внесении в них изменений уже после трансформации. Необходимая для этого информация о трансформационных связях сохраняется, но пока не используется после окончания процесса трансформации.
Пример описания трансформации
Ранее был описан пример трансформации, предназначенной для преобразования платформо-независимой UML-модели классов в платформо-зависимую модель, ориентированную на технологию CORBA. Но этот пример трансформации был описан на естественном языке, а теперь попробуем задать его с помощью формального языка трансформации. В данной трансформации будут участвовать две модели с именами "source" и "target", первая из которых является исходной моделью, а вторая создаётся в процессе выполнения трансформации. Будет использоваться упрощённая метамодель классов UML, приведённая на .Трансформация будет состоять из одного блока. Ниже показан заголовок этого блока и первое правило, соответствующее фразе "Для каждого класса из PIM следует создать класс реализации в PSM и связанный с ним класс-интерфейс" из неформального описания трансформации.
stage example_CORBA_transformation {
rule class_to_class { forall srcclass from source/classes make implclass in target/classes; implclass/name= srcclass /name+"_implementation"; implclass/stereotype="implementation" make interclass in target/classes; interclass/name=srcclass/name; interclass/stereotype="interface"; make d in target/associations; d/stereotype="realize"; make e in implclass/associations; e/base=d; e/cardinality=1; e/association_end_type="navigable"; include e in d/ends; make f in interclass/associations; f/base=d; f/cardinality=1; f/association_end_type="navigable"; include f in d/ends; e/otherend=f; f/otherend=e; }
Правило "class_to_class" для каждого класса исходной модели создаёт класс-интерфейс и класс-реализацию в генерируемой модели, а так же связь между ними. Далее напишем пару правил, соответствующих утверждениям "Все приватные атрибуты должны быть скопированы в соответствующие классы реализации" и "Публичные атрибуты следует также поместить в класс реализации, но уже как приватные; в интерфейс следует добавить методы для доступа и модификации этих атрибутов".
rule priv_attributes { forall srcclass from source/classes forall srcattrib from a/attributes where ((srcattrib /visibility="private") or (srcattrib /visibility="protected")) forall trgtclass from target/classes forall d from rules/class_to_class where ((d/srcclass=srcclass) and (d/implclass=trgtclass)) make trgtattrib in trgtclass/attributes; trgtattrib/name=srcattrib/name; trgtattrib/visibility=srcattrib/visibility; trgtattrib/type=srcattrib/type; }
rule pub_attributes { forall srcclass from source/classes forall srcattrib from a/attributes where srcattrib/visibility="public" forall implclass from target/classes forall interclass from target/classes forall d from rules/class_to_class where ((d/srcclass=srcclass) and (d/implclass=implclass) and (d/interclass=interclass)) make trgtattrib in implclass/attributes; trgtattrib/name=srcattrib/name; trgtattrib/visibility="private"; trgtattrib/type=srcattrib/type; make getoperation in interclass/operations; getoperation/name="get_"+srcattrib/name; getoperation/type=srcattrib/type; make setoperation in interclass/operations; setoperation/name="set_"+srcattrib/name; make h in setoperation/parameters; h/type=srcattrib/type; }
В этих правилах использована трансформационная связь, образованная применением правила "class_to_class". Благодаря этой связи возможно определить класс-интерфейс и реализацию, порождённые заданным классом исходной модели. Следующее правило из неформального описания - "Публичные операции класса копируются в интерфейс, приватные - в класс реализации", оно описывается с помощью нескольких формальных правил.
rule methods1 { forall srcclass from source/classes forall srcoper from a/operations where srcoper/visibility="public" forall trgtclass from target/classes forall d from rules/class_to_class where ((d/srcclass=srcclass) and (d/interclass=trgtclass)) make trgtoper in trgtclass/operations; trgtoper/name=srcoper/name; trgtoper/type=srcoper/type; trgtoper/visibility=srcoper/visibility; }
rule methods1a { forall a from rules/methods1 forall b from a/srcoper/parameters make c in a/trgtoper/parameters; c/name=b/name; c/type=b/type; }
rule methods2 { forall srcclass from source/classes forall srcoper from a/operations where srcoper/visibility=("private" or "protected") forall trgtclass from target/classes forall d from rules/class_to_class where ((d/srcclass=srcclass) and (d/implclass=trgtclass)) make trgtoper in trgtclass/operations; trgtoper/name=srcoper/name; trgtoper/type=srcoper/type; trgtoper/visibility=srcoper/visibility; }
rule methods2a { forall a from rules/methods2 forall b from a/srcoper/parameters make c in a/trgtoper/parameters; c/name=b/name; c/type=b/type; }
Правила с именами methods1 и methods2 отображают публичные и приватные операции соответственно, а вспомогательные правила methods1a и methods2a нужны для копирования параметров операций. Далее формально зададим утверждение "Ассоциации "один к одному" и "многие к одному" преобразуются в атрибут - объектную ссылку", а так же "Связи-обобщения преобразуются в аналогичные связи-обобщения между классами-интерфейсами".
rule associations_single { forall srcclass from source/classes forall assoc from srcclass/associations where assoc/base/association_type="navigation" where ((assoc/otherEnd/cardinality="1") or (assoc/otherEnd/cardinality="0..1")) where assoc/otherEnd/association_end_type="navigable" forall d from rules/class_to_class where d/srcclass=srcclass forall e from rules/class_to_class where e/srcclass=assoc/otherEnd/class make objptr in d/implclass/attributes; objptr/type=e/interclass/name+"_ptr"; objptr/name=assoc/otherEnd/name; objptr/visibility="private"; }
rule association_generalization { forall srcclass from source/classes forall srcassoc from a/associations where srcassoc/base/association_type="generalization" where srcassoc/otherEnd/association_end_type="navigable" forall c from rules/class_to_class where c/srcclass=srcclass forall d from rules/class_to_class where d/srcclass=srcassoc/otherEnd/class make trgtassoc in target/associations; trgtassoc/association_type="generalization"; trgtassoc/stereotype=srcassoc/base/stereotype; trgassoc/name=srcassoc/base/name; make f in c/interclass/associations; f/name=srcassoc/name; f/cardinality=srcassoc/cardinality; f/association_end_type=srcassoc/association_end_type; include f in trgtassoc/ends; make g in d/interclass/associations; g/name=srcassoc/otherEnd/name; g/cardinality=srcassoc/otherEnd/cardinality; g/association_end_type=srcassoc/otherend/association_end_type; include g in trgtassoc/ends; f/otherend=g; g/otherend=f; }
И, наконец, последнее правило соответствует утверждению "Интерфейсы исходной модели и их связи копируются в генерируемую модель без создания классов-реализаций".
rule interface_mapping { forall a from rules/class_to_class where a/srcclass/stereotype="interface" delete a/implclass; } }
На самом деле данное правило просто удаляет лишние классы реализации, созданные первым правилом. Последняя фигурная скобка обозначает окончание блока трансформации. Итак, полученное описание трансформации формально определяет те преобразования модели, которые необходимы при переходе к PSM, основанной на CORBA и которые были заданы на естественном языке в начале статьи. В результате выполнения этого описания трансформации на какой-либо модели классов будет получена платформо-зависимая модель "target" и совокупность связей между этой моделью и исходной.
Пример простейшей трансформации
Для того чтобы лучше понять требования к языку описания трансформаций, рассмотрим преобразования, необходимые для перехода от платформо-независимой модели к модели, основанной на технологической платформе CORBA []. Пока будем описывать их неформально, на естественном языке. При этом будем стараться задавать эти преобразования в общем виде, не ориентируясь на какую-либо конкретную UML-модель.В результате таких преобразований из платформо-независимой UML модели произвольного вида мы получим модель, которая лучше соответствует объектной модели CORBA и более удобна для дальнейшей реализации, чем исходная модель. Разумеется, данное описание является только примером и не задаёт всех аспектов преобразования в CORBA-ориентированную модель, в частности не описано преобразование множественных связей и специальных видов ассоциаций. Описывать трансформацию удобно в виде правил -модификаций модели, которые следует выполнить для определённых элементов исходной модели или групп таких элементов. Формальный язык описания трансформации целесообразно наделить такой же структурой, чтобы облегчить его понимание человеком. Далее мы рассмотрим предлагаемый автором язык описания трансформации, основной структурной единицей которого является правило трансформации.
Принципиальная схема инструмента трансформации
Инструмент трансформации может быть самостоятельным программным продуктом или компонентом среды разработки. При разработке с использованием MDA он предназначен для частичной автоматизации генерации платформо-зависимой модели [].Входными данными для него являются:
Результатом работы инструмента являются:
С точки зрения инструмента трансформации нет принципиальной разницы между исходными и генерируемыми моделями: и те и другие в процессе трансформации могут подвергаться изменениям и дополнениям. Поэтому в дальнейшем будем говорить о совокупности моделей, подвергаемых трансформации, понимая под этим как исходные, так и генерируемые модели.
Разные подходы к трансформации UML-моделей
Существует несколько способов описания и выполнения трансформаций UML-моделей []. Простейший способ - это явное императивное описание процесса трансформации с использованием любого алгоритмического языка. При этом подходе в среду разработки на этапе её создания встраивается набор трансформаций, которые позднее могут быть задействованы пользователем. У этого подхода имеются существенные недостатки, которые делают его малопригодным для использования в средах разработки, поддерживающих MDA. Прежде всего, у пользователя отсутствует возможность добавлять новые описания трансформаций или изменять существующие; он вынужден использовать то, что сделано разработчиками инструмента. Кроме того, из-за отсутствия единого стандарта описания трансформаций разные среды разработки неминуемо будут выполнять трансформации по-разному даже для одной и той же технологической платформы, что может привести к возникновению случаев несовместимости и затруднит смену сред разработки: вместо зависимости от технологической платформы программист окажется в зависимости от выбранной им среды разработки. И наконец, подобный подход означает, что для каждой среды разработки придётся писать полный набор описаний трансформаций для всех популярных технологий, вместо того чтобы использовать стандартные описания трансформаций, созданные независимыми разработчиками.Другой подход - использование уже разработанных механизмов трансформаций и преобразований из других областей информатики. В частности, можно представить UML-модель в виде графа и использовать математический аппарат трансформации графов []. Главный недостаток такого подхода состоит в том, что в нем используется собственный понятийный аппарат, не имеющий отношения к UML-моделированию. Это значит, что от пользователей такой системы требуется знание не только UML-моделирования, но и теории графов и принципов их трансформации. Кроме того, поскольку UML-модель несёт семантическую нагрузку, отличную от формального графа, правила трансформации, сформулированные для графа, будут трудны для понимания с точки зрения UML-модели: для понимания трансформации придётся мысленно совершать переход от графа к породившей его UML-модели, а для внесения изменений в описание трансформации - от UML к графу.
Ещё один вариант заключается в использовании методик трансформации XML-документов и стандарта XMI []. XMI (XML Metadata Interchange) - это стандарт, позволяющий представить UML модель в виде XML документа. Он предназначен главным образом для хранения UML-данных, а так же любых других данных, метамодель которых задана с помощью MOF (Meta Object Facility) [] и обмена ими между различными инструментами и средами разработки. MOF - это стандарт описания метамоделей, с помощью которого в частности можно описать структуру и общий вид UML-модели. Для XML существует несколько хорошо развитых методик трансформации, в частности XSLT [] и XQuery []. Для трансформации UML-модели можно преобразовать её в XMI-представление, выполнить трансформацию средствами работы с XML, и затем преобразовать результат обратно в UML. Но XMI разрабатывался прежде всего как стандарт хранения и обмена UML-данными, он сложен для чтения и понимания пользователем. Также очень сложно понять функционирование трансформации, описывающей преобразование XML-документа, с точки зрения UML-модели, которой соответствует этот документ. Из-за того, что трансформация описывается в терминах XML, а не UML большая часть описания трансформации оказывается направленной на то, чтобы в результате получить XML-документ, соответствующий стандарту XMI, а не на собственно описание трансформации UML.
Язык моделирования UML считается универсальным, и, конечно же, он содержит средства описания трансформаций. В частности стандарт CWM (Common Warehouse Metamodel) позволяет описывать трансформации и преобразования []. Идея использовать UML для описания трансформаций UML-моделей подобно тому, как на UML описывается синтаксис UML, выглядит заманчиво, но трудно реализуема на практике. CWM даёт возможность только описывать сам факт того, что между определёнными элементами модели существует отображение, но не содержит развитых средств для задания трансформаций в общем виде (декларативно или императивно). Ещё один стандарт из семейства UML - QVT (Query, View, Transformation) - представляет значительно больший интерес с точки зрения его применения в MDA.
Но, к сожалению, на данный момент этот стандарт находится на ранних этапах разработки. Кроме того, вызывает опасение тот факт, что в рамках этого стандарта предполагается решить сразу несколько общих задач, и то, что QVT ориентирован прежде всего не на практическое применение, а на развитие концепции метаметамоделирования в рамках MOF (Meta Object Facility). Существует вероятность того, что из за подобной направленности на теорию и на решение задач в общем виде этот стандарт будет неудобен для использования на практике в задачах, специфичных для MDA, хотя ни в чём нельзя быть уверенным, пока стандарт ещё не принят хотя бы в ранней версии.
Представляет интерес разработка языка и средства трансформации моделей, предназначенного именно для применения в MDA. Возможно, такое средство трансформации окажется более удобным и эффективным в данной узкой области, чем адаптация более универсального стандарта. Ниже будет рассмотрен один из таких языков трансформации, предлагаемый автором.
Трансформация UML-моделей и ее применение в технологии MDA
Препринт Института Системного Программирования РАНТрансформационная связь и её использование в описании трансформации
Каждый раз, когда выполняется то или иное правило, помимо выполнения действий, описанных в секции генерации, создаётся специальная структура данных, называемая трансформационной связью. Имя этой структуры совпадает c именем правила, а полями данных являются локальные переменные, объявленные в описании правила (в операторах выборки и операторах создания). Значения этих полей данных совпадают со значениями соответствующих переменных, определённых в процессе выполнения правил.Трансформационные связи, образованные в процессе трансформации, объединяются в совокупность трансформационных связей. Она содержит информацию о ходе трансформации, применённых правилах и о том, как и почему был изменён или создан тот или иной элемент модели. Эту информацию после выполнения трансформации можно использовать для поддержания соответствия между моделями при их модификации.
Совокупность трансформационных связей может использоваться не только после завершения трансформации, но и в процессе ее выполнения. В операторах выборки, заданных в описании трансформации, вместо навигации по модели возможна навигация по трансформационным связям, порождённым ранее применёнными правилами. Для этого в операторе выборки используется навигационное выражение особой структуры. В отличие от обычного навигационного выражения, навигация по совокупности трансформационных связей начинается не с локальной переменной или имени модели, а с имени блока трансформации. После имени блока следует имя правила и имя локальной переменной из этого правила. Так как любое правило в процессе трансформации может быть применено несколько раз, и, соответственно, в совокупности связей может присутствовать несколько экземпляров соответствующей трансформационной связи, кардинальность подобного навигационного выражения всегда больше единицы.
Вместо имени блока можно использовать ключевое слово "rules", которое эквивалентно имени текущего блока. Следует отметить, что, поскольку блоки трансформации исполняются последовательно, в каждом блоке возможно использование информации о трансформационных связях данного блока и блоков, стоящих в описании трансформации перед ним. Блоки, располагающиеся в описании трансформации после текущего, ещё не выполнены и не имеют трансформационных связей.
Использование трансформационных связей в описании трансформации позволяет создавать зависимости между применением правил и более точно определять, в каком случае должно быть применено то или иное правило. Это, в свою очередь, позволяет описывать нетривиальные преобразования моделей в компактной и простой для понимания форме.
и активно используются множество стандартов,
На данный момент разработаны и активно используются множество стандартов, middleware-технологий и платформ (CORBA, DCOM, Dot-Net, WebServices, JAVA-технологии и т.д.), и в будущем их количество будет расти. Попытки создать универсальную платформу, которая бы заменила все существующие, привели только к увеличению количества используемых технологий. Всё более важными становятся вопросы выбора технологии для конкретного проекта, осуществления взаимодействия и интеграции разнородных систем и переносе систем на новую технологическую платформу, когда используемая платформа устаревает и уже не может удовлетворить потребности заказчика. Решение может лежать в использовании новой, более совершенной методики разработки ПО.Model Driven Architecture (MDA) - новый подход к разработке ПО, предложенный консорциумом OMG []. Архитектура MDA может предоставить ряд преимуществ по сравнению с существующими методиками: упрощение разработки многоплатформенных систем, простота смены технологической платформы, повышение скорости разработки и качества разрабатываемых программ и многое другое. Однако всё это станет возможным только тогда, когда среды разработки будут поддерживать новую технологию и полностью реализовывать её потенциал. К сожалению, на данный момент большинство коммерческих продуктов, для которых заявлена поддержка MDA, реально не предоставляют соответствующих инструментов; в связи с этим эффективное применение MDA для решения реальных задач затруднено.
В основе MDA лежат понятия платформо-независимой и платформо-зависимой моделей (platform-independent and platform-specific models, PIMs and PSMs) []. В процессе разработки системы сначала создаётся PIM - модель, содержащая бизнес-логику системы без конкретных деталей её реализации, относящихся к какой либо технологической платформе. Принципиальным является именно тот факт, что на этапе создания этой модели не принимается никаких решений по поводу её реализации, разрабатываемый программный продукт не привязывается к технологиям.
Это означает, что описание трансформации должно быть понятно не только создавшему его программисту, но и тому, кто планирует его использовать. Язык описания трансформации должен быть понятным для человека и иметь легко читаемую нотацию. Также желательно, чтобы язык допускал эффективное структурирование описания трансформации, то есть его разбиение на слабо зависимые части. Без подобного структурирования будет очень сложно изменять описание трансформации большого объёма, так как для оценки результата изменения придётся проверять всё описание трансформации, а не только его структурно независимую часть.
Выполнение трансформации
Теперь, когда определён синтаксис языка трансформации, опишем процедуру выполнения трансформации. Инструмент трансформации, получив в качестве входных данных исходную модель (или несколько моделей) и описание трансформации, а также имея информацию об используемой метамодели, может выполнить заданную трансформацию. При этом, в зависимости от описания трансформации, возможно как изменение исходной модели, так и создание новой.Выполнение трансформации заключается в последовательном применении блоков трансформации. Выполнение блока состоит в нахождении в этом блоке правила, которое может быть применено в данный момент, и применении этого правила.
Применимость правила определяется по его секции выборки.
Каждый оператор выборки объявляет новую переменную и с помощью навигационного выражения определяет множество возможных значений этой переменной на данной модели. Секция выборки может также содержать уточняющие условия; конъюнкцию всех таких условий назовём обобщённым уточняющим условием. Множество возможных выборок - это декартово произведение множеств значений переменных выборки, ограниченное уточняющим условием, то есть множество всевозможных наборов значений переменных, для которых обобщённое уточняющее условие истинно. Выборкой назовём произвольный элемент этого множества. Правило применимо, если для текущего состояния трансформируемой модели (совокупности моделей) существует такая выборка, для которой это правило не было применено ранее. Применение правила к выборке состоит в последовательном выполнении всех операторов секции генерации. При этом значениями переменных выборки являются соответствующие компоненты выборки, для которой применяется правило. Каждый раз, когда применяется правило, создаётся новый экземпляр трансформационной связи, порождённой этим правилом. (О том, что такое трансформационная связь, будет сказано позже.)
Если правило применимо более чем к одной выборке, то для выполнения случайным образом выбирается одна из них (вообще говоря случайным образом, в зависимости от реализации).
Далее, в зависимости от порядка применения правил в блоке, правило может быть применено к другим выборкам, или может начаться выполнение другого правила.
Порядок применения правил определяется заданной при создании описания трансформации последовательностью применения правил в блоке. Она задаётся с помощью параметра
Если ни одно правило из блока трансформации больше не может быть применено, или если достигнут конец описания блока при линейном ("linear") порядке выполнения, то этот блок трансформации считается завершённым и начинает выполняться следующий.Трансформация считается завершенной, когда выполнен последний блок.
Следует отметить, что для произвольного описания трансформации не гарантируется завершение процесса трансформации для любой модели; при использовании правил с операторами создания элемента модели возможны бесконечные циклы. Это необходимо учитывать как при создании описания трансформации, так и при его использовании.
Технология MDA может оказаться новой
Технология MDA может оказаться новой ступенью эволюции средств и методик разработки программных систем. Но это станет возможно только в том случае, если появятся инструменты разработки, специально предназначенные для этой технологии и максимально использующие её потенциал. Существующие на данный момент инструменты являются в основном адаптациями и расширениями старых разработок, они только поддерживают подход MDA, но не предназначены для него. Таких инструментов недостаточно, чтобы реализовать среду разработки ПО нового поколения. Поэтому на данный момент ведётся множество разработок инструментария для MDA.Одна из важнейших и самых сложных возникающих при этом задач состоит в автоматизации трансформации моделей. Ранее этой задаче не уделялось должного внимания, так как область применения возможных результатов была ограничена. Существующие методики и заимствования из других областей информатики оказываются малоэффективными и неудобными для решения практически задач, поставленных технологией MDA. Поэтому актуальна задача разработки методики описания и выполнения трансформации моделей с учётом особенностей её применения для MDA.
В данной работе предложен язык описания трансформации, предназначенный, прежде всего, для применения к моделям UML (впрочем, благодаря поддержке различных метамоделей, он может быть использован и для трансформации других моделей). При разработке языка учитывались особенности его применения в технологии MDA. Особое внимание было уделено понятности языка для человека и хорошей структурированности описаний трансформации на этом языке.
Теория для победителя
«Экспресс-Электроника»Западная практика ведения проектов и многолетний отечественный опыт разработки систем оборонного комплекса показывают, что использование методик планирования и контроля за ходом работ не только ускоряет выполнение проекта, но и значительно уменьшает затраты на его реализацию. Пришло ли в России время для существующих методик оптимального ведения проектов? Похоже, ответ на этот вопрос очевиден.
Сразу оговоримся, нижеизложенная информация является лишь азами современного проектного менеджмента и не претендует на абсолютную полноту. Данный материал интересен в первую очередь тем, кто так или иначе связан с выполнением работ в рамках определенных проектов, но, не являясь специалистом в данной области, стремится оптимизировать свои трудозатраты и трудозатраты своего коллектива. Понимание этого позволит избежать множества ошибок.
Как правило, под термином «проект» подразумевается ограниченный во времени организационный стратегический план для создания уникального продукта или услуги, который может выполняться как одним человеком, так и коллективом. Данное определение проекта ничего не говорит о длительности выполнения работ – оно может варьироваться в самых широких пределах. Неизменным остается лишь конечная цель проекта – получение прибыли или некоего стратегического результата, а также инструмент оптимизации хода выполнения работ – Project Management. Последний подразумевает использование определенных знаний, умений, средств и методов для достижения поставленных целей.
Приведенное определение, позаимствованное из руководства по основам управления проектами (A Guide to the Project Management Body of Knowledge), созданного Project Management Institute, к сожалению, не отражает тех трудностей, с которыми приходится сталкиваться большинству компаний при реализации даже относительно несложных проектов. На наш взгляд, все они связаны с отсутствием у исполнителей современных знаний в области оптимального ведения проекта, а также неумения создать или организовать по-настоящему действенную функциональную команду.
И если первая проблема решается достаточно просто – обучением имеющегося персонала или наймом квалифицированного, то решение второй куда сложнее. Дело в том, что принцип формирования команды, принятый в нашем обществе, не правилен, и преодоление стереотипов, связанных с ним, вызывает непонимание у руководства большинства компаний. Иногда дело доходит до саботажа в рядах менеджеров верхнего уровня (не являющихся владельцами компании). Не стоит забывать и об особенностях национального менталитета. К слову, они почему-то полностью нивелируют преимущества использования средств ускоренной разработки программных продуктов, зарекомендовавших себя с наилучшей стороны в западных компаниях.
Предлагаемый материал, надеемся, поможет читателю не только уяснить основы проектного менеджмента, но и понять принципы создания команды.
После определения целей проекта начинается его разработка. Согласно теории проектного менеджмента первый этап при выполнении проекта – составление списка необходимых работ. Обычно весь список оформляют в виде таблицы или блок-схемы, однако на данном этапе усердствовать не стоит, так как излишняя тщательность при выборе объектов оптимизации может привести к управлению проектом на микроуровне, и тем самым существенно его усложнить. С другой стороны, выбирать задачи слишком масштабные тоже нежелательно, поскольку это ведет к снижению эффективности применяемых методов оптимизации. Как правило, детализация работ на уровне нескольких дней является оптимальной, впрочем, временной квант оптимизации может динамически изменяться, при изменении уровня насыщенности событий.
Одним из первых методов оптимизации хода выполнения работ, не потерявшим своей эффективности и по сей день, является методика диаграмм Гантта. Она был разработана Генри Ганттом для отслеживания хода строительства больших трансконтинентальных океанских лайнеров. Идея Гантта состояла в том, что главным ресурсом планирования является время, а основой принятия управленческих решений — сравнение запланированного и фактического состояния работ.
На диаграммах Гантта по горизонтали обычно показывают интервалы времени, а по вертикали — работы, операции, оборудование. Горизонтальные отрезки отражают длительность выполнения работ. Выбрав по горизонтальной оси текущий момент времени и получив оперативную информацию о ходе производства, можно сопоставить фактическое состояние дел и планировавшееся. Все современные системы управления проектами и планирования предлагают представление графиков работ в виде диаграмм Гантта (рис. 1).
В то же время диаграммы Гантта имеют ряд недостатков. Например, с их помощью довольно сложно планировать многовариантные взаимосвязанные цепочки работ (в строительных, военных, государственных проектах и на производстве). Для таких задач в военном ведомстве США в 1950-е годы были предложены методы сетевого планирования, или методы выбора «критического пути». Кроме того, диаграммы Гантта удобно применять только для одного критического ресурса — времени. При необходимости учитывать еще несколько ресурсов, например технологическую оснастку, диаграммы Гантта надо воспринимать как объемные, приобретающие ряд измерений по числу учитываемых ресурсов. Это имеет смысл для визуальной интерпретации планов, но затрудняет их анализ. Для управления ходом проекта используются более мощные средства – CPM, PERT и некоторые другие. Ниже дается их описание.
В 1956 году М. Уолкер из фирмы DuPont, исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д. Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд». Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы DuPont. В результате был создан рациональный метод описания проекта с использованием ЭВМ. Первоначально он получил название метода Уолкера-Келли, а позже переименован в метод критического пути (Critical Path Method — CPM). Данный метод имеет три достоинства — позволяет получить графическое представление проекта, определяет ориентировочное время, требуемое для его выполнения, и показывает, какие действия критичны, а какие не столь важны для соблюдения всего графика работ.
При использовании СРМ действия, составляющие проект, моделируются как сеть, разбитая на узлы завершения этапов работ. События, которые находятся между этими условными узлами, не выделяются и на диаграмме показаны как объединительные дуги. Построение самой сетевой диаграммы осуществляют на основании данных о перечне и последовательности действий. Обычно начинают с узлов-действий, соединяя их впоследствии дугами-событиями. Над дугами указывается число, отражающее длительность выполнения проекта. Именно выставление длительности хода выполнения проекта, которая может быть вычислена путем суммирования самой длинной (в хронологическом отношении) ветви, позволяет оперировать оригинальной величиной — критическим путем (максимальная длительность выполнения проекта).
Суть метода в том, что выделяются работы, чья продолжительность не может меняться без особой необходимости, и работы, длительность которых варьируют без влияния на время выполнения всего проекта. В свою очередь, возможности оптимизации, заложенные в методику СРМ, заключаются в ускорении хода выполнения работ, составляющих критический путь методом распараллеливания усилий или простого сокращения времени выполнения проекта. В итоге, если менеджеру удается сократить сроки выполнения работ, составляющих критический путь, ускоряется весь процесс выполнения проекта.
Из-за того, что сроки выполнения отдельных действий по тем или иным причинам могут динамически изменяться в ходе осуществления проекта, критический путь постоянно рекомендуется пересчитывать, тем самым следить за выполнением проекта.
Методика, предлагаемая СРМ, в настоящее время широко распространена, однако она имеет свои недостатки. Оптимизации методом СРМ поддаются только сравнительно легко понятные проекты, в которых не трудно спрогнозировать время выполнения действия. Поэтому при разработке или конструировании различных систем (когда одна из интеллектуальных задач может быть не решаема достаточно долгие время) СРМ применим лишь условно.
Для задач, связанных с интеллектуальным трудом и другими вопросами, в которых стоимость оптимизируемого параметра не известна наверняка, используется метод PERT-анализа (Program Evaluation Review Technique).
Он был разработан сотрудниками Военно-морского флота США в 1957 году для обеспечения создания ракеты «Поларис». Применяя PERT-анализ, они попытались сымитировать график выполнения работ по созданию ракеты путем построения логической сети взаимозависимых последовательных событий. На начальной стадии PERT-представление было сфокусировано на контроле временных характеристик графика и прогнозировании вероятности успешного завершения программы. Но прежде чем PERT-представление было окончательно принято руководителями программ в промышленности, Военно-воздушные силы США внесли дополнение в методику, добавив к логической сети функцию ресурсной оценки. Таким образом, в 1962 году появилась PERT/Cost-методика (PERT-анализ с целью стоимостного прогнозирования), в то время как первоначально PERT-анализ был известен под названием PERT/Time (PERT-анализ для определения времени реализации проекта).
Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также какова вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить на два года раньше запланированного срока. Благодаря такому впечатляющему началу, данный метод управления вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя зарекомендовала при координации работ, выполняемых различными подрядчиками в рамках крупных проектов по разработке новых видов вооружения.
Типичный период времени, применяемый в PERT — одна неделя, но при необходимости может использоваться и любой другой промежуток. Для каждого действия указывают три оценки его длительности — оптимистическая (О), наиболее вероятная (В) и пессимистическая (П). Ожидаемое время продолжительности каждого действия может быть приблизительно оценено как (О + 4В + П)/6. Это расчетное время и указывается на сетевом графике.
Критический путь, как и в CPM, определяет полное календарное время, требуемое для проекта, и имеет тот же смысл.
Расчетная дата его окончания наиболее вероятна, и при существенном количестве действий, составляющих критический путь проекта, это соотношение оказывается близким к реальному.
На практике метод позволяет оценить предполагаемое время окончания проекта, вероятность его завершения к конкретной дате и конкретизировать действия, наиболее неопределенные в смысле своего выполнения.
Позже, для получения еще более точных оценок, стали использовать некоторые специальные математические методы, например «рулетка случайных чисел Монте-Карло» или методы статистического моделирования. Хотя первые методики используются и по сей день. Так, работы Гарри Гантта легли в основу научных дисциплин, возникших в середине ХХ века, — промышленной инженерии, занимающейся управлением и организацией производства, а также исследования операций. С исследованием операций связаны работы по применению математических методов формализации человеческой деятельности, в том числе в производстве и планировании. Разработаны многие статистические и оптимизационные алгоритмы планирования, используемые в современных системах. Например, в SAP R/3 для прогнозирования потребностей в продукции (функция Forecast) с учетом информации о фактическом спросе за предыдущие периоды, применяются статистические и эвристические методы (расчеты сезонных колебаний спроса, расчеты по трендам). Еще один пример — методы оперативного планирования (функция Scheduling), подсистемы планирования производства SAP R/3, в которых использованы алгоритмы расчета даты выполнения заказа, сокращения длительности производственного цикла, минимизации переналадок оборудования и прочие.
Управление проектами - статьи
Групповое авторство
Одной из проблем программирования является недоступность по той или иной причине разработчика определенного фрагмента кода, в результате чего его поддержка становится сложной или невозможной. Многие заказчики и группы попадали и попадают в зависимость от "гуру" — и всегда с негативными последствиями.В обстановке, когда "все делают все", идеи свободно высказываются и распространяются в группе. Более того, каждый может вносить изменения в любую строку кода. Это сложно понять с первого раза, отсутствие одного "супервизора" может сбить с толку — но это работает. По крайней мере, вполне распространена ситуация, когда весь коллектив выполняет одно неверное указание системного архитектора. Зависимость группы от одного, даже высококвалифицированного человека — весьма опасный путь. Участие в обсуждении архитектуры всех сотрудников не только повышает самооценку, улучшает квалификацию, но и приводит к значительно лучшим результатам разработки.
Коллектив, оказывается, способен самостоятельно выработать единое мнение и распределить авторитет и ответственность, пользуясь естественными механизмами человеческой психики. И поскольку каждый принимает участие в обсуждении архитектурных и организационных вопросов, то вполне логично, что и собственность на полученный продукт будет коллективной.
Так, начав с технических и организационных проблем, мы дошли до вопросов самореализации, развития личности и новой социальной модели. Как видите, Экстремальное Программирование является весьма исчерпывающей системой ценностей, и вы вполне можете применить ее к своей специфике.
Куда двигаться дальше? Первое — ознакомьтесь с сайтом, материалы которого положены в основу этой статьи. Прочитайте также замечательную книгу "Быстрая разработка программ: принципы, примеры, практика" Роберта Мартина. Она снабжена многими примерами — однако не стоит воспринимать ее как справочник по Java. За техническими деталями кроются эфемерные флюиды хода мысли экстремального программиста. Даже самые опытные из вас смогут почерпнуть там новые идеи — и, я думаю, не согласиться с этими идеями будет сложно, поскольку они привнесены в практику из практики и теорией стали только на время.
Идеальный день разработчика и фактор загрузки
Важным первичным инструментом при расчетах является идеальный день разработчика — то есть день, когда разработчик полностью концентрируется на решении проблем проекта. Это тот срок, в который разработчик может выполнить заданный объем работы при максимальной загрузке. Но было бы большой ошибкой использовать разработчика в этом режиме без крайней необходимости. Ритм работы экстремального программирования отнюдь не экстремален — и даже не должен подходить к отметке "горячо", по крайней мере в начале разработки.Фактор загрузки — это отношение реальных календарных рабочих дней к идеальным дням разработчика; он характеризует "температуру" разработки. Нормальными считаются факторы от двух до пяти, причем чем больший фактор вы можете позволить — тем больший запас адреналина есть в запасе у вашей команды. Опытные менеджеры используют "три" как стартовое значение, но для новых неосвоенных технологий следует использовать четыре или пять.
Другим временным фактором является скорость проекта.
История пользователей
История пользователей — это аналог Use Case, но имеющий несколько другой оттенок. История пользователя — это компактный документ (предположительно около трех предложений) составленный пользователем и описывающий одну отдельную операцию для данного пользователя в духе "я захожу в программу и...". В отличие от глобальных Use Case, где рассматриваются целые классы пользователей, историю пользователя легко определить, спланировать на конкретный цикл и реализовать в определенный срок. Скажем, "ввод накладной" значительно более ясен и детерминирован, чем "обработка входных документов".Истории пользователей до последнего момента не принимают детального вида, в духе позднего принятия решений. Реализация истории должна быть ограничена по срокам от одной до трех недель разработки — в противном случае такая история должна быть разбита на более мелкие. Главное — избежать ситуации, когда нечто достаточно долго делается без обратной связи, поскольку все сделанное потенциально является предметом критики и переработки.
Считается, что 80?20 историй пользователей являются идеальным числом для составления плана нового релиза.
Экстремальное программирование и быстрая разработка ПО
Арсений Чеботарев"Компьютеры + Программы",
Экстремальное программирование — или, сокращенно, XP — является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов и призвано вернуть в среду разработчиков дух творчества.
Любая идея, доведенная до абсурда, вырождается в собственную противоположность. Именно такая ситуация складывается в североамериканской промышленности ПО с RAD-средствами разработки. В некоторый момент инструменты, предназначенные для быстрой разработки приложений, стали вытеснять в умах менеджеров все остальное, в том числе разработчиков, заказчиков и сам проект. Неоправданное, гипертрофированное внимание к Процессу в ущерб другим факторам разработки породило массу формальных процедур — но качество полученных продуктов и количество успешных проектов оказалось разочаровывающим.
Противостоять нажиму формализма в работе программистов призвана инициатива группы разработчиков, объединившихся под лозунгом Экстремального Программирования, или XP. И хотя наши разработчики, в основном, еще далеки от проблем своих заокеанских коллег, тем не менее, многие методы с успехом могут быть использованы в нашей практике.
Рассмотрим основные принципы экстремального программирования — с небольшими сокращениями повторений, характерных для американского дефинитивного стиля и с некоторыми дополнениями. Приведенная терминология не всегда соответствует оригинальной и является компиляцией из нескольких источников — однако она передает основные положения и дух экстремального программирования в мере, достаточной для практического использования.
В основе экстремального программирования лежит несколько совершенно конкретных, часто выраженных в численном виде принципов, определяющих, что, когда и как должно делаться. Не воспринимая эти числа как догму, нужно, тем не менее, иметь в виду, что они появились как результат анализа многочисленных успешных и неуспешных проектов, так что для внесения своих поправок, как минимум, должны быть веские основания.
Экстремальный цикл
В основе экстремального программирования — очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели. К концу каждого цикла вы должны иметь полностью рабочий, функциональный и протестированный релиз приложения. Эти циклы должны быть повторяющимися и бесперебойными на протяжении всего проекта.Предпосылкой для такого режима работы является многократно проверенный факт, что требования редко бывают полными, своевременными и корректными. Иными словами, как бы хорошо вы ни планировали свое приложение, имейте в виду, что его 100% придется переделывать. Более того, его, возможно, придется переделывать даже на завершающей стадии. Не откладывайте переделки на конец работы, делайте их регулярно.
Как следствие постоянно изменяющихся требований следует другой принцип — позднее принятие решений.
Кодирование в глубину
Кодирование в глубину (по аналогии с названием метода обхода бинарного дерева) обозначает, что в течение цикла должна быть полностью разработана и протестирована отдельная функциональность и проигнорированы соседние с ней области. Подразумевается, что готовая часть будет включать прикладную логику, пользовательский интерфейс, документацию и набор тестовых заданий для демонстрации работоспособности. Те, кто писали документацию по давно завершенной системе, поймут, насколько это важно.Легко также впасть в искушение — и вместо насущных и актуальных задач перейти к более отдаленным, но и более легким или удобным частям приложения. Это не правильно — таким образом нарушается принцип работоспособности приложения к концу цикла.
Из готовых, законченных функциональностей складываются истории пользователя, и именно "закрытие" отдельного класса проблем пользователя в самый быстрый срок должно стать основной целью. В противном случае может сложиться ситуация, когда на 90% готовое приложение нельзя показать заказчикам и пользователям, поскольку оно до конца не выполняет ни одной функции.
Помимо концентрации на одной задаче в каждом конкретном цикле важное значение имеют также скорость проекта и фактор загрузки.
План итераций
План итераций ограничивает количество заданий, которые будут выполняться в данной итерации. Выборка производится на основании текущей скорости проекта, то есть на основе оценки идеального срока, умноженного на фактор загрузки. Истории пользователей получают приоритеты внутри цикла и трансформируются в задачи разработки, каждая из которых выполняется в течении одного-трех идеальных рабочих дней.Если в результате детализации ожидаемое время разработки превосходит время цикла, то некоторые истории переносятся на более поздний срок. Этот эффект снежного кома — вполне обычная практика, поскольку детальные задачи часто распадаются на отдельные части, когда сумма времени для каждой превосходит время для целого.
Не стоит искать виновных в этой ситуации. Такое свойство планирования, как недооценка деталей, это и есть та причина, по которой не производится предварительное планирование. Детальный предварительный план всегда будет пересмотрен в будущем, и поэтому изначально и гарантированно нереален. Планирование производится только на основании предыдущего цикла, с коррекцией скорости проекта и с учетом перенесенных заданий.
Параллельно с выборкой историй пользователей план предусматривает создание набора тестов приемки, которые будут сопровождать код в процессе всех последующих сборок.
План релиза
План релиза, утверждаемый на специальном совещании, дает точный ответ на вопрос, какие именно истории пользователей будут реализованы в данном релизе. Преимущество отдается небольшим инкрементальным релизам. Выбранные к реализации истории транслируются в конкретные задания программирования, такие как создание формы ввода или процедуры запроса к БД. Обычно после нескольких итераций оценки необходимых операций осуществляются очень точно. Как только план выполнения итераций выходит из-под контроля и, по крайней мере, после каждых нескольких удачных итераций повторно собираются совещания по поводу нового плана релиза.Выбранные истории являются основой для планов итераций.
Позднее принятие решений
"Поздний анализ" означает "принимайте конкретные решения только тогда, когда это нужно". В большинстве случаев принятые на начальной стадии решения относительно кода приходилось отменять под влиянием новых требований или других обстоятельств. Не принимайте никаких решений по поводу кода, которого у вас еще нет,— тогда вы развяжете себе руки при реализации текущих задач. Как правило, многое из запланированного оказывается вообще не востребованным. Поэтому планировать кодирование полезно перед началом каждого цикла, но не "раз и навсегда".С другой стороны, любая начатая часть работы, любая подсистема должна быть закончена прежде, чем начнется работа над другими секциями кода. Такая методика известна как кодирование в глубину.
Представители заказчиков
Представители заказчиков являются важнейшим звеном успешной разработки по технологии XP. Представители должны не просто контактировать, но буквально физически присутствовать в непосредственной близости и работать в команде разработчиков. Любая проблема должна быть обнаружена на самом раннем этапе, любые пожелания или вопросы должны решаться в реальном времени. Представители заказчика являются источником историй пользователей и тестовых наборов данных, они принимают участие в планировании плана релизов. Кроме того, открытый процесс позволяет инспектировать спорные участки кода в любой момент времени, создавая полностью прозрачную атмосферу между разработчиками и заказчиками.Хотя это не очевидно, но практически происходит экономия времени заказчика, который все время находится в курсе дел — дополнительно время экономится на детальных спецификациях в начале работы, поскольку любой аспект можно выяснить в процессе работы. Впоследствии не придется инструктировать персонал заказчика, поскольку заказчик уже располагает высококачественными специалистами по данному продукту.
При этом многие документы-посредники становятся ненужными, поскольку многое решается устно, без вовлечения технических и бюрократических механизмов. Значение имеют только конечные результаты работы — но не промежуточные решения и дискуссии, так что нет необходимости документировать все возможные ходы мысли и альтернативы.
Помимо тесного взаимодействия с заказчиками, особого внимания требует и структура группы разработчиков.
Простота и эффективность используемого кода
Часто предоставленный сам себе разработчик решает использовать новую технологию или инструмент, который, по его мнению, обещает дополнительную производительность или выгоду. На самом деле это редко оправдывается, а в атмосфере, когда ваш код завтра будет прочитан и использован партнерами по команде, у вас просто не остается возможностей для экспериментов за чужой счет. Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды. Например, любой разработчик должен уметь программно обрабатывать текстовые файлы, многие знают C++, Java, Perl, SQL и подобные инструменты. Использование редких технологий и инструментов, например сложных, особенно заказных RAD и т.п., может вызвать не только проблемы понимания, но и впоследствии проблемы поддержки. Учитывайте, что освоение сложного инструмента может занять больше времени, чем вся разработка проекта.К сожалению, программный код, созданный по самым лучшим образцам, со временем имеет тенденцию к деградации под воздействием изменений и исправлений. Поэтому нужно взять за правило производить постоянный и бескорыстный рефракторинг.
Рефракторинг
Это наведение порядка в коде, переработка отдельных файлов и их групп с целью наведения порядка, удаления максимального количества ненужных фрагментов, объединения классов на основе схожей функциональности, коррекция комментариев, осмысленное переименование объектов и так далее. Рефракторинг должен стать лучшим отдыхом программиста в промежутке между решением сложных проблем. Не следует также забывать и о постоянном тестировании модулей.Скорость проекта
Скорость проекта — это скорость реализации частей программы, определенных для заданного цикла. В качестве основных ориентиров прогресса в разработке выступают реализации историй пользователей.Структура группы разработчиков
Для быстрой разработки применяется особая методология организации работы, основанная на теории психологии малых групп. Основной принцип: все разработчики должны быть доступны друг для друга, как организационно, так и физически,— преимущественно желательно располагать группу в одной большой комнате. Структура в группе — одноранговая, то есть существует только профессиональный авторитет, но не административное деление. Доказано, что самая продуктивная обстановка — умеренный шум большой рабочей комнаты, тишина или музыкальное сопровождение дают худшие результаты.Все производственные вопросы решаются в самой группе, включая используемые методы, инструменты или технологии — эти параметры решения задачи не могут быть навязаны извне: как правило, профессионалы в коллективе решают поставленные задачи оптимально. Крое того, каждый разработчик самостоятельно выбирает подходящие задания, в зависимости от потребности группы и собственных способностей.
Одной из самых качественных технологий программирования на сегодня является парная технология, когда один программист вводит код, а другой при этом смотрит на экран и по ходу корректирует его или задает вопросы относительно реализации. Такая подстрочная критика кода, как показывает практика, в несколько раз повышает качество начального кода, сводя возможность ошибок в начальном коде к минимуму.
Второй принцип — принцип замены партнеров — означает, что пары меняют партнеров один-два раза в течение дня, причем группы работают над различными частями системы. Кажется, что такая метода не позволяет сконцентрироваться на отдельной области — однако практика опровергает это. Концентрация на одной области приводит к укоренению стиля, не всегда оптимального, а отсутствие критики кода может привести "хакера" к тяжело обнаружимым ошибкам. Постоянная смена области приложения, напротив, повышает не только квалификацию в результате обмена опытом, но также и мотивацию повышения собственного мастерства.
В обстановке групповой работы важное значение получает максимальная простота и эффективность используемого кода.
Тестирование модулей
В отличие от тестов приемки, создаваемых заказчиками и отражающих истории пользователей, тестирование модулей — это сугубо технологическая проверка корректности классов на основании готовой или созданной специально для этих целей автоматизированной системы. Настоящая методика тестирования предусматривает создание сначала тестов и только после — самих классов, что исключает "подгонку" тестов к работающим прототипам и уклонение от острых ситуаций.Классы-тесты должны быть неотъемлемой частью библиотеки или пакета, их отсутствие вызывает сомнения в работоспособности класса. Создаваемый для приложения код должен проходить все более сложные тесты — и таким образом изначально создаваться для некоторого реального окружения. Игнорирование этого принципа может усложнить тестирование впоследствии, когда уже трудно восстановить работу многих модулей.
Тесты служат четырем целям: во-первых, они, собственно, помогают протестировать функциональность; во-вторых, это естественная форма проектной документации, то есть на вопрос "что делает этот класс" можно ответить "пытается пройти набор функциональных тестов". Третье: тесты — это готовая часть описательной документации, сопровождающей класс после разработки, всегда отвечающая на вопрос "как использовать данный класс". И, наконец, это средство групповой разработки.
Выгода от написания модульных тестов хорошо проявляется в отношении группового авторства: фиксированный набор тестов, созданный модератором класса, всегда может гарантировать, что последующие изменения, произведенные другими членами команды, по-прежнему позволяют классу удовлетворять тестам.
Тесты приемки
Тесты приемки создаются на основании историй пользователей и желательно до, а не после создания программных модулей. Без прохождения тестов история не может считаться реализованной ни в какой мере. Фактически, тесты приемки — это те же истории пользователей, но умноженные на возможные ошибки ввода и другие варианты поведения системы, то есть рассматриваются различные варианты конкретной истории. Естественно, что для многократного тестирования необходимо создать автоматические процедуры, вводящие тестовые наборы и ведущие журналы тестов.Тестирование — не приложение к приложению, а, скорее, наоборот. Часто контроль качества (QA) и составление тестов возлагается на отдельную группу, в состав которой входят представители заказчиков.
Управление проектами - статьи
Быстрый выпуск версий
Ни один аналитик, даже самый квалифицированный, не поймет потребности заказчика лучше, чем он сам… попользовавшись готовым продуктом некоторое время. Эта ценная особенность человеческой природы легла в основу новой методики, которая формулируется следующим образом: дайте заказчику определиться со своими потребностями раньше, выпустив версию быстрее.Впрочем, у этого подхода есть определенные ограничения: во-первых, пользователи не всегда готовы к быстрым переменам, а во-вторых, выпускаемый продукт должен быть всецело протестирован. Если с первой проблемой справиться проблематично, то вторая успешно решается применением автоматизированных тестов, модульных или приемочных.
Игра в планирование
Наш мир слишком изменчив и непредсказуем, чтобы полагаться на постоянство ситуации. То же происходит и при разработке программного обеспечения: о редкой системе можно сказать, что ее окончательный вид был заранее известен в деталях еще в самом начале разработки. Обычно у заказчика аппетит приходит во время еды: ему постоянно хочется что-то поменять, что-то улучшить, а что-то вообще выбросить из системы. Это и есть изменчивость требований, которую все так боятся. К счастью, человеку дано умение прогнозировать возможные варианты и, таким образом, держать ситуацию под контролем.В экстремальном программировании планирование - неотъемлемая часть разработки и то, что планы могут поменяться, учитывается с самого начала. Той точкой опоры, методикой, которая позволяет прогнозировать ситуацию и безболезненно мириться с изменениями, является игра в планирование. В ходе такой игры можно быстро собрать известные требования к системе, оценить и запланировать их разработку в соответствии с приоритетностью.
Как и любая другая игра, планирование имеет своих участников и свою цель. Ключевой фигурой является, конечно же, заказчик. Именно он сообщает о необходимости той или иной функциональности. Программисты же дают ориентировочную оценку каждой функциональности. Прелесть игры в планирование заключается в единстве цели и солидарности разработчика и заказчика: в случае победы побеждают все, в случае поражения все проигрывают. Но при этом каждый участник идет к победе своей дорогой: заказчик выбирает наиболее важные задачи в соответствии с бюджетом, а программист оценивает задачи в соответствии со своими возможностями по их реализации.
Экстремальное программирование предполагает, что разработчики в состоянии сами решить, за какой промежуток времени они справятся со своими задачами и кто из них охотнее бы решил одну задачу, а кто другую.
В идеальной ситуации игра в планирование с привлечением заказчика и программиста должна проводиться каждые 3-6 недель, до начала следующей итерации разработки. Это позволяет довольно просто внести коррективы в соответствии с успехами и неудачами предыдущей итерации.
Экстремальное программирование: новые возможности
,Экстремальное программирование - молодая, но быстро развивающаяся методология разработки программного обеспечения. Она получила признание и широкое распространение благодаря ориентации на обычных людей, максимальному упрощению бюрократических процедур и обилию качественной литературы
Что же такое eXtreme Programming: набор отдельных правил и методик или полноценная методология? Давайте попробуем XP "на зуб", не отрывая глаз от страниц журнала.
С чего начинается экстремальное программирование? С понимания того, что типичное положение отечественного разработчика программного обеспечения обязывает максимально снижать стоимость разработки. А для этого необходимо интенсивно сотрудничать с заказчиком, понимать его интересы и, в конце концов, сделать именно то, чего он хочет: не больше и не меньше.
В основе экстремального программирования лежат не конкретные методики, как принято считать, а лишь четыре базовых принципа: общение, простота, обратная связь и храбрость. Именно с них необходимо начинать.
Экстремальное программирование предлагает готовое решение: делайте все максимально просто, держите заказчика при себе или сами держитесь при заказчике, позвольте ему активно следить за процессом разработки, приветствуйте изменения - и успех практически обеспечен.
В основе экстремального программирования лежат не конкретные методики, как принято считать, а лишь четыре базовых принципа: общение, простота, обратная связь и храбрость. Именно с них необходимо начинать.
В командах, работающих по методу XP, всегда приветствуется общение - самое быстрое средство обмена информацией и опытом. Это очень важно, когда требуется максимальная скорость разработки. Но общение, как и любое другое полезное начинание, требует постоянной поддержки. Именно поэтому кто-то из команды должен взять на себя ответственность следить за общением, стать так называемым дипломатом. Общение и необходимость объяснения своих действий другим членам команды вынуждает делать все максимально просто.
Если не получается с первого раза, над упрощением работают еще и еще, пока не будет достигнута главная цель - максимальная понятность кода другим разработчикам.
Что бы мы ни делали - вдевали нитку в иголку или собирались на вечеринку - мы всегда стремимся достичь какой-то цели. Если мы замечаем, что отклоняемся от нее, то корректируем свои действия соответствующим образом. А теперь представьте себе, насколько тяжелей попасть ниткой в иголку с закрытыми глазами или красиво одеться без зеркала! А ведь при разработке программ часто так и происходит: мы делаем нечто, результат чего нам не виден. Поэтому в экстремальном программировании принято за правило видеть результат своих действий настолько быстро, насколько это возможно. Или, говоря техническим языком, обеспечить максимально быструю обратную связь.
Экстремальное программирование спрашивает нас: почему бы не воспитать в себе храбрость? Ведь она очень важна в работе. Разве можно без храбрости принять на себя ответственность за выполнение какой-то задачи, да еще в конкретные сроки? Разве можно без храбрости осознать, что ты уперся в тупик, сделать шаг назад и поискать обходной путь? И, наконец, что позволит разработчику признать свою ошибку в оценке задачи и вовремя предупредить об этом остальных вместо того, чтобы поставить их перед фактом уже тогда, когда все сроки истекут? Польза храбрости налицо, и каждый успех, даже в самой маленькой задачке, способен эту храбрость развить.
Таковы главные принципы. А теперь обратим внимание на целый арсенал методик экстремального программирования, позволяющих реализовать эти принципы.
Коллективное владение кодом
Традиционно программный продукт поделен на сферы влияния между несколькими разработчиками. Каждый программист разрабатывает и отвечает за определенные участки программы.В такой схеме каждый разработчик является специалистом узкого профиля. Он понятия не имеет, что творится в коде соседей. Если требуется внести изменения в "чужой" код, программист вынужден попросить об этом "владельца" соответствующей части программы.
Такая расстановка сил оправдана, если в команде царит абсолютное доверие и надежность каждого безупречна. Но представьте, что произойдет, если один из разработчиков уйдет в отпуск, заболеет или вовсе уволится? Насколько замедлит разработку такое выпадение звена из общей цепочки?
Вместо того чтобы надеяться на удачу, экстремальное программирование предлагает смотреть реальным трудностям в лицо. Для того чтобы компенсировать возможные "выпадающие звенья", используется принцип коллективного владения кодом. Каждым участком кода должны владеть как минимум два программиста, и любой член команды может внести изменения в любой кусок кода.
Работоспособность такого подхода поддерживается другими методиками, такими как модульное тестирование и простота разработки. Внести изменения в простой код несложно, а если от этого нарушится что-то написанное ранее, об этом сразу просигнализируют модульные тесты.
Метафора системы
Экстремальное программирование обеспечило нас простым, но эффективным инструментарием для освоения разрабатываемой системы. В частности, первое представление о системе может быть получено посредством метафоры, или сравнения с существующими аналогами.Человеческое мышление построено на образах: каждое слово вызывает в памяти ассоциацию с характерным образом. Специалисты учли этот факт и выделили его в отдельную методику. Теперь для понимания системы используется сравнение наиболее похожего ранее известного продукта или предмета с разрабатываемым. Всегда легче запомнить мелкие отличия, чем строить в уме всю систему по кусочкам.
Парное программирование
Опытные разработчики заметили, что периодический просмотр чужого кода положительно влияет на его качество. Мастера экстремального программирования развили этот подход: в ходе разработки код пересматривается постоянно посредством приема, именуемого парным программированием.Парное программирование заключается в том, что два программиста работают за одним компьютером, пользуясь общими клавиатурой и мышкой. Такой незамысловатый подход не только повышает качество кода, но и обеспечивает более тесное общение, неявную передачу знаний, более эффективное использование рабочего времени, позволяет выявлять глобальные ошибки на ранних стадиях… И это еще далеко не все его преимущества. Исследования парного программирования показывают, что затраты на разработку не увеличиваются вдвое, а за счет экономии времени остаются приблизительно на том же уровне.
Постоянная переработка
Не секрет, что добавление каждой новой функциональности и разрастание кода усложняют разработку, выявление ошибок и внесение последующих изменений. Одной из уловок экстремального программирования является компенсация добавления функциональности усовершенствованием кода. Это и есть переработка кода, или рефакторинг.Правила хорошего тона для большинства языков программирования, особенно объектно-ориентированных, давно сформулированы. Если ими грамотно руководствоваться при написании нового кода и учитывать все возможные изменения, то никакой переработки не потребуется. Но на такое мало кто способен. Код не всегда получается красивым с первого раза, отчего трудозатраты стремительно растут.
Переработка кода позволяет адекватно и немедленно реагировать на каждое изменение. Переработка кода - настолько мощный инструмент обеспечения качества программы, что может быть выделена в отдельную дисциплину. В частности, типовые случаи и подходы, применяемые при переработке кода, детально описаны в книге Мартина Фаулера "Рефакторинг".
Продолжающаяся интеграция
Очень часто разработчики сталкиваются с проблемами поздней интеграции, когда новая функциональность оказывается несовместима с остальным проектом. Единственным эффективным средством решить такую проблему является продолжающаяся интеграция. Интегрировав работоспособный участок кода раньше, можно побороть или даже предотвратить несовместимость на ранней стадии проекта.Несмотря на свою простоту, такая методика имеет свои правила использования, такие как успешность выполнения имеющихся модульных тестов для интегрируемой функциональности, наличие функциональных или приемочных тестов и, конечно же, возможность отката к предыдущему состоянию. Как правило, интеграция и разрешение сопутствующих трудностей выполняются на отдельном компьютере парой программистов. Это позволяет свести к минимуму риск нежелательных последствий интеграции.
Программист или интерэкшн-дизайнер?
VP Design and General Manager, Cooper Ltd.Оригинал: Can Programmers Do Interaction Design? by Kim Goodwin
Перевод: , сайт maxkir.com
Практически во всех компаниях, с которыми работала наша консалтинговая фирма, программисты считают, что форму и поведение программного продукта должны определять именно они. Наверное, при отсутствии интерэкшн-дизайнеров так оно и есть. Программист по опыту знает, что никто не продумает за него, как именно программа будет предоставлять информацию пользователю. Остальные тоже не задаются вопросом, почему разработкой поведения программы занимается программист, так как это считается технической задачей.
В результате руководители уверены, что интерэкшн-дизайн им бесплатно сделают программисты. Им кажется, что интерэкшн-дизайнеры вообще не нужны: если программное приложение получится слишком сложным, они решат, что программистам нужен соответствующий психологический тренинг. Однако дизайн поведения программы, разработанный программистами, далеко не бесплатное приобретение. Такой дизайн не качественен, не эффективен и, к тому же, связан с серьезным риском.
Такой дизайн не качественен, потому что программисты не способны думать как интерэкшн-дизайнеры (или пользователи).
Если вам важно, чтобы пользователи и заказчики были довольны программным продуктом, то его дизайном должны заниматься люди, которые понимают чаяния заказчиков и пользователей, и способны смотреть на мир их глазами. Программисты же не способны думать так, как думают обычные люди. Их мыслительный процесс настолько отличается от среднестатистического, будто они относятся к другому биологическому виду. Алан Купер даже прозвал их "хомо логикус". Он нас, сапиенсов, их отличает не только пристрастие к кофеину и отвращение к дневному свету; самое большое различие состоит в мировосприятии. Нам достаточно просто радоваться тому, что программа делает то, что мы от нее хотим. Нас не интересует, как именно она это делает. А вот представитель вида хомо логикус, в отличие от нас, глубоко интересуется как раз тем, как программа устроена внутри.
Хороший программист одновременно удерживает в голове целую дюжину переменных и продумывает все возможные граничные условия, которые могут нарушить работу программы. А вот о чем программист задумывается редко, так это о том, что "возможное" далеко не всегда означает "вероятное". Возьмем простой пример: в приложении Apple iPhoto самые важные для пользователя функции, как например, разворот и обрезка фотографий, вынесены на самое видное место. Если бы дизайн для iPhoto создавал программист, то наряду с часто используемыми функциями, "на поверхности" оказались бы и специфические возможности, например, изменение глубины цвета изображения. Интерэкшн-дизайнер либо "спрячет" эту возможность подальше в меню, либо, что еще лучше, вообще откажется от нее, сэкономив, тем самым, время на разработку и поддержку программы.
Такой дизайн не эффективен, потому что изначально у программиста нет описания поведения программы.
Когда дизайн продукта создается программистом, время работы существенно увеличивается. Первая, и самая очевидная причина состоит в том, что программист тратит свое драгоценное время на выбор элементов управления и расположение их на экране, когда он мог бы писать код. Эта неэффективность еще больше заметна при итеративной разработке: представьте себе, что вы пригласили архитектора построить дом, но не дали ему чертежей. Когда вы отвергаете то, что было построено во время первой итерации, он говорит: "Прекрасно, второй этаж вам был не нужен. Нет проблем, сейчас мы его снесем, а в следующий раз постараемся построить то, что вам понравится больше". Конечно, при разработке программных продуктов этот процесс не так нагляден, но его последствия оказывают не менее разрушительный эффект на бюджет и временные рамки проекта.
"Но ведь мы же дали им спецификации!" - восклицают маркетологи. "Они просто не делают то, о чем мы их просим!". Если честно, самим программистам тоже не очень-то нравится постоянно переделывать свою работу.
Однако они не умеют читать мысли, а без этой способности едва ли можно разобраться в обычной спецификации, которую написали сотрудники отдела маркетинга. Если бы Стивен Спилберг дал своей команде такую задачу: показать сцену погони, любовную сцену, взрыв и хэппи энд, то едва ли в итоге получился бы впечатляющий блокбастер.
Программисты, по идее, должны работать с неким планом и спецификацией поведения программы, которая описывает внешний вид каждого экрана и поведение всех находящихся на них элементов. Когда у программистов есть подобные спецификации, они работают гораздо эффективнее, заметно сокращая и время, и объем работ, и количество итераций, что не раз отмечали наши клиенты. Одни говорят, что время разработки сократилось вдвое, другие утверждают, что сэкономили год работы.
Этот дизайн связан с риском, потому что руководители проекта не контролируют ситуацию.
У большинства руководителей - тех, которые не разбираются в технических вопросах, и даже тех, которые разбираются в них очень хорошо, в глубине души живет ощущение, что они не контролируют процесс разработки. И они совершенно правы. Конечно, они могут определять сроки, зато программисты решают все остальное. В этом нет ничего пред- или злонамеренного. Если бы это было так, то руководители уже давно приняли бы меры. Это происходит негласно, потому что вопросы поведения продукта считаются техническими и автоматически переходят в ведение программистов.
Проблема усложняется еще и тем, как мыслит разработчик: у него никогда нет достаточного количества времени - ни на то, чтобы писать код, ни на то, чтобы следовать процессу, ни на что. Если маркетолог подойдет к нему с вопросом: "А нельзя ли вот тут сделать поддержку функции "перетащить и оставить"?", то программист обязательно ответит: "Нет, это практически невозможно". Однако по-настоящему он имеет в виду: "Это невозможно сделать за тот ничтожный период времени, который вы мне отвели. Я не могу выполнить те двадцать запросов, которые вы уже дали, и еще вот этот".
Эта уверенность в нехватке времени приводит к подспудным решениям относительно функциональности продукта, а руководители даже не понимают этого. А что если возможность "перетащить и оставить" сделала бы ваш онлайновый магазин недосягаемым для конкурентов? Что если бы это позволило сэкономить 20 000 долларов в месяц на звонках в службу технической поддержки? Абсолютное большинство руководителей предпочтут выпустить хороший продукт, но на месяц позже, чем в срок, но плохой.
Включая в команду разработчиков дизайнеров-непрограммистов, руководители снова обретают контроль над решением важных вопросов, касающихся функциональности продукта. Вооружившись исследованиями поведения целевой аудитории, интерэкшн-дизайнеры могут сесть за "стол переговоров" с маркетологами, техническими специалистами и руководителями и найти такое решение, которое наилучшим образом удовлетворяло бы ожидания пользователей и клиентов. Тут же технический специалист может донести до общего сведения, сколько времени и сил уйдет на это у программистов, маркетологи оценят влияние такого решения на количество продаж, а руководитель, получив всю необходимую информацию, принимает оптимальное для компании решение.
Работа интерэкшн-дизайнера выгодна с точки зрения себестоимости, потому что в результате у программистов высвобождается время на написание кода, клиенты получают продукт, который им нравится, и который они не променяют ни на какой другой. При этом сокращаются расходы на службу технической поддержки, а весь процесс разработки становится более предсказуемым и контролируемым. Так почему бы вам прямо сейчас не набрать номер отдела по найму персонала и не сказать, что у вас есть вакансия?
Об авторе
Ким Гудвин (Kim Goodwin) является вице-президентом по дизайну и генеральным менеджером компании "Cooper". Если у вас есть вопросы, комментарии или предложения, вы можете написать ей письмо на адрес kim@cooper.com
1) Для термина "interaction designer" пока еще не существует устоявшегося русского перевода.Именно поэтому здесь этот термин просто транскрибируется. "Интерэкшн-дизайнер" - возможно, не лучший вариант, но по крайней мере, звучит привычно в профессиональной среде и не создает вопросов относительно его значения. Другие варианты перевода: "дизайнер взаимодействия", "проектировщик взаимодействия", "дизайнер интерактивных систем".
© Copyright Cooper Ltd., все права защищены
© Copyright , перевод, 2004
Простота разработки
Экстремальное программирование учит нас делать все максимально просто - другими словами, не усложнять себе жизнь. В том числе и при разработке программного обеспечения. Простую программу легче поддерживать, в нее легче вносить изменения, она менее подвержена ошибкам.Рассмотрим такой пример. Можете ли вы сходу сказать, что делает следующий код C++ и результат какой математической операции с переменной x отражен в переменной f?
int x = 5; for (int i = 1, f = 1; i < x; i++, f *= i); cout<
int x = 5; int f = 1; for (int i = 1; i < x; i++) { f *= i; } cout<
Сорокачасовая рабочая неделя
Человек, особенно если он программист, ради дела способен на многое: задержаться на работе, выйти на работу на выходные, отказаться от отпуска, несколько суток не спать, сидя за клавиатурой… В общем, чего только не сделаешь ради любимого занятия. Но экстремальное программирование категорически против такого самопожертвования и нарушения принятых норм трудового права.Это продиктовано не только соображениями законности и гуманности, а - в первую очередь - необходимостью повышения эффективности работы и строгой организации. Ведь экстремальное программирование - коллективная игра, рассчитанная не на индивидуумов, а на всю группу целиком. А такая вещь, как, например, парное программирование, возможна лишь при синхронизации биоритмов ее участников. И она невозможна, если один человек будет приходить на работу к девяти, а второй к двенадцати или один решит, что ему лучше поработать в субботу и воскресенье, а другому это неудобно.
Но самое главное - человеку, чтобы сохранить здоровье и работоспособность, необходим полноценный отдых. Восьмичасовой рабочий день и пятидневная рабочая неделя установлены именно из соображений максимальной продуктивности. Во многих западных фирмах поздний уход с работы расценивается как неуспеваемость или неспособность правильно распорядиться своим рабочим временем. В большинстве случаев это так и есть. Да и с медицинской точки зрения, задержки на работе ведут к постоянной усталости, раздражительности и снижению мозговой деятельности. Разве это эффективно? А как в таком коллективе организовать постоянное открытое общение между разработчиками, и возможно ли будет парное программирование? Ответ отрицательный. Нормы есть нормы, и их стоит придерживаться.
Стандарты кодирования
Как ни странно, но эта давно известная методика не всегда применяется разработчиками программного обеспечения. Экстремальное программирование в качестве обязательного условия успешности работы над проектом выдвигает требование применения стандартов кодирования.Это оправдано со многих позиций: единообразный код более понятен другим разработчикам, а споры о пробелах перед скобками уже вошли в легенды, да и задумываться при внесении изменений в чужой код относительно форматирования выражений не придется.
Тестирование до начала разработки
Тестирование, в его классическом понимании, - довольно скучная процедура. Обычно нанимают тестировщика, который периодически выполняет одни и те же действия и ждет того дня, когда его, наконец, переведут на другую должность или появится возможность поменять работу.В экстремальном программировании роль тестирования интереснее: теперь вначале идет тест, а потом код. Как же тестировать то, чего еще нет? Ответ прост и банален: тестируйте свои мысли - чего следует ожидать от будущего куска программы или функциональности. Это позволит лучше понять, что требуется сделать программистам, и проверить работоспособность кода сразу, как только он будет написан.
Мне возразят: но ведь тест тоже может не работать. Что же, писать тест для теста? А потом тест для теста теста и так далее до бесконечности? Вовсе нет. Тест для теста заменит код. Как так? А вот смотрите: представьте себе, что нужно зафиксировать гайку посередине болта так, чтобы она не проворачивалась. Что для этого делают? Прикручивают вторую гайку вплотную к первой, так что каждая гайка не дает соседней проворачиваться. Так и в программировании: тест тестирует код, а код тестирует тест.
Опыт показывает, что такой подход не только не замедляет, но и ускоряет разработку. Ведь знание того, что нужно сделать, и требуемого объема работ позволят сэкономить время, отказавшись от реализации невостребованных в данный момент деталей.
Управление проектами
Иван Селиховкин
Сергей Архипенков
Сергей Архипенков
Семенов В.А., Морозов С.В., Тарлапан О.А., Энкович И.В.
Труды Института системного программирования РАН
Труды Института системного программирования РАН
Сергей Архипенков
Перевод: Сергей Кузнецов
Оригинал: A Conversation with Bruce Lindsay, ACM Queue, Vol. 2, No. 8 - November 2004.
В.А. Семенов, С.Г. Ерошкин, А.А. Караулов, И.В. Энкович,
Труды Института системного программирования РАН
Е. Д. Волкова, А. Д. Страбыкин,
Труды Института системного программирования РАН
,
Терехов Андрей Николаевич, Интернет-Университет Информационных Технологий, INTUIT.ru
, Компания
Источник:
, Труды Института системного программирования РАН
Волкова Е.Д., Страбыкин А.Д., Труды Института системного программирования РАН
,
Скотт Амблер, Ambysoft Inc.
Перевод - Сергей Кузнецов
, Препринт Института Системного Программирования РАН
Наталья Чернявская, Юрий Чернявский,
Алистэр Коуберн
()
Перевод: , maxkir.com
Мартин Фаулер, Chief Scientist, ThoughtWorks
Перевод: , http://maxkir.com/
VP Design and General Manager, Cooper Ltd.
Перевод: , сайт maxkir.com
Алистэр Коуберн, Humans and Technology, 4-ое октября 2003
Перевод: , сайт maxkir.com
Евгений Марков
Ксензов Михаил, Труды Института Системного Программирования РАН
Буздин К.В., Труды Института Системного Программирования РАН
, Softline Company
С.Архипенков
, , www.cmcons.com
Арсений Чеботарев,
,
К.В. Халимов, М.В. Резник, ЗАО "ПМСОФТ"
Гаврилов Н.Н., РЭА им. Г.В. Плеханова
Козлов А.С., ГУУ
Матвеев А.А., ЗАО "ПМСОФТ"
В.Н. Михеев,,
Е.О.Пужанова, ЗАО "ПМСОФТ"
, ООО ИК СИБИНТЕК
, "Экспресс-Электроника"
, "Экспресс-Электроника"
, "Экспресс-Электроника"
Наталья Дубова,
К.В. Ахтырченко, Т.П. Сорокваша, Труды
,
Джеймс Уайттеккер, Джеффри Воас
20.03.2003
Евгений Игумнов
В. Сухомлин, НИВЦ МГУ, учебные материалы конференции ,
Заказчик на рабочей площадке
Основной проблемой разработки программного обеспечения является недостаток знаний программистов в разрабатываемой предметной области. Экстремальное программирование нашло выход и из этой ситуации. Нет, это не стажировка разработчика на предприятии заказчика - он тогда не захочет программировать. Наоборот, это участие заказчика в процессе разработки.Разве может программист, досконально не понимая суть вопроса и не будучи телепатом, угадать, чего хочет заказчик? Ответ очевиден. Самым простым способом преодолеть такое неудобство - а экстремальное программирование учит нас находить самые простые решения - будет задать заказчику прямой вопрос. Более строгие подходы требуют всеобъемлющего предварительного анализа разрабатываемой области. В определенных случаях это оправдано, хотя и дороже обходится. Реальный опыт ведения приземленных проектов показывает, что невозможно собрать все требования заранее. Более того, даже если предположить, что все требования на текущий момент собраны, все равно останется одно узкое место: программы, как и все в природе, не создаются мгновенно, а тем временем бизнес-процессы могут поменяться. Это следует учитывать.
Многие сомневаются в возможности привлечения заказчика к процессу разработки. Действительно, заказчики бывают разные. Если привлечь заказчика или его представителя не удается, иногда оказывается целесообразным временный наем специалиста в разрабатываемой области. Такой шаг сократит неясности в работе, повысит скорость разработки и приблизит проект к тому, что желает получить заказчик. Это может быть выгодно и с финансовой стороны: ведь оплата труда программиста порой значительно превышает оклад специалистов других отраслей.
Эти методики собраны воедино не
Эти методики собраны воедино не случайно. Их непротиворечивая совокупность способна ввести процесс разработки в интеллектуальный резонанс, заметно повысив качество продукта и приблизив время его выпуска. Основная прелесть всего экстремального программирования - прогнозируемость и сведение к минимуму затрат на разработку; предоставление заказчику того продукта, который он желает получить на момент выпуска; и конечно же общение и обучение разработчиков без отрыва от производства. 
Менеджмент: Стратегии - Виды - Организация
- Стратегический менеджмент
- Стратегии стратегического менеджмента
- Практика стратегического менеджмента
- Экономика стратегического менеджмента
- Менеджмент
- Основы менеджмента
- Финансы менеджмента
- Организация менеджмента
- Виды менеджмента
- Менеджмент по русски
- Мотивационный менеджмент