Программная инженерия

ЛЕКЦИИ по дисциплине «Программная инженерия» ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ Программная инженерия (промышленное программирование) обычно ассоциируется с разработкой больших и сложных программ коллективами разработчиков. Программная инженерия – что это такое? На сегодняшний день нет единого определения понятия «программная инженерия». Ниже приведено несколько таких определений, данных крупными специалистами в этой области, или зафиксированные в документах ведущих организаций]: • установление и использование обоснованных инженерных принципов (методов) для экономного получения ПО, которое надежно и работает на реальных машинах. • та форма инженерии, которая применяет принципы информатики (computer science) и математики для рентабельного решения проблем ПО. [CMU/SEI-90- TR-003] • применение систематического, дисциплинированного, измеряемого подхода к разработке, использованию и сопровождению ПО [IEEE 1990]. • дисциплина, целью которой является создание качественного ПО, которое завершается вовремя, не превышает выделенных бюджетных средств и удовлетворяет выдвигаемым требованиям. Для того, чтобы получить представление о том, что такое программная инженерия, попробуем разобраться в следующих вопросах: • Что такое программное обеспечение (software)? • Какими свойствами обладает хорошая программа? • Что такое программная инженерия? • В чем отличие программной инженерии от других инженерий? Что такое программное обеспечение (software)? Взгляд на ПО как только на программу, сидящую в компьютере слишком узок. Дело в том, что продается (поставляется) не только программа, но еще и документация, в которой можно прочитать, как установить программу и как ей пользоваться и данные для установки программы в различных условиях (конфигурационные файлы). Поэтому ПО иногда называют программным продуктом. Т.е. программный продукт (программное обеспечение) – это не только программы, а также вся связанная с ними документация и конфигурационные данные, необходимые для корректной работы программы. А специалисты по программному обеспечению разрабатывают программные продукты, т.е. такое ПО, которое может быть продано потребителю. В зависимости от того, для кого разрабатываются программные продукты (конкретного заказчика или рынка, программные продукты бывают двух типов: • коробочные продукты (generic products – общие продукты или shrink-wrapped software – упакованное ПО) • заказные продукты (bespoke – сделанный на заказ или customized products – настроенный продукт). Важная разница между ними заключается в том, кто ставит задачу (определяет, или специфицирует требования). В первом случае это делают сами разработчики на основе анализа рынка (маркетинга) – и при этом рискуют сами. Во втором – заказчик и при этом рискует, что разработчик не сможет реально выполнить все требования в срок и при выделенном бюджете. Свойства хорошей программы Прежде всего, хорошая программа должна делать то, что ожидает от нее заказчик – т.е. удовлетворять требованиям заказчика. Такие требования называют функциональными. Но кроме функциональных требований, существует еще ряд общих характеристик, которым в той или иной степени должна обладать каждая программа. Эти характеристики принято называть нефункциональными требованиями. К нефункциональным требованиям относят: 1. Сопровождаемость (maintainability). Сопровождаемость означает, что программа должна быть написана с расчетом на дальнейшее развитие. Это критическое свойство системы, т.к. изменения ПО неизбежны вследствие изменения бизнеса. Сопровождение программы выполняют, как правило, не те люди, которые ее разрабатывали. Сопровождаемость включает такие элементы как наличие и понятность проектной документации, соответствие проектной документации исходному коду, понятность исходного кода, простота изменений исходного кода, простота добавления новых функций. 2. Надежность (dependability). Надежность ПО включает такие элементы как: • Отказоустойчивость – возможность восстановления программы и данных в случае сбоев в работе • Безопасность – сбои в работе программы не должны приводить к опасным последствиям (авариям) • Защищенность от случайных или преднамеренных внешних воздействий (защита от дурака, вирусов, спама). 1. Эффективность (efficiency). ПО не должно впустую тратить системные ресурсы, такие как память, процессорное время, каналы связи. Поэтому эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т.п. 2. Удобство использования (usability). ПО должно быть легким в использовании, причем именно тем типом пользователей, на которых рассчитано приложение. Это включает в себя интерфейс пользователя и адекватную документацию. Причем, пользовательский интерфейс должен быть не интуитивно, а профессионально понятным пользователю. Следует отметить, что реализация нефункциональных требований часто требует больших затрат, чем функциональных. Так, сопровождаемость требует значительных усилий по поддержанию соответствия проекта исходному коду и применения специальных методов создания модифицируемых программ. Надежность – дополнительных средств восстановления системы при сбоях. Эффективность – поиска специальных архитектурных решений и оптимизации кода. А удобство – проектирования не «интуитивно» понятного, а профессионально понятного интерфейса пользователя. Что такое программная инженерия? Программная инженерия — это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. В этом определении есть две ключевые фразы: • Инженерная дисциплина • Все аспекты производства ПО. Получается, что так мы обозначаем, во-первых, специальную область знания или другими словами, научную дисциплину, а во-вторых, все аспекты производства ПО, т.е. некоторую практическую деятельность. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) – тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом (например, MSF, RUP, CMMI, Scrum). Вот эти-то обобщения и входят в программную инженерию как в область знания. Примечание. Microsoft Solutions Framework (MSF) — методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения. MSF представляет собой согласованный набор концепций, моделей и правил. Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software. Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности. Scrum ( англ. scrum «схватка») — методология гибкой разработки ПО. Методология делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, или как подход к управлению разработкой и сопровождению программ: Scrum of Scrums. Все аспекты производства ПО. Необходимо понимать, что заказчику нужно, во-первых, выполнить работу в определенные сроки, во-вторых, результат должен быть требуемого качества – того, которое удовлетворит заказчика и за которое он заплатит. Чтобы удовлетворить этим требованиям, программирование "обрастает" различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Таким образом, программная инженерия занимается не только техническими вопросами производства ПО (специфицирование требований, проектирование, кодирование), но и управлением программными проектами, включая вопросы планирования, финансирования, управления коллективом и т.д. Кроме того, задачей программной инженерии является разработка средств, методов и теорий для поддержки процесса производства ПО. Таким образом, программная инженерия применяется для удовлетворения требований заказчика ПО. Основные цели программной инженерии: • Системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения. • Качество ПО должно быть высоким. • Разработка ПО должна быть осуществлена в рамках выделенного бюджета. • Системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющимся ПО. • Системы должны быть легко сопровождаемыми и масштабируемыми. В чем отличие от других инженерий? Отличие программной инженерии от других инженерий интересно прежде всего с точки зрения двух вопросов: • Почему доля провальных проектов в программной инженерии так велика по сравнению с другими инженериями? • Можно ли в программной инженерии применять опыт других инженерий? Эти вопросы является фундаментальными для программной инженерии. По этому поводу высказывается много мнений (и часто противоположных). Остановимся на некоторых более или менее очевидных отличиях программной инженерии от других инженерий. Прежде всего, отметим, что жизненный цикл продукта любой инженерии в упрощенном виде включает фазы: проектирование, создание образца, испытание, производство, эксплуатация. Компьютерная программа – это (в отличие от объектов других инженерий) не материальный объект (просьба не путать с носителем программы – устройством памяти любого типа). Отсюда следуют следующие отличия. Фаза производства состоит в копировании образца на другие носители. Стоимость фазы исчезающее мала. Если кодирование считать элементом проектирования (что очень близко к истине), то отсутствует также и фаза создания образца (строится компилятором и линковщиком). Отсюда следуют следующие выводы: • Стоимость программы – это стоимость только ее проектирования • Стоимость проектирования коробочных продуктов «размазывается» по копиям • Стоимость заказных продуктов (массово не копируемых) остается высокой Второе существенное отличие состоит в том, что программа – искусственный объект. Т.е. для программы нет объективных законов, которым бы подчинялось ее поведение. Например, у инженера – строителя есть объективные законы строительной механики: равновесия моментов и сил, устойчивости механических систем и т.д. Инженер – строитель может проверить свои архитектурные решения на соответствие этим законам и тем самым обеспечить удачу проекта. Эти законы объективны, они будут действовать всегда. У программного инженера на первый взгляд также есть типовые, проверенные временем архитектурные решения (например, клиент-серверная архитектура). Но эти решения определяются уровнем развития вычислительной техники (и адекватным им уровнем требований). С появлением техники с принципиально новыми возможностями программному инженеру придется искать новые решения. Прямым следствием отсутствия возможности «теоретического» контроля проекта является то, что тестирование продукта – это единственный способ убедиться в его качестве. Именно поэтому стоимость тестирования составляет существенную стоимость ПО. Кстати, строительный инженер, как правило, лишен возможности такого «тестирования» своего продукта перед сдачей его в эксплуатацию. Ну и наконец, программная инженерия – молодая дисциплина, опыт которой насчитывает всего несколько десятков лет. По сравнению с опытом строительной инженерии (тысячелетия) это конечно очень мало. Программную инженерию иногда сравнивают с ранней строительной, когда законы строительной механики еще не были известны и строительные инженеры действовали методом проб и ошибок, накапливая бесценный опыт. Несмотря на молодой возраст, программная инженерия также накопила определенный опыт, который позволяет (при разумном его применении) делать удачные проекты. Этот опыт выражен в основных принципах программной инженерии, которые мы с вами сейчас рассмотрим. Подробнее о проблемах проектирования ПО можно посмотреть в неоднозначной статье Кони Бюрера «От ремесла к науке: поиск основных принципов разработки ПО» http://interface.ru/fset.asp?Url=/rational/science.htm Методы программной инженерии? Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом. В этом определении есть две основные составляющие: (а) создание высококачественного продукта и (б) экономически эффективным способом. Иными словами, метод – это то, что обеспечивает решение основной задачи программной инженерии: создание качественного продукта при заданных ресурсах времени, бюджета, оборудования, людей. Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны: · Метод структурного анализа и проектирования Том ДеМарко (1978), · Метод сущность-связь проектирования информационных систем Чен (1976) · Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991). Метод программной индустрии основан на идее создания моделей ПО с поэтапным преобразованием этих моделей в программу – окончательную модель решаемой задачи. Так, на этапе спецификаций создается модель – описание требований, которая далее преобразуется в модель проекта ПО, проект – в программный код. При этом важно, чтобы модели метода представлялись графически с помощью некоторого языка представления моделей. Методы должны включать в себя следующие компоненты: • Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.) • Правила и ограничения, которые надо выполнять при разработке моделей (например, каждый объект должен иметь одинаковое имя) • Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов) • Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом) Нет идеальных методов, все они применимы только для тех или иных случаев. Нет абсолютных методов – применяемые на практике методы могут включать элементы различных подходов. Выбор метода составляет задачу специалиста по программной инженерии. Предпосылки создания и история развития программной инженерии. Становление и развитие этой области деятельности было вызвано рядом проблем, связанных с высокой стоимостью программного обеспечения, сложностью его создания, необходимостью управления и прогнозирования процессов разработки. В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как кризис программирования. Выражался он в том, что большие проекты выполняются с превышением сметы расходов и/или сроков отведенных на разработку, а разработанное ПО не обладает требуемыми функциональными возможностями, имеет низкую производительность и качество. В результате чего, стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии промышленного программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г. Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. Там впервые и прозвучал термин «программная инженерия» как некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем. Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. Отмечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО. Вокруг этой концепции было много споров. В 1970 г. У.У. Ройс (W.W. Royce) произвел идентификацию нескольких стадий в типичном цикле и было высказано предположение, что контроль выполнения стадий приведет к повышению качества ПО и сокращению стоимости разработки. Программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. Этапы становления и развития программной инженерии: 1. 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (структурный подход) 2. 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО (объектно-ориентированный подход) Рост сложности программ (структурное программирование) Проблема. Возрастание стоимости ПО было связано с переходом от разработки относительно простых программ к разработке сложных программных комплексов. Следует отметить, что этот переход был вызван появлением вычислительной техники третьего поколения (интегральные схемы). С переходом на использование интегральных схем производительность компьютеров возросла на порядки, что и создало предпосылки для решения сложных задач. К числу таких сложных задач относятся: системы управления космическими объектами, управления оборонным комплексом, автоматизации крупного финансового учреждения и т.д. Сложность таких комплексов оценивалась следующими показателями: • Большой объем кода (миллионы строк) • Большое количество связей между элементами кода • Большое количество разработчиков (сотни человек) • Большое количество пользователей (сотни и тысячи) • Длительное время использования. Для таких сложных программ оказалось, что основная часть их стоимости приходится не на создание программ, а на их внедрение и эксплуатацию. По аналогии с промышленной технологией стали говорить о жизненном цикле программного продукта, как о последовательности определенных этапов: этапа проектирования, разработки, тестирования, внедрения и сопровождения. Структурное программирование. Этап сопровождения программного комплекса включал действия по исправлению ошибок в работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соответствовала программному коду, а сам программный код был очень сложен и запутан. Нужна была технология, которая обеспечит «правильное» проектирование и кодирование. Основные принципы технологии структурного проектирования и кодирования: • Нисходящее функциональное проектирование, при котором в системе выделяются основные функциональные подсистемы, которые потом разбиваются на подсистемы и т.д. (принцип «разделяй и властвую») • Применение специальных языков проектирования и средств автоматизации использования этих языков • Дисциплина проектирования и разработки: планирование и документирование проекта, поддержка соответствие кода проектной документации • Структурное кодирование без goto Модификация программ (ООП) Проблема. Следующая проблема роста стоимости программ была вызвана тем, что изменение требований к программе стали возникать не только на стадии сопровождения, но и на стадии проектирования – проблема заказчика, который не знает, что он хочет. Создание программного продукта превратилось в его перманентное перепроектирование. Возник вопрос, как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода. Объектно-ориентированное программирование. Решением этой проблемы стало использование подхода или метода, который стали называть объектно-ориентированным проектированием и программированием. Суть подхода состоит в том, что вводится понятие класса как развитие понятия модуля с определенными свойствами и поведением, характеризующими обязанностями класса. Каждый класс может порождать объекты – экземпляры данного класса. При этом работают основные принципы (парадигмы) ООП: • Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обработки). • Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов • Полиморфизм – определение свойств и методов объекта по контексту Как обстоят дела в настоящее время с разработкой ПО? По результатам исследований американской индустрии разработки ПО, выполненных в 1995 году Standish Group (www.standishgroup.com), только 16% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности. 53% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. 31% проектов были аннулированы до завершения. Представленная в таблице статистика по 30000 проектам по разработке ПО в американских компаниях показывает следующее распределение между: • Успешными проектами – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ • Проблемными проектами – нарушение сроков, перерасход бюджета и/или сделали не все, что требовалось • Проваленными проектами – не были доведены до конца из-за перерасхода средств, бюджета, качества. 1995 1996 1998 2000 2004 2006 2009 отменены 31% 40% 28% 23% 18% 19% 24% ущербны 53% 33% 46% 49% 53% 46% 44% успешны 16% 27% 26% 28% 29% 35% 32% В последние годы процентное соотношение трех перечисленных категорий проектов незначительно изменяется в лучшую сторону. Но несмотря на то, что программная инженерия достигла определенных успехов, перманентный кризис программирования продолжается. Связано это с тем, рубеж 80–90-х годов отмечается как начало информационно-технологической революции, вызванной взрывным ростом использования информационных средств: персональный компьютер, локальные и глобальные вычислительные сети, мобильная связь, электронная почту, Internet и т.д. Причины неудач: • нечеткая и неполная формулировка требований; • недостаточное вовлечение пользователей в работу над проектом; • отсутствие необходимых ресурсов; • неудовлетворительное планирование и отсутствие грамотного управления проектом; • частое изменение требований и спецификаций; • новизна и несовершенство используемой технологии; • недостаточная поддержка со стороны высшего руководства; • недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта. При планировании проектов зачастую по тем или иным причинам устанавливаются невыполнимые сроки, закладываются недостаточные ресурсы. Таким образом, возникают безнадежные проекты (death march projects). Признаки безнадежного проекта: • план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; • количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба; • бюджет и связанные с ним ресурсы урезаны наполовину; • требования к функциям, производительности и другим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях. Другой причиной неверного планирования является заблуждение относительно производительности проектировщиков. В большом проекте общая производительность группы разработчиков не равна сумме производительностей отдельных членов группы (посчитанной как если бы они работали в одиночку). Об этом в книге «Мифический человеко-месяц» пишет Фредерик Брукс. (Брукс Ф. Мифический человеко-месяц или как создаются программные системы. – СПб.: Символ-Плюс, 1999) Выводы Брукса: • самая частая причина провала – нехватка времени; • иногда работы нельзя ускорить, не испортив результат; • человеко-месяц – опасное заблуждение, поскольку предполагается, что количество людей и месяцы можно поменять местами; • разделение задачи между несколькими людьми вызывает накладные затраты; • если проект не укладывается в срок, то добавление людей задержит его еще больше; • «серебряной пули» нет! Последнее положение касается технологии разработки. Брукс утверждает, что технологии, позволяющей на порядок повысить производительность разработчиков, не существует. То есть, нельзя полагать, что какая-либо новейшая технология разработки позволит осуществить проект в 10 раз быстрее. Особенности современных проектов ПО: • сложность – неотъемлемая характеристика создаваемого ПО; • отсутствие полных аналогов и высокая доля вновь разрабатываемого ПО; • наличие унаследованного ПО и необходимость его интеграции с разрабатываемым ПО; • территориально распределенная и неоднородная среда функционирования; • большое количество участников проектирования, разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и опыту. Разработка ПО имеет следующие специфические особенности: • неформальный характер требований к ПО и формализованный основной объект разработки – программы; • творческий характер разработки; • дуализм ПО, которое, с одной стороны, является статическим объектом – совокупностью текстов, с другой стороны, – динамическим, поскольку при эксплуатации порождаются процессы обработки данных; • при своем использовании (эксплуатации) ПО не расходуется и не изнашивается; • «неощутимость», «воздушность» ПО, что подталкивает к безответственному переделыванию, поскольку легко стереть и переписать, чего не сделаешь при проектировании зданий и аппаратуры Освоение и правильное применение методов и средств программной инженерии позволяет повысить качество, обеспечить управляемость процесса проектирования. Некоторые итоги Программная инженерия (или технология промышленного программирования) как некоторое направление возникло и формировалось под давлением роста стоимости создаваемого программного обеспечения. Главная цель этой области знаний – сокращение стоимости и сроков разработки программ. Фундаментальная идея программной инженерии: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Основной принцип программной инженерии состоит в том, что программы создаются в результате выполнения нескольких взаимосвязанных этапов (анализ требований, проектирование, разработка, внедрение, сопровождение), составляющих жизненный цикл программного продукта. Фундаментальными методами проектирования и разработки являются модульное, структурное и объектно-ориентированное проектирование и программирование. Программная инженерия прошла несколько этапов развития, в процессе которых были сформулированы фундаментальные принципы и методы разработки программных продуктов. ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Понятие процесса Центральным объектом изучения программной инженерии является процесс создания ПО – множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (проектных планов, документации, программного кода, тестов, пользовательской документации и пр.). Его осознание, выстраивание и улучшение - основа любой эффективной групповой деятельности. Поэтому не случайно, что процесс оказался одним из основных понятий программной инженерии. Однако на сегодняшний день не существует универсального процесса разработки ПО – набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. Будем называть это предварительное описание конкретным процессом, отличая его от плана работ, проектных спецификаций и пр. Например, в системе Microsoft Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В рамках компании возможна и полезна стандартизация всех текущих процессов, которую будем называть стандартным процессом. Последний, таким образом, оказывается некоторой базой данных, содержащей следующее: • информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования – различных IDE, СУБД и т.д.); • описание практик разработки – проектного менеджмента, правил работы с заказчиком и т.д.; • шаблоны проектных документов – технических заданий, проектных спецификаций, планов тестирования и т.д. и пр. Основная идея стандартного процесса – курсирование внутри компании передового опыта, а также унификация средств разработки. Очень уж часто в компаниях различные департаменты и проекты сильно отличаются по зрелости процесса разработки, а также затруднено повторное использование передового опыта. Кроме того, случается, что компания использует несколько средств параллельных инструментов разработки, например, СУБД, средства версионного контроля. Но очень часто это произвольный выбор самих разработчиков. В любом случае, такая множественность существенно затрудняет миграцию специалистов из проекта в проект, использование результатов одного проекта в другом и т.д. Однако при организации стандартного процесса необходимо следить, чтобы стандартный процесс не оказался всего лишь формальным, бюрократическим аппаратом. Понятие стандартного процесса введено и подробно описано в подходе CMMI. Необходимо отметить, что наличие стандартного процесса свидетельствует о наличии "единой воли" в организации, существующей именно на уровне процесса. На уровне продаж, бухгалтерии и др. привычных для всех компаний процессов и активов единство осуществить не трудно. А вот на уровне процессов разработки очень часто каждый проект оказывается сам по себе – "текучка" захватывает и изолирует проекты друг от друга очень прочно. Совершенствование процесса Определение. Совершенствование процесса (software process improvement) – это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки. Причины актуальности этой деятельности для компаний-производителей ПО заключается в следующем. 1. Происходит быстрая смена технологий разработки ПО, требуются изучение и внедрение новых средств разработки. 2. Наблюдается быстрый рост компаний и их выход на новые рынки, что требует новой организации работ. 3. Имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки. Что и каким образом можно улучшать. 1. Переход на новые средства разработки, языки программирования и т.д. 2. Улучшение отдельных управленческих и инженерных практик – тестирования, управления требованиями и пр. 3. Полная, комплексная перестройка всех процессов в проекте, департаменте, компании. 4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.). Мы отделили п. 3 от п. 4 потому, что на практике 4 далеко не всегда означает действительную созидательную работу по улучшению процессов разработки ПО, а часто сводится к поддержанию соответствующего документооборота, необходимого для получения сертификации. Сертификат потом используется как средство, козырь в борьбе за заказы. Главная трудность реального совершенствования процессов в компании заключается в том, что она при этом должна работать и создавать ПО, ее нельзя "закрыть на учет". Отсюда вытекает идея непрерывного улучшения процесса, так сказать, малыми порциями, чтобы не так болезненно. Это тем более разумно, что новые технологии разработки, появляющиеся на рынке, а также развитие уже существующих нужно постоянно отслеживать. Эта стратегия, в частности, отражена в стандарте совершенcтвования процессов разработки CMMI. Pull/Push стратегии. В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО) существуют две следующие парадигмы. 1. Organization pull – инновации нацелены на решение конкретных проблем компании. 2. Technology push – широкомасштабное внедрение инноваций из стратегических соображений. Вместо конкретных проблем, которые будут решены после внедрения инновации, в этом случае рассматриваются показатели компании (эффективность, производительность, годовой оборот средств, увеличение стоимости акций публичной компании), которые будут увеличены, улучшены после внедрения инновации. При этом предполагается, что будут автоматически решены многочисленные частные проблемы организации, в том числе и те, о которых в данный момент ничего не известно. Пример использования стратегии organization pull – внедрение новых средств тестирования в ситуации, когда высоки требования по качеству в проекте, либо когда качество программной системы не удовлетворяет заказчика. Пример использования стратегии technology push – переход компании со средств структурной разработки на объектно-ориентрованные. Еще один пример использования той же стратегии – внедрение стандартов качества ISO 9000 или CMMI. В обоих этих случаях компания не решает какую-то одну проблему или ряд проблем – она хочет радикально изменить ситуацию, выйти на новые рубежи и т.д. Проблемы применения стратегии technology push в том, что требуется глобальная перестройка процесса. Но компанию нельзя "закрыть на реконструкцию" – за это время положение на рынке может оказаться занято конкурентами, акции компании могут упасть и т.д. Таким образом, внедрение инноваций, как правило, происходит параллельно с обычной деятельностью компании, поэтапно, что в случае с technology push сопряжено с большими трудностями и рисками. Использование стратегии organization pull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technology push. Необходимо также отметить, что существуют проблемы, которые невозможно устранить точечными переделками процесса, то есть необходимо применять стратегию technology push. Приведем в качестве примера зашедший в тупик процесс сопровождения и развития семейства программных продуктов – компания терпит большие убытки, сопровождая уже поставленные продукты, инструментальные средства проекта безнадежно устарели и находятся в плачевном состоянии, менеджмент расстроен, все попытки руководства изменить процесс наталкиваются на непонимание коллектива, ссоры и конфликты. Возможно, что в таком случае без "революции" не обойтись. Еще одно различие обеих стратегий: в случае с organization pull, как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technology push. КЛАССИЧЕСКИЕ МОДЕЛИ ПРОЦЕССА Определение модели процесса. Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса (process model). Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить. Однако, сама идея модели процесса является одной из самых ранних в программной инженерии, когда считалось, что удачная модель – самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структуру команды и т.д.), которые должны быть определенно согласованы друг с другом. Поэтому и стали развиваться интегральные методологии разработки. Тем не менее, существует несколько классических моделей процесса, которые полезны на практике и которые будут рассмотрены ниже. Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности. Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, фаза сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы. Редко какой заказчик согласится первый раз увидеть результаты только после завершения проекта. С другой стороны, подрядчики предпочитают получать деньги постепенно, по мере того, как выполняются отдельные части работы. Таким образом, появляются фазы, позволяющие создавать и предъявлять промежуточные результаты проекта. Фазы полезны также безотносительно взаимодействия с заказчиком – с их помощью можно синхронизировать деятельность разных рабочих групп, а также отслеживать продвижение проекта. Примерами фаз может служить согласование с заказчиком технического задания, реализация определенной функциональности ПО, этап разработки, оканчивающийся сдачей системы на тестирование или выпуском альфа-версии. Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта, кодирование – программистом, тестирование – тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди. В рамках одной фазы может выполняться много различных видов деятельности. Кроме того, один вид деятельности может выполняться на разных фазах – например, тестирование: на фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при разработке и перед сдачей производить, собственно, само тестирование. На настоящий момент для сложного программного обеспечения используются многомерные модели процесса, в которых отделение фаз от видов деятельности существенно облегчает управление разработкой ПО. Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM – ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы. Водопадная (каскадная) модель  Была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования. Водопадная модель (англ. waterfall model) - это модель процесса разработки программного обеспечения, жизненный цикл которой выглядит как поток, последовательно проходящих фаз: разработка требований ПО, проектирование, реализация, тестирование, ввод в действие (использование) – см. рис. 1. Процесс разработки реализуется с помощью упорядоченной последовательности независимых шагов. Модель предусматривает, что каждый последующий шаг начинается после полного завершения выполнения предыдущего шага. На всех шагах модели выполняются вспомогательные и организационные процессы и работы, включающие управление проектом, оценку и управление качеством, верификацию и аттестацию, менеджмент конфигурации, разработку документации. В результате завершения шагов формируются промежуточные продукты, которые не могут изменяться на последующих шагах. Рис. 1. Достоинства модели: • стабильность требований  в течение всего жизненного цикла разработки; • на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; • определенность и понятность шагов модели и простота её применения; • выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие ресурсы (денежные. материальные и людские). Наконец, в рамках этой модели было введено прототипирование, то есть предлагалось разрабатывать систему дважды, чтобы уменьшить риски разработки. Первая версия – прототип – позволяет увидеть основные риски и обосновано принять главные архитектурные решения. На создание прототипа отводилось до одной трети времени всей разработки. В 70-80 годах прошлого века эта модель прочно укоренилась в разработке ПО в силу своей простоты и сходности с моделями разработки иных, не программных систем. В дальнейшем, в связи с развитием программной инженерии и осознанием итеративного характера процесса разработки ПО, эта модель активно критиковалась, практически, каждым автором соответствующих статей и учебников. Стало общепринятым мнение, что она не отражает особенностей разработки ПО. Недостатками водопадной модели являются: • Эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. • Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ПО зафиксированы в виде технического задания на все время его создания. • У пользователя нет возможности постепенно привыкнуть к системе. Процесс обучения происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию; • Каждая фаза является предпосылкой для выполнения последующих действий, что превращает такой метод в рискованный выбор для систем, не имеющих аналогов, т.к. он не поддается гибкому моделированию. Таким образом, пользователи зачастую получают ПП, не удовлетворяющий их реальным потребностям. Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Водопадная модель вошла в качестве составной части в другие модели и методологии, например, в MSF. Инкрементная модель (поэтапная модель с промежуточным контролем) Инкрементная модель (англ. increment — увеличение, приращение) является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикл (рис. 2). Данная модель подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию. Рис. 2 Поэтапная модель с промежуточным контролем Разработка программного обеспечения ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах, время жизни каждого из этапов растягивается на весь  период разработки. В начале работы над проектом определяются все основные требования к системе, подразделяются на более и менее важные. После чего выполняется разработка системы по принципу приращений, так, чтобы разработчик мог использовать данные, полученные в ходе разработки ПО. Каждый инкремент должен добавлять системе определенную функциональность. При этом выпуск начинают с компонентов с наивысшим приоритетом. Когда части системы определены, берут первую часть и начинают её детализировать, используя для этого наиболее подходящий процесс. В то же время можно уточнять требования и для других частей, которые в текущей совокупности требований данной работы были заморожены. Если есть необходимость, можно вернуться позже к этой части. Если часть готова, она поставляется клиенту, который может использовать её в работе. Это позволит клиенту уточнить требования для следующих компонентов. Затем занимаются разработкой следующей части системы. Ключевые этапы этого процесса — простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока не будет реализовано ПО во всей полноте. Жизненный цикл данной модели характерен при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат. Разработка версиями ведется в силу разного рода причин: • отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект; • отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки; • требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у её пользователей неприятие и только “затормозить” процесс перехода на новые технологии. Образно говоря, они могут просто “не переварить большой кусок, поэтому его надо измельчить и давать по частям”. Достоинства и недостатки этой модели (стратегии) такие же, как и у каскадной (классической модели жизненного цикла). Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора. Достоинства: • затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с каскадной моделью; • легче получить отзывы от клиента о проделанной работе — клиенты могут озвучить свои комментарии в отношении готовых частей и могут видеть, что уже сделано. Т.к. первые части системы являются прототипом системы в целом. • у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью. Недостатки модели: • менеджеры должны постоянно измерять прогресс процесса. В случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии; • структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям. Спиральная модель  Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной. Последовательность витков может быть такой: на первом витке принимается решение о целесообразности создания ПО, на следующем определяются системные требования, потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения (рис.3). Каждый виток имеет следующую структуру (секторы): • определение целей, ограничений и альтернатив проекта; • оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта; • разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО; • планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно. Рис. 3 Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение. Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших средств прототипирования может также сделать неудобным использование спиральной модели. Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль, – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО. Достоинства модели: • позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований; • допускает изменение требований при разработке программного обеспечения, что характерно для большинства разработок, в том числе и типовых; • в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в то же время разрешены итерации по всем фазам этой же модели; • позволяет получить более надежную и устойчивую систему. По мере развития программного обеспечения ошибки и слабые места обнаруживаются и исправляются на каждой итерации; • эта модель разрешает пользователям активно принимать участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий; • уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта; • обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества. Недостатки модели: • если проект имеет низкую степень риска или небольшие размеры, модель может оказаться дорогостоящей. Оценка рисков после прохождения каждой спирали связана с большими затратами; • жизненный цикл модели имеет усложненную структуру, поэтому может быть затруднено её применение разработчиками, менеджерами и заказчиками; • спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл, что отдаляет окончание работы над проектом; • большое количество промежуточных циклов может привести к необходимости в обработке дополнительной документации; • использование модели может оказаться дорогостоящим и даже недопустимым по средствам, т.к. время. затраченное на планирование, повторное определение целей, выполнение анализа рисков и прототипирование, может быть чрезмерным; • могут возникнуть затруднения при определении целей и стадий, указывающих на готовность продолжать процесс разработки на следующей и Основная проблема спирального цикла — определение момента перехода на следующий этап. Для её решения вводятся временные ограничения на каждый из этапов жизненного цикла и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планированиепроизводится на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков. Область применения спиральной модели Применение спиральной модели целесообразно в следующих случаях: • при разработке проектов, использующих новые технологии; • при разработке новой серии продуктов или систем; • при разработке проектов с ожидаемыми существенными изменениями или дополнениями требований; • для выполнения долгосрочных проектов; • при разработке проектов, требующих демонстрации качества и версий системы или продукта через короткий период времени; • при разработке проектов, для которых необходим подсчет затрат, связанных с  оценкой и разрешением рисков. СТАНДАРТЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ И ЗНАЧЕНИЕ МОДЕЛИРОВАНИЯ ПРИ РАЗРАБОТКЕ ПО Как отмечалось, по происхождению программные продукты бывают двух типов: заказные (под заказ конкретного потребителя) и коробочные (для массовой продажи на рынке). Для заключения контракта заказчик должен быть уверен, что разработчик справится и не завалит проект. В мировой практике промышленного производства гарантией успеха являются стандарты на производство продуктов и услуг и сертификация производителей на соответствие этим стандартам. Процесс стандартизации и сертификации давно вошел и в программную инженерию, где он составляет основу промышленного производства программных продуктов. При изготовлении коробочных продуктов стандартизация имеет не меньшее значение, т.к. она обеспечивает качество продуктов и продвижение их на рынок. Какие бывают стандарты? Среди всего многообразия стандартов принято выделять следующие основные типы стандартов: Корпоративные стандарты разрабатываются крупными фирмами (корпорациями) с целью повышения качества своей продукции. Такие стандарты разрабатываются на основе собственного опыта и с учетом требований мировых стандартов. Корпоративные стандарты не сертифицируются, но являются обязательными для применения внутри корпорации. В условиях рыночной конкуренции могут иметь закрытый характер. Отраслевые стандарты действуют в пределах организаций некоторой отрасли (министерства). Например, СНИП – строительные нормы и правила. Разрабатываются с учетом требований мирового опыта и специфики отрасли. Являются, как правило, обязательными для отрасли. Подлежат сертификации. Государственные стандарты (ГОСТы) принимаются государственными органами, в некоторых случаях имеют силу закона. Разрабатываются с учетом мирового опыта или на основе отраслевых стандартов. Могут иметь как рекомендательный, так и обязательный характер (стандарты безопасности). Для сертификации создаются государственные или лицензированные органы сертификации. Международные стандарты. Разрабатываются, как правило, специальными международными организациями на основе мирового опыта и лучших корпоративных стандартов. Имеют сугубо рекомендательный характер. Право сертификации получают организации (государственные и частные), прошедшие лицензирование в международных организациях. Кто разрабатывает стандарты программной инженерии? Основными разработчиками международных стандартов являются следующие организации: ISO - International Organization for Standardization – Международная организация по стандартизации. Наиболее представительная и влиятельная организация, разрабатывающая стандарты почти во всех областях деятельности, в том числе и в IT. ACM - Association for Computing Machinery –Ассоциация по вычислительной технике. Всемирная научная и образовательная организация в области вычислительной технике. Известна также и разработкой образовательных стандартов. SEI - Software Engineering Institute - Институт Программной Инженерии. Исследования в области программной инженерии с упором на разработку методов оценки и повышения качества ПО. Стандарты по качеству ПО и зрелости организаций, разрабатывающих ПО. PMI - Project Management Institute - Международный Институт Проектного Менеджмента (Управления Проектами). Некоммерческая организация, целью которой является продвижение, пропаганда, развитие проектного менеджмента в разных странах. PMI разрабатывает стандарты проектного менеджмента, занимается повышением квалификации специалистов. IEEE - Институт инженеров по электронике. Поддержка научных и практических разработок в области электроники и вычислительной техники. Большие вложения в разработку стандартов в этой области. См. также: Васютович В.В. Стандартизация в области информационных технологий. http://inform.alee.ru/item_541.html Основные стандарты программной инженерии Наиболее известными стандартами программной инженерии являются: ◦ ISO/IEC 12207 - Information Technology - Software Life Cycle Processes - Процессы жизненного цикла программных средств. Стандарт содержит определения основных понятий программной инженерии (в частности программного продукта и жизненного цикла программного продукта), структуры жизненного цикла как совокупности процессов, детальное описание процессов жизненного цикла. ◦ SEI CMM - Capability Maturity Model (for Software) - модель зрелости процессов разработки программного обеспечения. Стандарт отвечает на вопрос: «Какими признаками должна обладать профессиональная организация по разработке ПО?». Профессионализм организации определяется через зрелость процесса, применяемого этой организацией. Выделяются пять уровней зрелости процесса. ◦ ISO/IEC 15504 - Software Process Assessment - Оценка и аттестация зрелости процессов создания и сопровождения ПО. Является развитием и уточнением ISO 12207 и SEI CMM. Содержит расширенное по отношению ISO 12207 количество процессов жизненного цикла и 6 уровней зрелости процессов. Дается подробное описание схемы аттестации процессов, на основе результатов которой может быть выполнена оценка зрелости процессов и даны рекомендации по их усовершенствованию. ◦ PMBOK - Project Management Body of Knowledge - Свод знаний по управлению проектами. Содержит описания состава знаний по 9 разделам (областям знаний) управления проектами ◦ SWEBOK - Software Engineering Body of Knowledge - Свод знаний по программной инженерии - содержит описания состава знаний по 10 разделам (областям знаний) программной инженерии. ◦ ACM/IEEE CC2001 - Computing Curricula 2001 – Академический образовательный стандарт в области компьютерных наук. Выделены 4 основных раздела компьютерных наук: Computer science, Computer engineering, Software engineering и Information systems, по каждому из которых описаны области знаний соответствующего раздела, состав и планы рекомендуемых курсов. Значение моделирования при разработке ПО Компания, занимающаяся производством программного обеспечения, может преуспевать только в том случае, если выпускаемая ею продукция всегда отличается высоким качеством и разработана в соответствии с запросами пользователей. Фирма, которая способна выпускать такую продукцию своевременно и регулярно, при максимально полном и эффективном использовании всех имеющихся человеческих и материальных ресурсов будет стабильно процветать. Из сказанного следует, что основным продуктом такой компании является именно первоклассное программное обеспечение, удовлетворяющее повседневным нуждам пользователей. Центральным элементом деятельности, ведущей к созданию первоклассного программного обеспечения, является моделирование. Модели позволяют нам наглядно продемонстрировать желаемую структуру и поведение системы. Они также необходимы для визуализации и управления ее архитектурой. Модели помогают добиться лучшего понимания создаваемой нами системы, что зачастую приводит к ее упрощению и возможности повторного использования. Наконец, модели нужны для минимизации риска. Значение моделирования Неудачные проекты заканчиваются крахом в силу самых разных причин, а вот успешные, как правило, имеют много общего. Хотя успех программного проекта обеспечивается множеством разных слагаемых, одним из общих является применение моделирования. Моделирование - это устоявшаяся и повсеместно принятая инженерная методика. Мы строим архитектурные модели зданий, чтобы помочь их будущим обитателям во всех подробностях представить себе готовый продукт. Иногда прибегают даже к математическому моделированию зданий, чтобы учесть влияние сильного ветра или землетрясения. Итак, что же такое модель? Попросту говоря, она является упрощенным представлением реальности. Модель - это чертеж системы: в нее может входить как детальный план, так и более абстрактное представление системы "с высоты птичьего полета". Хорошая модель всегда включает элементы, существенно влияющие на результат, и не включает те, которые малозначимы на данном уровне абстракции. Каждая система может быть описана с разных точек зрения, для чего используются различные модели, каждая из которых, следовательно, является семантически замкнутой абстракцией системы. Модель может быть структурной, подчеркивающей организацию системы, или поведенческой, то есть отражающей ее динамику. Моделирование позволяет решить четыре различных задачи (см. главу 2): • визуализировать систему в ее текущем или желательном для нас состоянии; • определить структуру или поведение системы; • получить шаблон, позволяющий затем сконструировать систему; • документировать принимаемые решения, используя полученные модели. Моделирование предназначено не только для создания больших систем. Даже программный эквивалент собачьей конуры выиграет от этого процесса. Чем больше и сложнее система, тем большее значение приобретает моделирование при ее разработке. Дело в том, что моделировать сложную систему необходимо, поскольку иначе мы не можем воспринять ее как единое целое. Множественность точек зрения При разработке архитектуры ПО важным оказывается совмещение множества точек зрения. ПО оказывается настолько сложным, что его архитектуру не построить как единую модель – множество отдельных аспектов должны быть представлены в архитектуре, их связи сложны и плохо выразимы в явном виде. Полезнее оказывается создание множества моделей, созданных с разных точек зрения. Причина множественности точек зрения при разработке ПО. Умение рассматривать предмет с разных точек зрения является важнейшей философией успешной практики при работе с большими объемами разнородной и сложной информации. Посмотрим на разработку ПО и то, почему там востребованы разные взгляды на процесс, систему и т.д. Это происходит, прежде всего, из-за разных видов деятельности процесса разработки ПО (см. рис.1). При составлении функциональных требований к ПО обращают внимание на то, какая именно функциональность должна быть реализована, но при этом опускаются принципы и детали реализации. При проектировании, наоборот, на первое место выходят принципы реализации ПО. А при тестировании детали реализации снова неважны — на ПО смотрят как на черный ящик, реализующий (не важно каким способом) некоторый набор пользовательской функциональности. При развертке у заказчика на ПО смотрят как на набор файлов, хранилищ данных и т. д. Рис. 1. Разные виды деятельности – разные взгляды на систему Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры, технические писатели, менеджеры, заказчик, пользователи, продавцы-маркетологи и т. д. (см. рис. 2). Для всех этих специалистов нужна разная информация о программной системе. Представьте, что произойдет, если, например, продавцу или заказчику-непрограммисту в ответ на просьбу получше ознакомиться с ПО вы дадите почитать программные коды… Рис. 2. Разные специалисты – разные взгляды на систему Множественность точек зрения происходит также от того, что нет единых стандартов и норм разработки ПО. То есть разработка ПО во многом "state of art" (состояние искусства). Часто приходится изобретать новую точку зрения моделирования прямо по ситуации – чтобы именно этот эксперт тебя понял, чтобы именно эти особенности системы были отражены. Часто здесь – как в лотерее: создается несколько описаний системы с разных точек зрения, какое-то оказывается удачным и его все используют в дальнейшем. Итак, разные виды деятельности при разработке ПО, разные категории специалистов, задействованные в программном проекте, и уникальность каждой конкретной ситуации при разработке — все это приводит к созданию и использованию различных моделей, выполненных с разных точек зрения. ВВЕДЕНИЕ В ЯЗЫК UML Предисловие Этот язык является итогом развития средств схематического описания программных систем, которые развивались с блок-схем, предложенных еще фон Нейманом в конце 40-х годов. Он предполагал, что эти схемы станут высокоуровневым языком ввода алгоритмов в вычислительные машины, но эволюция языков программирования пошла по другому пути (пути текстовых языков). Тем не менее блок-схемы получили распространение при спецификации и документировании ПО, были стандартизованы, однако широкого практического применения не получили. В конце 60-х годов, в связи с поиском новых средств разработки ПО, рождением программной инженерии и общими следованиями в области проектирования и разработки искусственных систем появился термин структурный анализ (structured analysis) систем. Термин был введен ученым из MIT, Дугласом Россом, который также предложил диаграммный метод анализа и проектирования больших искусственных систем. Метод назывался SADT (Structured Analisys and Design Technique), стал основой серии военных стандартов США серии IDEF и широко распространился в индустрии. Однако диаграммный язык в SADT был очень скромным – набор блоков и связей между ними, с поддержкой декомпозиции блоков. В 70-х годах, в связи с массовым выходом ПО на свободный рынок (то есть программные системы стали создаваться не только в военной области, для крупного бизнеса, но также для среднего и малого бизнеса) структурный анализ стал бурно эволюционизировать – набор диаграмм обогатился диаграммами состояний и переходов, сущность-связь, потоков данных и т.д. С развитием объектно-ориентированных средств разработки (конец 80-х – середина 90-х) структурный анализ превратился в объектно-ориентированный анализ и проектирование. Появилось большое количество методологий, и постепенно сложился единый язык моделирования, который и был закреплен в стандарте UML (Unified Modeling Language). Произошло это в 1997 году. Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта. Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем. UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Несмотря на свои достоинства, UML - это всего лишь язык; он является одной из составляющих процесса разработки программного обеспечения, и не более того. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру. Моделирование необходимо для понимания системы. При этом единственной модели никогда не бывает достаточно. Напротив, для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки. Словарь и правила такого языка, как UML, объясняют, как создавать и читать хорошо определенные модели, но ничего не сообщают о том, какие модели и в каких случаях нужно создавать. Это задача всего процесса разработки программного обеспечения. Хорошо организованный процесс должен подсказать вам, какие требуются артефакты, какие ресурсы необходимы для их создания, как можно использовать эти артефакты, чтобы оценить выполненную работу и управлять проектом в целом. UML - это язык визуализации Явная модель облегчает общение. Некоторые особенности системы лучше всего моделировать в виде текста, другие - графически. На самом деле во всех интересных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика (см. "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой. UML - это язык специфицирования В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения. UML - это язык конструирования UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования. Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации. Обратное проектирование не представляет собой ничего необычного. Если вы не закодировали информацию в реализации, то эта информация теряется при прямом переходе от моделей к коду. Поэтому для обратного проектирования необходимы как инструментальные средства, так и вмешательство человека. Сочетание прямой генерации кода и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между обоими представлениями. Помимо прямого отображения в языки программирования UML в силу своей выразительности и однозначности позволяет непосредственно исполнять модели, имитировать поведение систем и контролировать действующие системы. UML - это язык документирования Компания, выпускающая программные средства, помимо исполняемого кода производит и другие артефакты, в том числе следующие: • требования к системе; • архитектуру; • проект; • исходный код; • проектные планы; • тесты; • прототипы; • версии, и др. Упомянутые артефакты - это не просто поставляемые составные части проекта; они необходимы для управления, для оценки результата, а также в качестве средства общения между членами коллектива во время разработки системы и после ее развертывания. UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями. Где используется UML Язык UML предназначен прежде всего для разработки программных систем. Его использование особенно эффективно в следующих областях: • информационные системы масштаба предприятия; • банковские и финансовые услуги; • телекоммуникации; • транспорт; • оборонная промышленность, авиация и космонавтика; • розничная торговля; • медицинская электроника; • наука; • распределенные Web-системы. Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств. СТРУКТУРА ЯЗЫКА UML Общая структура UML показана на следующем рисунке. Рис. Структура UML   Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний. Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста. Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения. Нотация представляет собой графическую интерпретацию семантики для ее визуального представления. Концептуальная модель UML Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы. Усвоив эти элементы, вы сумеете читать модели на UML и самостоятельно создавать их. Строительные блоки UML Словарь языка UML включает три вида строительных блоков: • сущности; • отношения; • диаграммы. Сущности - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей. В UML определено три типа сущностей: - структурная – абстракция, являющаяся отражением концептуального или физического объекта; - группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы; - поясняющая (аннотационная) – комментарий к элементу диаграммы. Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей. Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции, как показано на рис. 1. Рис. 1 Объект (object) – это абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением (рис. 2). С точки зрения UML объекты являются экземплярами Рис. 2 Актер (actor) - внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач (рис. 3). Таким образом актер – это внешний источник или приемник информации. - Инженер службы пути Рис. 3 Прецедент (Use case) - это описание последовательности выполняемых системой действий, которая приводит к значимому для какого-то определенного актера (Actor) результату. Прецедент применяется для структурирования поведенческих сущностей модели. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя, как показано на рис. 4. Рис. 4. Прецеденты Состояние (state) (Автомат (State machine)) - это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход). Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, подсостояния (см. рис. 5). Рис. 5 Состояния Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя, как показано на рис. 6. Интерфейс редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту. Рис. 6 iРасчет Кооперация (Collaboration) определяет взаимодействие; она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. Кооперация, следовательно, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях; таким образом, они являются реализацией образцов поведения, формирующих систему. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, в который обычно заключено только имя, как показано на рис. 7. Рис. 7 Кооперации Компонент (Component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рис. 8. Рис. 8 Компоненты Узел (Node) - это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Графически узел изображается в виде куба, обычно содержащего только имя, как показано на рис. 9. Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи Рис. 9 Узлы Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет. Пакеты (Packages) представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и даже другие группирующие сущности. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда - содержимое (см. рис. 10). Рис. 10 Пакеты Пакеты - это основные группирующие сущности, с помощью которых можно организовать модель UML. Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы. Пакет (package) – это общий механизм группировки элементов. В отличие от компонента, пакет чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель. Раздел деятельности (activity partition) - группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.) Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание (Note). Примечание - это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как показано на рис. 11. Рис. 11 Примечания Этот элемент является основной аннотационной сущностью, которую можно включать в модель UML. Чаще всего примечания используются, чтобы снабдить диаграммы комментариями или ограничениями, которые можно выразить в виде неформального или формального текста. Существуют вариации этого элемента, например требования, где описывают некое желательное поведение с точки зрения внешней по отношению к модели. Присоединяется к комментируемому элементу штриховой линией. Отношения В языке UML определены четыре типа отношений: • зависимость; • ассоциация; • обобщение; • реализация. Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей. Зависимость (Dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку (см. рис. 12). Рис. 12 Зависимости Ассоциация (Association) - структурное отношение, описывающее совокупность связей; связь - это соединение между объектами. Разновидностью ассоциации является агрегирование (Aggregation) - так называют структурное отношение между целым и его частями. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей. На рис. 13 показан пример отношений этого типа. Рис. 13 Ассоциации Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на родителя, как показано на рис. 14. Рис. 2.14 Обобщения Наконец, реализация (Realization) - это семантическое отношение между классификаторами, при котором один классификатор определяет "контракт", а другой гарантирует его выполнение. Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с незакрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости (см. рис. 15). Рис. 15 Реализации Для ассоциации и агрегации может указываться кратность (англ. multiplicity), характеризующая общее количество экземпляров сущностей, участвующих в отношении. Она, как правило, указывается с каждой стороны отношения около соответствующей сущности. Кратность может указываться следующими способами: - * – любое количество экземпляров, в том числе и ни одного; - целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5); - диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5); - диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*); - перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*). Если кратность не указана, то принимается ее значение, равное 1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается равной 1. Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. Каждый вид диаграмм является типом моделей, реализующим определенную точку зрения на программную систему. Виды диаграмм не являются строго обязательными в UML – их можно перемешивать, создавать свои собственные виды диаграмм. Тем не менее, стандартные виды диаграмм являются определенным достоянием программной инженерии, так как отражают опыт многих исследователей и практиков. Таким образом, в UML выделяют девять типов диаграмм: • диаграммы классов; • диаграммы объектов; • диаграммы прецедентов; • диаграммы последовательностей; • диаграммы кооперации; • диаграммы состояний; • диаграммы действий; • диаграммы компонентов; • диаграммы развертывания. В своей совокупности эти виды диаграмм позволяют передать наиболее важные решения, касающиеся системы в целом, а по отдельности каждый из них акцентирует внимание на одном ее аспекте, рассмотрение которого таким образом упрощается. ТИПИЧНЫЕ ПРИЕМЫ МОДЕЛИРОВАНИЯ Как показано на рис. 1, архитектура программной системы наиболее оптимально может быть описана с помощью пяти взаимосвязанных видов или представлений, каждый из которых является одной из возможных проекций организации и структуры системы и заостряет внимание на определенном аспекте ее функционирования. Рис. 1 Моделирование системной архитектуры Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические - диаграммами взаимодействия, состояний и действий. Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид поддерживает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические - диаграммами взаимодействия, состояний и действий. Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы. Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические - с помощью диаграмм взаимодействия, состояний и действий. Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий. При моделировании системы с различных точек зрения вы фактически конструируете ее сразу в нескольких измерениях. Правильный выбор совокупности видов или представлений позволит задать нужные вопросы, касающиеся системы, и выявить риск, который необходимо учесть. Если же виды выбраны плохо или вы сосредоточились только на одном из них в ущерб остальным, то возрастает опасность не заметить или отложить на будущее такие вопросы, пренебрежение которыми рано или поздно поставит под угрозу весь проект. Как правило, при разработки ПС требуются не все диаграммы. Допустим, если вы моделируете простое приложение, выполняемое на одном компьютере, могут потребоваться только нижеперечисленные диаграммы: • вид с точки зрения вариантов использования - диаграммы прецедентов; • вид с точки зрения проектирования - диаграммы классов (для структурного моделирования) и диаграммы взаимодействия (для моделирования поведения); • вид с точки зрения процессов - не требуется; • вид с точки зрения реализации - не требуется; вид с точки зрения развертывания - также не требуется. Если же разрабатываемая система реактивна или относится к управлению рабочим процессом, то для моделирования ее поведения понадобятся соответственно диаграммы состояний и действий. Если система построена на архитектуре "клиент/сервер", то стоит включать в работу диаграммы компонентов и развертывания для моделирования конкретных физических деталей реализации. Наконец, моделируя сложную распределенную систему, используйте все имеющиеся в UML диаграммы. Они позволят выразить ее архитектуру и связанный с проектом технический риск. Вам потребуется следующее: • вид с точки зрения прецедентов - диаграммы прецедентов и диаграммы действий (для моделирования поведения); • вид с точки зрения проектирования - диаграммы классов (структурное моделирование), диаграммы взаимодействия (моделирование поведения), диаграммы состояния (моделирование поведения); • вид с точки зрения процессов - снова диаграммы классов (структурное моделирование) и диаграммы взаимодействия (моделирование поведения); • вид с точки зрения реализации - диаграммы компонентов; • вид с точки зрения развертывания - диаграммы развертывания. Хорошо структурированная диаграмма обладает следующими свойствами: • заостряет внимание на одном аспекте некоторого представления системы; • содержит только элементы, существенные для понимания этого аспекта; • содержит детали, соответствующие выбранному уровню абстракции (не обременена деталями, без которых можно обойтись); • не настолько лаконична, чтобы ввести читателя в заблуждение относительно важных аспектов семантики. Изображая диаграмму, воспользуйтесь нижеприведенными рекомендациями: • дайте диаграмме имя, соответствующее ее назначению; • расположите элементы так, чтобы свести к минимуму число пересечений; • пространственно организуйте элементы так, чтобы семантически близкие сущности располагались на диаграмме рядом; • используйте примечания и цвет, чтобы привлечь внимание читателя к важным особенностям диаграммы. ДИАГРАММЫ ПРЕЦЕНДЕНТОВ (ДИАГРАММЫ ИСПОЛЬЗОВАНИЯ) С чего начинается процесс проектирования системы? С описания требований к системе. Требование - это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Думаю, многим из Вас известен документ, который называется техническое задание. Техническое задание - основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе! Техническое задание - вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов: • диаграммы прецедентов; • нефункциональные требования. Разработка диаграммы вариантов использования преследует цели: • определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы; • сформулировать общие требования к функциональному поведению проектируемой системы; • разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей; • подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Диаграмма вариантов использования является исходным концептуальным представлением, или концептуальной моделью системы, в процессе ее проектирования и разработки. С помощью прецедентов можно описать поведение разрабатываемой системы, не определяя ее реализацию. Таким образом, они позволяют достичь взаимопонимания между разработчиками, экспертами и конечными пользователями продукта. Суть диаграммы прецедентов состоит в следующем: проектируемая система представляется в виде множества сущностей, или актеров, взаимодействующих с системой с помощью так называемых прецедентов. При этом актером (actor), или действующим лицом, называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актер может рассматриваться как некая отдельная роль относительно конкретного варианта использования. Стандартным графическим обозначением актера на диаграммах является фигурка "человечка", под которой записывается конкретное имя актера (рис. 1). Рис. 1. Графическое обозначение актера Несмотря на "человеческий" вид этого обозначения, не следует забывать, что актеры - это не обязательно люди. Актером, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д. На диаграммах прецедентов обычно применяется именно "человекоподобная" форма актера, но на других диаграммах, и особенно в случаях, когда актер имеет атрибуты, которые важно показать, используется изображение актера как класса со стереотипом <> (рис. 2): Рис. 2 Еще один тип элементов, встречающийся на диаграммах прецедентов, более того, давший им название, - это собственно прецеденты, или варианты использования. Прецедент - это описание набора последовательных событий (включая возможные варианты), выполняемых системой, которые приводят к наблюдаемому актером результату. Прецеденты описывают сервисы, предоставляемые системой актерам, с которыми она взаимодействует. Причем прецедент никогда не объясняет, "как" работает сервис, а только описывает, "что" делается. Прецедент - это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Прецедент обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 3). Рисунок 3 - Графическое обозначение варианта использования Каждый прецедент соответствует отдельному сервису, который предоставляет моделируемую сущность или систему по запросу пользователя (актера), т.е. определяет способ применения этой сущности. Сервис, который инициализируется по запросу пользователя, представляет собой законченную последовательность действий. Это означает, что после того как система закончит обработку запроса пользователя, она должна возвратиться в исходное состояние, в котором готова к выполнению следующих запросов. Создание диаграммы обычно выполняется в такой последовательности: 1. Определение действующих лиц. 2. Определение прецедентов. 3. Составление описания каждого прецедента. 4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области). Вначале требования оформляются в виде обычного текстового документа, который создается или самим пользователем, или пользователем и разработчиком вместе. Далее требования оформляют в виде таблицы. В левую колонку помещают прецеденты, а в правую - действующих лиц, участвующих в прецеденте. Рассмотрим пример. Секретарь размещает на сервере меню обеденных блюд на неделю. Сотрудники должны иметь возможность ознакомиться с меню и сделать заказ, выбрав блюда на каждый день следующей недели. Офис-менеджер должен иметь возможность сформировать счет и оплатить его. Система должна быть написана на ASP.NET. Такое вот нехитрое интернет-приложение для автоматизации заказов обедов в офис. Думаем, здесь все понятно. Таблица с описанием требований может быть, например, такой: Прецедент Действующее лицо разместить меню секретарь ознакомиться с меню сотрудник, секретарь, офис-менеджер сделать заказ сотрудник, секретарь, офис-менеджер сформировать счет офис-менеджер оплатить счет офис-менеджер Здесь нигде не сказано о том, что система должна быть написана на ASP.NET. Почему - понятно: это ведь нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. В данном случае, создавая модель прецедентов, говоря о действующих лицах, можно применить обобщение. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис. 4): Рис. 4 У нас есть пример диаграммы. Итак, какие же элементы мы на ней видим? Первое, что бросается в глаза, - большой прямоугольник, внутри которого размещаются эллипсы, обозначающие, как мы уже поняли, прецеденты. В верхней части прямоугольника указано название моделируемой системы, а называют его рамками системы (system boundary, subject boundary), контекстом или просто системой. Этот элемент диаграммы показывает границу между тем, что вы как аналитик показали в виде прецедентов (внутри этих рамок), и тем, что вы изобразили как действующие лица (вне их). Чаще всего таким прямоугольником показывают границы самой моделируемой системы. То есть внутри границы находятся прецеденты - тот функционал, который реализует система (и в этом смысле прецеденты могут рассматриваться как представления подсистем и классов модели), а снаружи - действующие лица: пользователи и другие внешние сущности, взаимодействующие с моделируемой системой. Следует сказать, что рамки системы на диаграммах прецедентов изображают довольно редко, т. к. они неявно подразумеваются самой диаграммой. По сути, этот элемент не привносит в диаграмму какой-либо дополнительной значимой информации, так что его использование - дело вкуса аналитика. Появление рамок системы на диаграмме прецедентов чаще всего диктуется особенностями персонального стиля проектирования. Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей - это действующие лица (актеры, actors) и прецеденты. Начнем с актеров. Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин "актер". В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово "актер"? Да, конечно же – слово "роль"! Итак, какой же смысл вкладывают в понятие актера? Актер - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью (системой, подсистемой, классом). Актер может быть человеком, другой системой, подсистемой или классом, которые представляют нечто за пределами рассматриваемой сущности. Актеры "общаются" с системой путем обмена сообщениями. Четко выделив актеров, вы тем самым ясно определяете границу между тем, что внутри системы, и тем, что снаружи, - рамки системы. С системой актеры, как мы уже сказали, общаются через сообщения, но если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты. Один и тот же актер может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными актерами. Ассоциации между актером и прецедентом всегда бинарные - т. е. представляют отношения типа "один к одному", использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один актер может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций - по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Смысл этого обозначения вполне понятен: это направленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д. И еще - актеры не могут быть связаны друг с другом. Единственное допустимое отношение между актерами – обобщение  ( наследование ). Опять-таки, в нашем примере с заказом обедов в офис, вы могли увидеть именно такой вид отношений между актерами. Это не значит, что в реальной жизни офис-менеджер и секретарь (да и вообще любые два сотрудника) не могут общаться: просто при создании модели прецедентов такое общение не попадает в область наших интересов, считается несущественным. Имя прецедента обычно намного длиннее имен других элементов модели. Почему это так, в принципе, понятно: имя прецедента описывает взаимодействие актера с системой, говорит о том, какими сообщениями они обмениваются между собой. В нашем примере с заказом обедов мы видели несколько прецедентов и нетрудно заметить, что имя прецедента - это, скорее, название сценария, воспроизводящегося в ходе взаимодействия актера с системой. Причем это всегда описание с точки зрения актера, описание услуг, предоставляемых системой пользователю. Приведем пример простейшей диаграммы, иллюстрирующей сказанное нами об обозначениях прецедента (рис. 5). Рис. 5 В этом примере пассажир может купить в сервисной кассе билет на некоторый вид транспорта. Покупка билета - это название сценария, по которому актер (пассажир) может взаимодействовать с системой (кассой). Заметьте, это не описание сценария, а именно название - оно говорит нам, что делает актер в процессе взаимодействия, но не говорит, как именно! И еще - прецеденты определяют непересекающиеся сценарии поведения. Выполнение одного прецедента не может быть прервано в результате работы другого прецедента. Другими словами, выполнение одного прецедента не может быть прервано в результате событий или действий, вызванных выполнением другого прецедента. Прецеденты выступают как атомарные транзакции, выполнение которых не может быть прервано. Сценарии Сценарий - это конкретная последовательность действий, иллюстрирующая поведение. Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их изображают в виде " листа бумаги ", на котором написано имя файла, - прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 6). Рис. 6 Сценарии могут быть записаны в различных формах. Это может быть структурированный, но неформализованный текст, формализованный структурированный текст, псевдокод, таблица. Каждый сценарий описывает в повествовательной форме завершенное, конкретное взаимодействие, имеющее с точки зрения пользователя определенную цель. Если рассматривать табличную форму представления сценария, то линия, разделяющая левый и правый столбцы таблицы, символизируют собой границу, отделяющую действия пользователя от ответных действий системы. Табличная форма особо подчеркивает участие пользователя, что является очень важным аспектом при разработке пользовательского интерфейса. Вот пример простого (неформализованного) текстового описания сценария. Пользователь вводит логин, пароль, адрес электронной почты и код подтверждения и нажимает кнопку "Далее". Система запрашивает ввод проверочного кода. Пользователь вводит код и нажимает кнопку "Далее". Система проверяет соответствие кода изображенному на картинке. Не правда ли, знакомая процедура? Да, это описание регистрации пользователя на некотором сайте. Правда, не совсем полное: не рассмотрены случаи, когда выбранный пользователем логин уже занят, адрес электронной почты введен неправильно, пароль не удовлетворяет требованиям или код не соответствует изображенному на картинке. О таких случаях - альтернативных сценариях - мы поговорим чуть позже. А вот тот же сценарий в табличном представлении: Действия пользователя Реакция системы Ввод логина, пароля, адреса электронной почты и нажатие кнопки "Далее" Запрос ввода проверочного кода Ввод проверочного кода и нажатие кнопки "Далее" Проверка кода на соответствие изображенному на картинке Этот сценарий можно детализировать - например, прежде чем попросить ввести проверочный код, система отображает картинку, на которой этот самый код изображен. Т. е. запрос на ввод кода включает в себя вывод картинки с упомянутым кодом. А пока попробуем ответить на вопрос, а именно: как связаны понятия сценария и прецедента. Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать путем описания потока действий или событий в текстовой форме - в виде, понятном для "постороннего" (не занятого в непосредственной разработке системы) читателя. А ведь такое описание - это и есть сценарий! Таким образом, сценарии специфицируют прецеденты. Сценарии, да и вообще диаграммы прецедентов (дополненные сценариями) являются отличным средством общения между разработчиками и заказчиком, причем, в силу простоты нотации, - средством, понятным обеим сторонам. Актеры и прецеденты находятся в определенных отношениях. В языке UML существует несколько стандартных видов отношений между актерами и прецедентами: • отношение ассоциации, или association relationship; • отношение обобщения, или generalization relationship; • отношение расширения, или extend relationship; • отношение включения, или include relationship. На рисунке 7 приведен пример графического представления отношения ассоциации между актером и прецедентом Рис.7 Как видите, для ассоциации на диаграмме проставлена кратность и ее смысл вполне понятен, но все же о кратности следует поговорить отдельно. Один прецедент определяет несколько сценариев, каждый из которых представляет один из возможных вариантов определяемого прецедентом потока событий. Сценарии так же соотносятся с прецедентами, как экземпляры класса, т.е. сценарий - это экземпляр прецедента, как объект - экземпляр класса. Система может содержать, например, несколько десятков прецедентов, каждый из которых, в свою очередь, может разворачиваться в десятки сценариев. Как правило, прецедент описывает не одну последовательность действий, а множество, и выразить все детали рассматриваемого прецедента с помощью одной последовательности действий обычно не получается. Практически для любого прецедента можно выделить основной сценарий, описывающий "нормальную" последовательность действия, и вспомогательные, описывающие альтернативные последовательности, которые инициируются в случае возникновения определенных условий. Отношение обобщения. Изображается обобщение линией с "не закрашенной" треугольной стрелкой на конце. Обобщение - это отношение между предком и потомком, и стрелка всегда указывает на предка. Если вспомнить, что потомки наследуют (используют) свойства предка, то вполне логично вспоминается наше утверждение о том, что стрелки в UML всегда направлены в сторону того, от кого что-то требуют, чьими сервисами пользуются (рис. 8). Рис. 8 После того как мы выделили и описали каждый прецедент, мы должны просмотреть их все на предмет наличия одинаковых действий - поискать, а не выполняются ли (используются) некоторые действия совместно несколькими прецедентами. Этот совместно используемый фрагмент лучше описать в отдельном прецеденте. Таким образом, мы уменьшим избыточность модели за счет применения обобщения прецедентов (иногда, правда, говорят не об обобщении, а об использовании прецедентов; почему - сейчас поймете). Как это и "положено" при наследовании, экземпляры обобщенных прецедентов (потомков) сохраняют поведение, присущее обобщающему прецеденту (предку). Обобщение может использоваться для создания различных разновидностей актеров (рис. 9). Актеры-потомки наследуют от предка базовые характеристики и дополняют их своей спецификой. Точно так же прецедент-потомок наследует поведение и семантику прецедента-родителя и дополняет его поведение. Рис. 9. Пример графического изображения отношения обобщения между экторами Следующий вид отношений между прецедентами - включение. Отношение включения означает, что в некоторой точке базового прецедента содержится поведение другого прецедента. Включаемый прецедент не существует сам по себе, а является всего лишь частью объемлющего прецедента. Таким образом, базовый прецедент как бы заимствует поведение включаемых, раскладываясь на более простые прецеденты. Например, когда мы покупаем в магазине некоторую вещь, в момент считывания кассиром штрих-кода обновляется состояние базы данных товаров, имеющихся в наличии, - количество наличных единиц купленного товара уменьшается. То же самое действие выполняется и в том случае, если купленный товар оказался бракованным, непригодным к использованию или попросту нам не понравился: состояние упомянутой базы данных вновь обновляется - но теперь уже в сторону увеличения количества наличных единиц определенного товара. Т. е. оба этих действия - и покупка, и возврат - содержат (включают в себя) такое действие, как обновление содержимого БД. А как же изображается включение? Да очень просто - как зависимость со стереотипом <>. При этом стрелка направлена, естественно, в сторону включаемого прецедента. Этот факт легко объяснить, если вспомнить утверждение, которое мы уже несколько раз использовали: стрелка всегда направлена в сторону того элемента, от которого что-то требуется, чьими сервисами пользуются. А если считать, что объемлющий прецедент включает в себя, заимствует (использует) поведение включаемых прецедентов, становится ясно, что стрелка может быть направлена только таким образом. А вот и диаграмма, иллюстрирующая вышесказанное, которую мы позаимствовали из Zicom Mentor (рис. 10): Рис. 10. Как хорошо видно из этого примера, использование включения позволяет избежать многократного описания одного и того же набора действий - общее поведение можно просто описать в виде прецедента, включаемого в базовые. На очереди - отношение расширения. Чтобы уяснить себе смысл расширения, представим себе, что мы говорим об оплате некоторого купленного нами товара. Мы можем оплатить товар наличными, если сумма не превышает $ 100. Или оплатить кредитной картой, если сумма находится в пределах от $ 100 до $ 1000. Если же сумма превышает $ 1000, нам придется брать кредит. Таким образом, мы расширили понимание операции оплаты купленного товара и на случаи, когда используются другие средства оплаты, нежели наличные. Но сами эти случаи возникают только при строго определенных условиях: когда цена товара попадает в определенные рамки. Расширение дополняет прецедент другими прецедентами, "срабатывающими" при некоторых условиях, - просто добавляет в исходный прецедент последовательность действий, содержащуюся в другом прецеденте.  Отношение расширения прецедента А к прецеденту В означает, что экземпляр прецедента В может включать в себя (при определенных условиях, которые могут быть описаны в расширении) поведение, описанное в прецеденте А. Пример показан на следующей диаграмме (рис. 11): Рис. 11 Однако в приведенном примере не видно, при каких именно условиях человек использует каждый конкретный способ оплаты. В то же время, при моделировании с использованием расширения можно указать как условия осуществления расширенного поведения, так и место - точку расширения прецедента, в которой подключаются действия из расширяющих прецедентов. Точка расширения описывается в дополнительном разделе прецедента, отделенном от его названия горизонтальной линией - точно так же, как в отдельных разделах перечисляются атрибуты класса и его операции. Ниже показан пример описания точки расширения, позаимствованный нами из Zicom Mentor (рис. 12). Рис. 12. В этом примере регистрация пассажиров авиарейса включает в себя контроль службы безопасности, а при условии (указанном в примечании после служебного слова "Condition:"), что человек часто летает и салон переполнен (обратите внимание на оператор AND, говорящий об одновременности выполнения условий), класс билета может быть повышен, например, с "эконом" до "бизнес-класса". Причем такой апгрейд может произойти только после того, как билет предъявлен на стойку регистрации - это и есть точка расширения. Она описана (ее имя указано) в дополнительном разделе прецедента после служебной фразы "Extension points:". Предваряя вопрос читателя, скажем, что прецедент может иметь сколь угодно много точек расширения. А сопоставить конкретный расширяющий прецедент с определенной точкой расширения можно, прочитав условия расширения, указанные в комментариях, - само условие записывается после служебного слова "Condition:" в фигурных скобках, за которыми идет служебная фраза "Extension point:", и после нее указывается имя точки расширения. Посмотрите еще раз на наш пример с регистрацией пассажиров в аэропорту и убедитесь сами, что все это очень просто! Некоторое недоумение может вызвать то, что стрелка направлена всегда в сторону расширяемого прецедента. Но и это легко объяснить с точки зрения нашего тезиса, что "стрелка всегда указывает на того, от которого что-то требуют": ведь для того, чтобы прецедент был расширен, нужно, чтобы он попал в точку расширения и проверилась истинность условий - только тогда действия, содержащиеся в расширяющем прецеденте, смогут быть добавлены в последовательность действий исходного прецедента. Так что все правильно - от расширяемого прецедента требуется точка расширения и проверка условий, потому и стрелка направлена к нему. Выводы • Модель прецедентов позволяет описать систему на концептуальном уровне. • Диаграммы прецедентов - отличное средство коммуникаций между экспертами, пользователями и разработчиками, а также основа для тестирования создаваемой системы. • Прецедент - это описание набора последовательных событий (включая возможные варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату. • Эктор - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью. • Прецеденты (как и экторы) могут быть генерализованы, т. е. наследовать и дополнять свойства своих предков. • Прецеденты также могут вступать между собой в отношения включения и расширения, что позволяет разложить прецеденты на более простые составляющие и выделить необязательное поведение. • Каждый прецедент реализуется одной или несколькими кооперациями. • Сценарии специфицируют прецеденты, а диаграммы взаимодействий визуализируют сценарии. ДИАГРАММА КЛАССОВ Общие сведения Центральное место в объектно-ориентированном анализе и проектировании (ООАП) занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Вообще-то, понятие класса Вам должно быть знакомо, но, пожалуй, не лишним будет поговорить о классах еще раз. Классики о классах говорят очень просто и понятно: Класс представляет собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой. В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Атрибут — это свойство класса, которое может принимать множество значений. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. Продолжая тему, скажем, что классы - это строительные блоки любой объектно-ориентированной системы. Они представляют собой описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. При проектировании объектно-ориентированных систем диаграммы классов обязательны. Диаграмма классов - это набор статических, декларативных элементов модели. Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки. Далее поговорим более детально о диаграмме классов. Там мы подробно разберем нотацию этого вида диаграмм и познакомимся с улучшениями, внесенными текущей версией UML. Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части. В первой части указывается название класса. Как правило, имя класса состоит из одного, максимум двух слов. Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области. Третья часть содержит перечень операций, отражающих его поведение в модели предметной области (рис. 1) Рис. 1 Обязательным элементом обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса. По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами и операциями. Даже если секция атрибутов или операций пустая, в обозначении класса она выделяется горизонтальной линией, для того чтобы сразу отличить класс от других элементов языка UML. Для класса "Счет" (рис. 2, в) дополнительно изображена четвертая секция, в которой указано исключение – отказ от обработки просроченной кредитной карточки. Рис. 2 Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой). В дополнение к общему правилу наименования элементов языка UML имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что именно имена классов образуют словарь предметной области при ООАП. Пример имен классов могут быть такие существительные, как "Сотрудник", "Компания", "Руководитель", "Клиент", "Продавец", "Менеджер", "Офис" и многие другие, имеющие непосредственное отношение к моделируемой предметной области и функциональному назначению проектируемой системы. Во второй сверху секции прямоугольника класса записываются его атрибуты (attributes), или свойства. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, состоящая из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения: <квантор видимости> <имя атрибута> [кратность] : <тип атрибута> = <исходное значение> {строка-свойство} Видимость свойства указывает на возможность его использования другими классами. Один класс может "видеть" другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. С помощью модификаторов видимости можно ограничить доступ к атрибутам и операциям объекта со стороны других объектов. Если же атрибут или операция описаны с модификатором видимости public, то к ним можно получить доступ из любой части программы. Если атрибут или операция описаны с модификатором private, то доступ к ним можно получить только из операции, определенной в том же классе. Модификатор protected разрешает доступ только из операций этого же класса и классов, создаваемых на его основе. В UML атрибуты и операции с модификаторами доступа обозначаются специальными символами слева от их имен: Символ Значение + public - открытый доступ - private - только из операций того же класса # protected - только из операций этого же класса и классов, создаваемых на его основе Квантор видимости может быть опущен. Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя является единственным обязательным элементом синтаксического обозначения атрибута. Тип атрибута в нотации UML иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс. Исходное значение служит для задания некоторого начального значения для соответствующего атрибута в момент создания отдельного экземпляра класса. Операция (operation) представляет собой некоторый сервис, который предоставляет каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строки-свойства данной операции: <квантор видимости> <имя операции> (список параметров) : <выражение типа возвращаемого значения>{строка-свойство} Имена операций, так же как и атрибутов, записываются со строчной (малой) буквы, а их типы - с заглавной (большой) буквы. При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок. В качестве примеров записи операций можно привести следующие обозначения отдельных операций: • +создать() • +нарисовать(форма: Многоугольник = прямоугольник, цвет_заливки: Color = (0, 0, 255)) • запросить_счет_клиента(номер_счета:Integer):Currency • выдать_сообщение():{"Ошибка деления на ноль"} На рис. 3 приведено графическое изображение класса "Заказ" в нотации UML. Рис. 3 Изображение класса в UML Отношения между классами Ни один из объектов окружающего нас мира не существует сам по себе. Все объекты находятся в определенных отношениях друг с другом. Сначала попробуем прояснить, как относятся друг к другу отношения между классами в UML. Используя различные источники удалось построить следующую структурную схему, демонстрирующую разновидности отношений: Рис. 4 — Отношения между классами При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями, или связями, в языке UML являются: • отношение зависимости, или dependency relationship (рис. 5); • отношение ассоциации, или association relationship (рис. 6 – 9); • отношение обобщения, или generalization relationship (рис. 10); • отношение реализации, или realization relationship. Зависимостью называется отношение, согласно которому изменение в спецификации одного элемента (например, класса " товар ") может повлиять на использующий его элемент (класс " строка заказа "). Часто зависимости показывают, что один класс использует другой в качестве аргумента. Приведем простой пример, опять-таки взятый из нашей повседневности. Иногда к нам в руки попадают видеофайлы, воспроизвести которые "с лету" не удается. Почему? Правильно, потому что на компьютере не установлены соответствующие кодеки. То есть операция "Воспроизведение", реализуемая программой-медиаплеером, зависит от операции "Декомпрессия", реализуемой кодеком. Если спецификация операции "Декомпрессия" изменится, придется менять код медиаплеера, иначе он просто не сможет работать с каким-то кодеком и, в лучшем случае, завершит свою работу с ошибкой. А вот так зависимость между классами изображается в UML (рис. 5): Рис. 5 Другой вид отношений между объектами - это ассоциация. Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа (" клиент " может сделать " заказ "). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Ассоциация может иметь имя, показывающее природу отношений между объектами, при этом в имени может указываться направлениечтения связи при помощи треугольного маркера. Однонаправленная ассоциация может изображаться стрелкой. Проиллюстрируем сказанное примерами (6): Рис. 6 Кроме направления ассоциации, мы можем указать на диаграмме роли, которые каждый класс играет в данном отношении, и кратность, то есть количество объектов, связанных отношением (рис. 7): Рис. 7 Ассоциация  может объединять три и более класса. В этом случае она называется n-арной и изображается ромбом на пересечении линий, как показано на этой диаграмме, позаимствованной нами из Zicom Mentor (рис. 8): Рис. 8 Рисунок 9 иллюстрирует модель формирования заказа. Каждый заказ может быть создан единственным клиентом (множественность роли 1...1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть " привязан " к определенному клиенту. Рис. 9 Свойства ассоциации Такого рода ассоциация является простой и отражает отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа "часть-целое", то используется специальный тип ассоциации — агрегация. В этом случае один класс имеет более высокий статус (целое) и состоит из низших по статусу классов (частей). При этом выделяют простое и композитное агрегирование и говорят о собственно агрегации и композиции. Агрегация — отношение «часть-целое» между двумя равноправными объектами, когда один объект (контейнер) имеет ссылку на другой объект. Оба объекта могут существовать независимо. Простая агрегация предполагает, что части, отделенные от целого, могут продолжать свое существование независимо от него. Рис. 10 Графическое изображение отношения композиции в языке UML Под композитным же агрегированием понимается ситуация, когда целое владеет своими частями и их время жизни соответствует времени жизни целого, т. е. независимо от целого части существовать не могут. Рис. 11 Графическое изображение отношения обобщения в языке UML Примеры этих видов ассоциаций и их обозначений в UML можно увидеть на следующей диаграмме (рис. 12). Рис. 12 Примеры, как нам кажется, очень простые и понятные. Винчестер можно вынуть из компьютера и установить в новый компьютер или в USB-карман, т. е. существование жесткого диска с разборкой системного блока не заканчивается. А вот кнопки без окон обычно существовать не могут - с закрытием окна кнопки также исчезают. И, наконец, еще одна важная вещь, касающаяся ассоциации. В отношении между двумя классами сама ассоциация тоже может иметь свойства и, следовательно, тоже может быть представлена в виде класса. Пример прост (рис. 13): Рис. 13 Действительно, перед началом трудовых отношений работник и работодатель подписывают между собой контракт, который имеет такие атрибуты, как, например, описание работ, сроки их выполнения, порядок оплаты и т. д. Обобщение — это отношение между общей сущностью (родителем — класс " клиент ") и ее конкретным воплощением (потомком — классы " корпоративный клиент " или " частный клиент ").  Рис. 14 Графическое изображение отношения обобщения в языке UML Объекты класса -потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым. Пример (рис. 15) весьма прост. Как видим, он, хоть и немного однобоко, иллюстрирует с помощью операции наследования или генерализации "генеалогическое древо" бытовой техники. Думаем, мы бы поняли смысл этой диаграммы, даже если бы ничего не знали о классах и не занимались программированием вообще. Рис. 15 Между классами возможны различные отношения, представленные на рис. 16: Рис. 16 Отображение связей между классами Выводы • Инкапсуляция защищает внутреннее устройство объекта и реализуется путем ограничения доступа к атрибутам и операциям класса из других частей программы. • Обобщение позволяет повторно использовать уже существующие решения, создавая новые классы путем наследования от имеющихся классов. • Полиморфизм позволяет работать с группой разнородных объектов одинаковым образом, не задумываясь о различиях в реализации. • Инкапсуляция, наследование и полиморфизм - три кита, на которых держится ООП. • В любой системе между объектами существуют отношения разных типов. • Отношение зависимости означает, что реализация одного класса зависит от спецификации операций другого класса. • Ассоциация выражает отношение между несколькими равноправными объектами и может иметь направление, роли и кратность, а также изображаться в виде класса ассоциации. • Композиция и агрегация используются, если между объектами существуют отношения типа "часть-целое", причем композиция предполагает, что части не могут существовать отдельно от целого. ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ  Диаграммы прецедентов и диаграммы классов, которые мы рассмотрели, показывают отношения между объектами в некоторый момент времени, т. е. предоставляют нам снимок состояния системы, являясь статическими. Диаграмма же последовательностей отображает взаимодействие объектов в динамике. В UML взаимодействие объектов понимается как обмен информацией между ними в виде сообщений. Кроме того, что сообщение несет какую-то информацию, оно некоторым образом также влияет на получателя. Условия взаимодействия задаются сценарием, полученным на этапе разработки диаграмм прецедентов. Да, действительно, диаграммы последовательностей можно (и нужно!) использовать для уточнения диаграмм прецедентов, более детального описания логики сценариев использования. Диаграммы последовательностей обычно содержат объекты, которые взаимодействуют в рамках сценария, сообщения, которыми они обмениваются, и возвращаемые результаты, связанные с сообщениями Таким образом, диаграмма последовательности – это удобное средство для обозначения очередности следования друг за другом различных сообщений, с помощью которых объекты взаимодействуют между собой. Например, когда нужно проработать буквально по шагам какой-то очень важный участок выполнения программы. Главный акцент - порядок и динамика поведения, т.е. как и в каком порядке происходят события. Обычно нормальные люди стараются описывать одной диаграммой только один определенный  вариант использования, например: "оставить комментарий к сообщению в блоге", "стать постоянным читателем" и т.д... Диаграмма последовательности предназначена для моделирования отношений между объектами (ролями, классами, компонентами) Системы в рамках одного прецедента. Диаграмма последовательности, которая описывает всю систему сразу, представляет собой монстра, пожирающего внимание, сознание, силы, время и мозг разработчика. Теперь о том, какие обозначения используются на диаграмме последовательностей. Объекты диаграммы последовательности Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. На этих диаграммах изображаются только те объекты, которые непосредственно участвуют во взаимодействии т.к. ключевым моментом является именно динамика взаимодействия объектов во времени и не используются возможные статические ассоциации с другими объектами. На диаграмме последовательности объекты в основном представляют экземпляры класса или сущности, обладающие поведением. В качестве объектов могут выступать пользователи, инициирующие взаимодействие, классы, обладающие поведением в Системе или программные компоненты, а иногда и Системы в целом.  Объекты обозначается прямоугольником, в котором указывается информация об участнике действий. Это, как правило, название объекта и его класс, разделенные двоеточием (рис. 1). Объекты располагаются слева направо таким образом, чтобы крайним слева был тот объект, который инициирует взаимодействие. Неотъемлемой частью объекта на диаграмме последовательности является линия жизни объекта, участвующего во взаимодействии. Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то его линия жизни должна начинаться в верхней части диаграммы и заканчиваться в нижней части (объекты 1 и 2 на рис. 1). Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены, чтобы освободить занимаемые ими ресурсы. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы “X” (объект 3 на рис. 1). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий. Периоды активности объекта в момент взаимодействия показываются с помощью фокуса управления. Обозначается узким прямоугольником (серого или белого цвета), расположенным на линии жизни. Указывает начало и завершение действия, в котором участвует объект. Поскольку линия жизни - это метафора времени, то прямоугольник на линии жизни указывает на активизацию объекта во времени. Прямоугольники на вертикальных линиях под каждым из объектов показывают "время жизни" (фокус) объектов. Впрочем, довольно часто их не изображают на диаграмме, все это зависит от индивидуального стиля проектирования. Рис. 1 Графические примитивы диаграммы последовательности Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность (объект 6 на рис. 2). Рис. 2 Варианты линий жизни и фокусов управления объектов Также одним из основных понятий, связанных с диаграммой последовательности, является Сообщение.  Как уже отмечалось выше, взаимодействия объектов реализуются с помощью сообщений. Сообщения (вызовы методов) изображаются линиями со стрелками, возвращаемые результаты - пунктирными линиями со стрелками. У каждого сообщения должно быть имя, соответствующее его цели. Существует несколько видов сообщений: простое, синхронное, с отказом становиться в очередь и др. (рис. 3). Рис. 3 Примеры сообщений Простое сообщение используется по умолчанию. Означает, что все сообщения выполняются в одном потоке управления (рис. 3, 1). Синхронное (synchronous) применяется, когда клиент посылает сообщение и ждет ответа пользователя (рис. 3, 2). Сообщение с отказом становиться в очередь (balking): клиент посылает сообщение серверу и, если сервер не может немедленно принять сообщение, оно отменяется (рис. 3, 3). Сообщение с лимитированным временем ожидания (timeout): клиент посылает сообщение серверу, а затем ждет указанное время; если в течение этого времени сервер не принимает сообщение, оно отменяется (рис. 3, 4). Асинхронное сообщение (asynchronous): клиент посылает сообщение серверу и продолжает свою работу, не ожидая подтверждения о получении (рис. 3, 5). Временная шкала на диаграмме направлена сверху вниз. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. Таким образом, на диаграмме последовательности мы можем увидеть следующие аспекты: • Сообщения, побуждающие объект к действию • Действия, которые вызываются сообщениями (методы) – зачастую это передача сообщения следующему объекты или возвращение определенных данных объекта • Последовательность обмена сообщениями между объектами  Итак, прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Сообщение в большинстве случаев (за исключением диаграмм, описывающих концептуальный уровень Системы) это вызов методов отдельных объектов, поэтому для корректного исполнения метода в сообщении необходимо передать какие-то данные и определить, что мы хотим видеть в ответ. При именовании сообщения на уровне проектирования реализации системы в качестве имени сообщения следует использовать имя метода.  При отображении работы с сообщениями иногда возникает необходимость указать некоторые временные ограничения. Например, длительность передачи сообщения или ожидание ответа от объекта не должно превышать определенный временной интервал. Можно указать следующие временные параметры: • ограничение продолжительности (Duration Constraint) – минимальное и максимальное значение продолжительности передачи сообщения • ограничение продолжительности ожидания между передачей и получением сообщения (Duration Constraint Between Messages) • перехват продолжительности сообщения (Duration Observation) • временное ограничение (Timing Constraint) – временной интервал, в течение которого сообщение должно прийти к цели (устанавливается на стороне получателя) • перехват времени, когда сообщение было отправлено (Timing Observation)    Форма заказа передает данные Менеджеру заказа, при этом передача данных не должна длиться больше 30 сек. – данное ограничение может понадобиться при выявлении требований к быстродействию Системы. Далее получение данных с формы инициирует запуск метода для создания экземпляра класса Заказ. Между получением данных от Формы заказа и инициализацией создания объекта должно пройти не более 30 сек., в противном случае пользователю может быть предоставлено сообщение об ошибке или недоступности сервера. Длительность передачи сообщения о создании объекта может быть зафиксирована в переменной d. Данное значение может понадобиться при установке временного ограничения на получение ответного сообщения клиентом. В момент передачи сообщения фиксируется временное значение и заносится в переменную t. Таким образом, можно установить ограничение на стороне приемника, указав переменную t в качестве минимального значения и t+<допустимый интервал> в качестве максимального значения.  Пример диаграммы последовательности Рисунок 4 Думаем, смысл диаграммы вполне понятен: студент хочет записаться на некий семинар, предлагаемый в рамках некоторого учебного курса. С этой целью проводится проверка подготовленности студента, для чего запрашивается список (история) семинаров курса, уже пройденных студентом (перейти к следующему семинару можно, лишь проработав материал предыдущих занятий). После получения истории семинаров объект класса "Слушатель" получает статус подготовленности, на основе которой студенту сообщается результат (статус) его попытки записи на семинар. Как видите, все просто! Итак, предлагаю рассмотреть простенькую диаграмму последовательности. Возьмем банальный пример (рис.5). Эта диаграмма показывает как приготовить яичницу. Рисунок 5. Когда мы смотрим на такую диаграмму последовательности, мы сразу понимаем что: - нужно не забыть включить плиту; - перед жаркой нужно хорошо разогреть масло; - первым нужно положить масло, а потом яйца, а не наоборот; - cоль можно добавить асинхронно, в процессе жарки. Не следует захламлять диаграмму лишними объектами. Ведь если завалить диаграмму всеми объектами, то с ней невозможно будет работать. Например, если возвращаться к приготовлению яичницы. В том случае, если мы включим в диаграмму такие объекты как: нагревательный элемент плиты, регулятор температуры, ручка сковородки, прихватка, масленка, холодильник, в котором хранятся яйца, инструмент для отрезания кусочка масла, инструмент для переноса кусочка масла в сковородку, предмет для разбивания яиц, мусорное ведро, механизм регулирующий количество высыпаемой соли, лопатка, рука левая, рука правая и, наконец, голова, то диаграмма станет намного менее понятной, что плохо... Как связаны между собой диаграммы прецедентов, классов и последовательности ? В ходе проектирования ПО аналитик поэтапно спускается от общей концепции, через понимание ее логической структуры к наиболее детальным моделям, описывающим физическую реализацию.  С помощь диаграммы прецедентов (вариантов использования) выявляются основные пользователи системы и задачи, которые данная система должна решать. С помощью диаграммы последовательности мы описываем последовательность действий для каждого прецедента, необходимых для достижения поставленной цели.  Далее проектируется логическая структура системы с помощью диаграммы классов. На данном этапе выделяются классы, формирующие структуру БД Системы, а также классы реализующие некий набор операций, способствующий достижению целей в рамках выбранного прецедента. Для описания сложного поведения некоторых объектов (экземпляров класса) составляется диаграмма состояний. ДИАГРАММА КОМПОНЕНТОВ Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Особенность логического представления заключается в том, что оно оперирует понятиями, которые не имеют самостоятельного материального воплощения. Другими словами, различные элементы логического представления, такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически. Они лишь отражают наше понимание структуры физической системы или аспекты ее поведения. Основное назначение логического представления состоит в анализе структурных и функциональных отношений между элементами модели системы. Однако для создания конкретной физической системы необходимо некоторым образом реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначен другой аспект модельного представления, а именно физическое представление модели. Чтобы пояснить отличие логического и физического представлений, рассмотрим в общих чертах процесс разработки некоторой программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой системы необходимо разработать исходный текст программы на некотором языке программирования (C++, Pascal, Basic/VBA, Java). При этом уже в тексте программы предполагается такая организация программного кода, которая предполагает его разбиение на отдельные модули. Тем не менее исходные тексты программы еще не являются окончательной реализацией проекта, хотя и служат фрагментом его физического представления. Очевидно, программная система может считаться реализованной в том случае, когда она будет способна выполнять функции своего целевого предназначения. А это возможно, только если программный код системы будет реализован в форме исполняемых модулей, библиотек классов и процедур, стандартных графических интерфейсов, файлах баз данных. Именно эти компоненты являются необходимыми элементами физического представления системы. Таким образом, полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation diagrams), которые включают в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развертывания. Особенности построения первой из них рассматриваются в этой главе, а второй – в следующей. Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. .Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей: • Визуализации общей структуры исходного кода программной системы. • Спецификации исполнимого варианта программной системы. • Обеспечения многократного использования отдельных фрагментов программного кода. • Представления концептуальной и физической схем баз данных. В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов. Компоненты Для представления физических сущностей в языке UML применяется специальный термин – компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента может использоваться специальный символ – прямоугольник со вставленными слева двумя более мелкими прямоугольниками (рис. 1). Внутри объемлющего прямоугольника записывается имя компонента и, возможно, некоторая дополнительная информация. Изображение этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с компонентом информации. В метамодели языка UML компонент является потомком классификатора. Он предоставляет организацию в рамках физического пакета ассоциированным с ним элементам модели. Как классификатор, компонент может иметь также свои собственные свойства, такие как атрибуты и операции. Рис. 1. Графическое изображение компонента в языке UML Так, в первом случае (рис. 1, а) с компонентом уровня экземпляра связывается только его имя, а во втором (рис. 1, б) – дополнительно имя пакета и помеченное значение. Имя компонента Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания. Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Хотя его графическое изображение в обоих случаях одинаковое, правила записи имени компонента несколько отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента ':' имя типа Х При этом вся строка имени подчеркивается. В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), имена динамических библиотек (расширение dll), имена Web-страниц (расширение html), имена текстовых файлов (расширения txt или doc) или файлов справки (hip), имена файлов баз данных (DB) или имена файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение Java для языка Java), скрипты (pi, asp) и др. Поскольку конкретная реализация логического представления модели системы зависит от используемого программного инструментария, то и имена компонентов будут определяться особенностями синтаксиса соответствующего языка программирования. В отдельных случаях к простому имени компонента может быть добавлена информация об имени объемлющего пакета и о конкретной версии реализации данного компонента (рис. 1, б). Необходимо заметить, что в этом случае номер версии записывается как помеченное значение в фигурных скобках. В других случаях символ компонента может быть разделен на секции, чтобы явно указать имена реализованных в нем интерфейсов. Такое обозначение компонента называется расширенным. Виды компонентов Поскольку компонент как элемент физической реализации модели представляет отдельный модуль кода, иногда его комментируют с указанием дополнительных графических символов, иллюстрирующих конкретные особенности его реализации. Строго говоря, эти дополнительные обозначения для примечаний не специфицированы в языке UML. Однако их применение упрощает понимание диаграммы компонентов, существенно повышая наглядность физического представления. Некоторые из таких общепринятых обозначений для компонентов изображены ниже (рис. 2). В языке UML выделяют три вида компонентов. • Во-первых, компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll (рис. 2, а), Web-страницы на языке разметки гипертекста с расширением html (рис. 2, б) и файлы справки с расширением hlр (рис. 10.2, в). • Во-вторых, компоненты-рабочие продукты. Как правило – это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++ (рис. 2, г). • В-третьих, компоненты исполнения, представляющие исполнимые модули – файлы с расширением ехе. Они обозначаются обычным образом. Рис. 2. Варианты графического изображения компонентов на диаграмме компонентов Эти элементы иногда называют артефактами, подчеркивая при этом их законченное информационное содержание, зависящее от конкретной технологии реализации соответствующих компонентов. Более того, разработчики могут для этой цели использовать самостоятельные обозначения, поскольку в языке UML нет строгой нотации для графического представления примечаний. Другой способ спецификации различных видов компонентов – явное указание стереотипа компонента перед его именем. В языке UML для компонентов определены следующие стереотипы: • Библиотека (library) – определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки. • Таблица (table) – также определяет первую разновидность компонента, который представляется в форме таблицы базы данных. • Файл (file) – определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ. • Документ (document) – определяет вторую разновидность компонента, . который представляется в форме документа. • Исполнимый (executable) – определяет третий вид компонента, который может исполняться в узле. Интерфейсы Следующим элементом диаграммы компонентов являются интерфейсы. Напомним, что в общем случае интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок (рис. 3, а). При этом имя интерфейса, которое обязательно должно начинаться с заглавной буквы "I", записывается рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов. Рис. 3. Графическое изображение интерфейсов на диаграмме компонентов Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом «интерфейс» и возможными секциями атрибутов и операций (рис. 3, б). Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса, которая может быть важна для реализации. При разработке программных систем интерфейсы обеспечивают не только совместимость различных версий, но и возможность вносить существенные изменения в одни части программы, не изменяя другие ее части. Таким образом, назначение интерфейсов существенно шире, чем спецификация взаимодействия с пользователями системы (актерами). Зависимости Напомним, что зависимость не является ассоциацией, а служит для представления только факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу). Зависимости могут отражать связи модулей программы на этапе компиляции и генерации объектного кода. В другом случае зависимость может отражать наличие в независимом компоненте описаний классов, которые используются в зависимом компоненте для создания соответствующих объектов. Применительно к диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой. В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 4). Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем «main.exe» зависит от импортируемого интерфейса I Dialog, который, в свою очередь, реализуется компонентом с именем «image.java». Для второго компонента этот же интерфейс является экспортируемым. Рис. 4. Фрагмент диаграммы компонентов с отношением зависимости Заметим, что изобразить второй компонент с именем «image.java» в форме варианта примечания нельзя именно в силу того факта, что этот компонент реализует интерфейс. Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов (рис. 5). Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно. Рис. 5. Графическое изображение отношения зависимости между компонентами Наконец, на диаграмме компонентов могут быть представлены отношения зависимости между компонентами и реализованными в них классами. Эта информация имеет важное значение для обеспечения согласования логического и физического представлений модели системы. Разумеется, изменения в структуре описаний классов могут привести к изменению компонента. Ниже приводится фрагмент зависимости подобного рода, когда некоторый компонент зависит от соответствующих классов. Рис. 6. Графическое изображение зависимости между компонентом и классами Следует заметить, что в данном случае из диаграммы компонентов не следует, что классы реализованы этим компонентом. Если требуется подчеркнуть, что некоторый компонент реализует отдельные классы, то для обозначения компонента используется расширенный символ прямоугольника. При этом прямоугольник компонента делится на две секции горизонтальной линией. Верхняя секция служит для записи имени компонента, а нижняя секция – для указания дополнительной информации (рис. 7). Рис. 7. Графическое изображение компонента с дополнительной информацией о реализуемых им классах Внутри символа компонента могут изображаться другие элементы графической нотации, такие как классы (компонент уровня типа) или объекты (компонент уровня экземпляра). В этом случае символ компонента изображается таким образом, чтобы вместить эти дополнительные символы. Так, например, изображенный ниже компонент (рис. 8) является экземпляром и реализует три отдельных объекта. Рис. 8. Графическое изображение компонента уровня экземпляра, реализующего отдельные объекты Объекты, которые находятся в отдельном компоненте-экземпляре, изображаются вложенными в символ данного компонента. Подобная вложенность означает, что выполнение компонента влечет выполнение соответствующих объектов. Другими словами, существование компонента в течение времени исполнения программы обеспечивает существование, а возможно, и доступ всех вложенных в него объектов. Что касается доступа к этим объектам, то он может быть дополнительно специфицирован с помощью квантификаторов видимости, подобно видимости пакетов. Содержательный смысл видимости может отличаться для различных видов пакетов. Так, для компонентов с исходным текстом программы видимость может означать возможность внесения изменений в соответствующие тексты программ с их последующей перекомпиляцией. Для компонентов с исполняемым кодом программы видимость может характеризовать возможность запуска на исполнение соответствующего компонента или вызова реализованных в нем операций или методов. Рекомендации по построению диаграммы компонентов Разработка диаграммы компонентов предполагает использование информации как о логическом представлении модели системы, так и об особенностях ее физической реализации. До начала разработки необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования. После этого можно приступать к общей структуризации диаграммы компонентов. В первую очередь, необходимо решить, из каких физических частей (файлов) будет состоять программная система. На этом этапе следует обратить внимание на такую реализацию системы, которая обеспечивала бы не только возможность повторного использования кода за счет рациональной декомпозиции компонентов, но и создание объектов только при их необходимости. Речь идет о том, что общая производительность программной системы существенно зависит от рационального использования ею вычислительных ресурсов. Для этой цели необходимо большую часть описаний классов, их операций и методов вынести в динамические библиотеки, оставив в исполняемых компонентах только самые необходимые для инициализации программы фрагменты программного кода. После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. При разработке интерфейсов следует обращать внимание на согласование (стыковку) различных частей программной системы. Включение в модель схемы базы данных предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами. Наконец, завершающий этап построения диаграммы компонентов связан с установлением и нанесением на диаграмму взаимосвязей между компонентами, а также отношений реализации. Эти отношения должны иллюстрировать все важнейшие аспекты физической реализации системы, начиная с особенностей компиляции исходных текстов программ и заканчивая исполнением отдельных частей программы на этапе ее выполнения. Для этой цели можно использовать различные виды графического изображения компонентов. При разработке диаграммы компонентов следует придерживаться общих принципов создания моделей на языке UML. В частности, в первую очередь необходимо использовать уже имеющиеся в языке UML компоненты и стереотипы. Для большинства типовых проектов этого набора элементов может оказаться достаточно для представления компонентов и зависимостей между ними. Если же проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения. В частности, использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик. В заключение следует обратить внимание, что диаграмма компонентов, как правило, разрабатывается совместно с диаграммой развертывания, на которой представляется информация о физическом размещении компонентов программной системы по ее отдельным узлам. Особенности построения диаграммы развертывания будут рассмотрены в следующей главе. ДИАГРАММА СОСТОЯНИЙ Объекты характеризуются поведением и состоянием, в котором они находятся. Рассмотрим простой пример. Любое техническое устройство, такое как телевизор, компьютер, автомобиль, телефонный аппарат в самом общем случае может характеризоваться такими своими состояниями, как "исправен" и "неисправен". Интуитивно ясно, какой смысл вкладывается в каждое из этих понятий. Более того, использование по назначению данного устройства возможно только тогда, когда оно находится в исправном состоянии. В противном случае необходимо предпринять совершенно конкретные действия по его ремонту и восстановлению работоспособности. Другими словами, объекты что-то делают и что-то "знают". Диаграммы состояний применяются для того, чтобы объяснить, каким образом работают сложные объекты. Несмотря на то, что смысл понятия "состояние" интуитивно понятен, все же приведем его определение в таком виде, в каком его дают классики и Zicom Mentor: Состояние (state) - ситуация в жизненном цикле объекта, во время которой он удовлетворяет некоторому условию, выполняет определенную деятельность или ожидает какого-то события. Состояние объекта определяется значениями некоторых его атрибутов и присутствием или отсутствием связей с другими объектами. Диаграмма состояний показывает, как объект переходит из одного состояния в другое. Очевидно, что диаграммы состояний служат для моделирования динамических аспектов системы (как и диаграммы последовательностей, кооперации, прецедентов и, как мы увидим далее, диаграммы деятельности). Диаграмма состояний полезна при моделировании жизненного цикла объекта (как и ее частная разновидность - диаграмма деятельности, о которой мы будем говорить далее). Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели. Диаграмма состояний, по существу, является графом специального вида, который представляет некоторый автомат. Формализм обычного автомата основан на выполнении следующих обязательных условий: 1. Автомат не запоминает историю перемещения из состояния в состояние. С точки зрения моделируемого поведения определяющим является сам факт нахождения объекта в том или ином состоянии, но никак не последовательность состояний, в результате которой объект перешел в текущее состояние. Другими словами, автомат "забывает" все состояния, которые предшествовали текущему в данный момент времени. Образно говоря, существует непрозрачная стена, отделяющая текущее состояние от прошлого поведения объекта. 2. В каждый момент времени автомат может находиться в одном и только в одном из своих состояний. Это означает, что формализм автомата предназначен для моделирования последовательного поведения, когда объект в течение своего жизненного цикла последовательно проходит через все свои состояния. При этом автомат может находиться в отдельном состоянии как угодно долго, если не происходит никаких событий. 3. Хотя процесс изменения состояний автомата происходит во времени, явно концепция времени не входит в формализм автомата. Это означает, что длительность нахождения автомата в том или ином состоянии, а также время достижения того или иного состояния никак не специфицируются. Другими словами, время на диаграмме состояний присутствует в неявном виде, хотя для отдельных событий может быть указан интервал времени и в явном виде. 4. Количество состояний автомата должно быть обязательно конечным (в языке UML рассматриваются только конечные автоматы), и все они должны быть специфицированы явным образом. 5. Граф автомата не должен содержать изолированных состояний и переходов. Это условие означает, что для каждого из состояний, кроме начального, должно быть определено предшествующее состояние. Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют "петлей". 6. Автомат не должен содержать конфликтующих переходов. т. е. таких переходов из одного и того же состояния, когда объект одновременно может перейти в два и более последующих состояния. В языке UML исключение конфликтов возможно на основе введения так называемых сторожевых условий, которые будут рассмотрены ниже. Таким образом, правила поведения объекта, моделируемого некоторым автоматом, определяются, с одной стороны, общим формализмом автомата, а с другой - его графическим изображением в языке UML в форме конкретной диаграммы состояний. Основными понятиями, входящими в формализм автомата, являются состояние и переход. Главное различие между ними заключается в том, что длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода из одного состояния в другое равно нулю (если дополнительно ничего не сказано). Другими словами, переход объекта из состояния в состояние происходит мгновенно. Состояние на диаграмме изображается прямоугольником со скругленными вершинами (рис. 1). Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния (рис. 1, а). В противном случае в первой из них записывается имя состояния, а во второй - список некоторых внутренних действий или переходов в данном состоянии (рис. 1, б). При этом под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, "истина" или "ложь"). Рис. 1 Графическое изображение состояний на диаграмме состояний Имя состояния представляет собой строку текста, которая раскрывает содержательный смысл данного состояния. Имя всегда записывается с заглавной буквы. Поскольку состояние системы является составной частью процесса ее функционирования, рекомендуется в качестве имени использовать глаголы в настоящем времени (звенит, печатает, ожидает) или соответствующие причастия (занят, свободен, передано, получено). Простейшим примером визуального представления состояний и переходов на основе формализма автоматов может служить рассмотренная выше ситуация с исправностью технического устройства, такого как компьютер. В этом случае вводятся в рассмотрение два самых общих состояния: "исправен" и "неисправен" и два перехода: "выход из строя" и "ремонт". Графически эта информация может быть представлена в виде изображенной ниже диаграммы состояний компьютера (рис. 2). Рис. 2 Простейший пример диаграммы состояний для технического устройства типа компьютер Существует также два вида псевдосостояний (рис. 3): начальное, в котором находится объект сразу после его создания (обозначается сплошным кружком), и конечное, которое объект не может покинуть, если перешел в него (обозначается кружком, обведенным окружностью). Рис. 3 Графическое изображение состояний на диаграмме состоянии: а – начального; б – конечного Стрелками показываются переходы между состояниями, которые вызваны выполнением методов описываемого диаграммой объекта. Простой переход (simple transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что переход срабатывает, или происходит срабатывание перехода. Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рис. 2, 4): < Событие> <[Условие]> < / Действие>. Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение "истина". Термин «событие» (event) требует отдельного пояснения, поскольку является самостоятельным элементом языка UML. Формально событие представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели. Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события и представляет собой некоторое булевское выражение. Из контекста диаграммы состояний должна явно следовать семантика этого выражения, а для его записи может использоваться синтаксис языка объектных ограничений. Введение для перехода сторожевого условия позволяет явно специфицировать семантику его срабатывания. Если сторожевое условие принимает значение "истина", то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние (рис. 4). Рис. 4 Диаграмма состояний для моделирования почтовой программы-клиента Составное состояние (composite state) - сложное состояние из других вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния (substate). Хотя между ними существует отношение композиции, графически все вершины диаграммы, которые соответствуют вложенным состояниям, изображаются внутри символа составного состояния (рис. 5). В этом случае его размеры увеличиваются, чтобы вместить в себя все подсостояния. Рис 5 Графическое представление составного состояния с двумя вложенными в него последовательными подсостояниями Например: диаграмма состояния прохождения учебного курса (рис. 6) Рис. 6 Здесь мы видим составное состояние, включающее другие состояния, одно из которых содержит также параллельные подсостояния. Мы не говорили ранее о том, как все это обозначается, но ведь и так понятно - это диаграмма прохождения академического курса студентом. Для того чтобы пройти курс, студент должен выполнить лабораторные работы, защитить курсовой проект и сдать экзамен. Все просто! Историческое состояние (history state) применяется в контексте составного состояния (рис. 6). Рис. 6 Графическое изображение: а – недавнего; б – давнего исторического состояния Оно используется для запоминания того из последовательных подсостояний, которое было текущим в момент выхода из составного состояния. И еще один пример (рис. 7) - диаграмма состояний объекта «Заказ» Рис. 7 Диаграмма состояний объекта «заказ» ДИАГРАММЫ РАЗВЕРТЫВАНИЯ Когда мы пишем программу, мы пишем ее для того, чтобы запускать на компьютере, который имеет некоторую аппаратную конфигурацию и работает под управлением некоторой операционной системы. Корпоративные приложения часто требуют для своей работы некоторой ИТ-инфраструктуры, хранят информацию в базах данных, расположенных где-то на серверах компании, вызывают веб-сервисы, используют общие ресурсы и т. д. В таких случаях неплохо бы иметь графическое представление инфраструктуры, на которую будет развернуто приложение. Вот для этого-то и нужны диаграммы развертывания, которые иногда называют диаграммами размещения. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели. Итак, перечислим цели, преследуемые при разработке диаграммы развертывания: • Определить распределение компонентов системы по ее физическим узлам. • Показать физические связи между всеми узлами реализации системы на этапе ее исполнения. • Выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности. Для обеспечения этих требований диаграмма развертывания разрабатывается совместно системными аналитиками, сетевыми инженерами и системотехниками. Далее рассмотрим отдельные элементы, из которых состоят диаграммы развертывания. Узел. Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может рассматриваться наличие по меньшей мере некоторого объема электронной или магнитооптической памяти и/или процессора. В последней версии языка UML понятие узла расширено и может включать в себя не только вычислительные устройства (процессоры), но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы. Графически на диаграмме развертывания узел изображается в форме трехмерного куба (строго говоря, псевдотрехмерного прямоугольного параллелепипеда). Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов (рис. 1, а), так и в качестве экземпляров (рис. 1, б). Рис. 1. Графическое изображение узла на диаграмме развертывания В первом случае имя узла записывается без подчеркивания и начинается с заглавной буквы. Во втором имя узла-экземпляра записывается в виде <имя узла ':' имя типа узла>. Имя типа узла указывает на некоторую разновидность узлов, присутствующих в модели системы. Например, аппаратная часть системы может состоять из нескольких персональных компьютеров, каждый из которых соответствует отдельному узлу-экземпляру в модели. Однако все эти узлы-экземпляры относятся к одному типу узлов, а именно узлу с именем типа «Персональный компьютер». Так, на представленном выше рисунке (рис. 1, а) узел с именем «Сервер» относится к общему типу и никак не конкретизируется. Второй же узел (рис. 1, б) является анонимным узлом-экземпляром конкретной модели принтера. Изображения узлов могут расширяться, чтобы включить некоторую дополнительную информацию о спецификации узла. Если дополнительная информация относится к имени узла, то она записывается под этим именем в форме помеченного значения (рис. 2). Рис. 2. Графическое изображение узла-экземпляра с дополнительной информацией в форме помеченного значения Если необходимо явно указать компоненты, которые размещаются на отдельном узле, то это можно сделать двумя способами. Первый из них позволяет разделить графический символ узла на две секции горизонтальной линией. В верхней секции записывают имя узла, а в нижней секции – размещенные на этом узле компоненты (рис. 3, а). Второй способ разрешает показывать на диаграмме развертывания узлы с вложенными изображениями компонентов (рис. 3, б). Важно помнить, что в качестве таких вложенных компонентов могут выступать только исполняемые компоненты. Рис. 3. Варианты графического изображения узлов-экземпляров с размещаемыми на них компонентами В качестве дополнения к имени узла могут использоваться различные стереотипы, которые явно специфицируют назначение этого узла. Хотя в языке UML стереотипы для узлов не определены, в литературе встречаются следующие их варианты: «процессор», «датчик», «модем», «сеть», «консоль» и др., которые самостоятельно могут быть определены разработчиком. Более того, на диаграммах развертывания допускаются специальные обозначения для различных физических устройств, графическое изображение которых проясняет назначение или выполняемые устройством функции. Соединения Кроме собственно изображений узлов на диаграмме развертывания указываются отношения между ними. В качестве отношений выступают физические соединения между узлами и зависимости между узлами и компонентами, изображения которых тоже могут присутствовать на диаграммах развертывания. Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением. Так, на представленном ниже фрагменте диаграммы развертывания (рис. 4) явно определены не только требования к скорости передачи данных в локальной сети с помощью помеченного значения, но и рекомендации по технологии физической реализации соединений в форме примечания. Рис. 4. Фрагмент диаграммы развертывания с соединениями между узлами Кроме соединений на диаграмме развертывания могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами. Подобный способ является альтернативой вложенному изображению компонентов внутри символа узла, что не всегда удобно, поскольку делает этот символ излишне объемным. Поэтому при большом количестве развернутых на, узле компонентов соответствующую информацию можно представить в форме отношения зависимости (рис. 5). Диаграммы развертывания могут иметь более сложную структуру, включающую вложенные компоненты, интерфейсы и другие аппаратные устройства. На изображенной ниже диаграмме развертывания (рис. 6) представлен фрагмент физического представления системы удаленного обслуживания клиентов банка. Узлами этой системы являются удаленный терминал (узел-тип) и сервер банка (узел-экземпляр). Рис. 5. Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем компонентами Рис. 6. Диаграмма развертывания для системы удаленного обслуживания клиентов банка На этой диаграмме развертывания указана зависимость компонента реализации диалога «dialog.exe» на удаленном терминале от интерфейса lAuthorise, реализованного компонентом «main.exe», который, в свою очередь, развернут на анонимном узле-экземпляре «Сервер банка». Последний зависит от компонента базы данных «Клиенты банка», который развернут на этом же узле. Примечание указывает на необходимость использования защищенной линии связи для обмена данными в данной системе. Другой вариант записи этой информации заключается в дополнении диаграммы узлом со стереотипом «закрытая сеть». Рекомендации по построению диаграммы развертывания Разработка диаграммы развертывания начинается с идентификации всех аппаратных, механических и других типов устройств, которые необходимы для выполнения системой всех своих функций. В первую очередь специфицируются вычислительные узлы системы, обладающие памятью и/или процессором. Дальнейшее построение диаграммы развертывания связано с размещением всех исполняемых компонентов диаграммы по узлам системы. Если отдельные исполняемые компоненты оказались не размещенными, то подобная ситуация должна быть исключена введением в модель дополнительных узлов, содержащих процессор и память. При разработке простых программ, которые исполняются локально на одном компьютере, так же как и в случае диаграммы компонентов, необходимость в диаграмме развертывания может вообще отсутствовать. В более сложных ситуациях диаграмма развертывания строится для таких приложений, как: • Моделирование программных систем, реализующих технологию доступа к данным «клиент-сервер». Для подобных систем характерно четкое разделение полномочий и, соответственно, компонентов между клиентскими рабочими станциями и сервером базы данных. Возможность реализации «тонких» клиентов на простых терминалах или организация доступа к хранилищам данных приводит к необходимости уточнения не только топологии системы, но и ее компонентного состава. • Моделирование неоднородных распределенных архитектур. Речь идет о корпоративных интрасетях, насчитывающих сотни компьютеров и других периферийных устройств, функционирующих на различных платформах и под различными операционными системами. При этом отдельные узлы такой системы могут быть удалены друг от друга на сотни километров (филиалы компаний). В этом случае диаграмма развертывания становится важным инструментом визуализации общей топологии системы и контроля миграции отдельных компонентов между узлами. • Наконец, системы со встроенными микропроцессорами, которые могут функционировать автономно. Такие системы могут содержать самые разнообразные дополнительные устройства, обеспечивающие автономность их функционирования и решения целевых задач. Для подобных систем диаграмма развертывания позволяет визуализировать состав этих устройств и их взаимосвязи в системе. Как правило, разработка диаграммы развертывания осуществляется на завершающем этапе ООАП, что характеризует окончание фазы проектирования физического представления. С другой стороны, диаграмма развертывания может строиться для анализа существующей системы с целью ее последующего анализа и модификации. При этом анализ предполагает разработку этой диаграммы на его начальных этапах, что характеризует общее направление анализа от физического представления к логическому. При моделировании бизнес-процессов диаграмма развертывания, кроме компьютеров корпоративной сети, может содержать в качестве узлов различные средства оргтехники (факсимильные устройства, многоканальные телефонные станции, множительные аппараты, экраны для презентаций и др.). При этом каждое из подобных устройств может функционировать как автономно, так и в составе корпоративной сети. Если необходимо включить в модель ресурсы Интернета, то на диаграмме развертывания Интернет обозначается в форме «облачка» с соответствующим именем. Строго говоря, подобное обозначение не специфицировано в языке UML, однако оно часто используется при разработке моделей распределенных систем. Следующая диаграмма развертывания представляет собой образец, чтобы дать представление о представлении развертывания системы управления заказами. Здесь мы показали узлы, как: • монитор; • модем; • сервер кэширования; • сервер. Заявка считается веб-приложением, которое развернуто в кластерной среде, используя сервер 1, сервер 2 и сервер 3. Пользователь подключается к приложению, используя Интернет. Управления течет от сервера кэширования к кластерной среде. Таким образом, диаграмма развертывания было обращено с учетом всех перечисленных выше пунктов: В заключение следует отметить одно немаловажное обстоятельство, характерное для разработки всех канонических диаграмм. Хотя в языке UML определена графическая нотация для всех элементов канонических диаграмм, способы графического изображения отдельных инструментальных средств имеют свои специфические особенности. Применение того или иного инструментального CASE-средства накладывает определенные ограничения на визуализацию моделей программных систем. Речь идет о том, что некоторые элементы языка UML могут вообще отсутствовать в CASE-средствах. Выход из подобной ситуации может быть связан либо с выбором другого инструментария, поддерживающего последние версии языка UML, либо упрощении модели на основе ее типизации. Приведем еще один пример:    УПРАВЛЕНИЕ ПРОЕКТАМИ. ОПРЕДЕЛЕНИЯ И КОНЦЕПЦИИ Проект — основа инноваций Классическое управление проектами выделяет два вида организации человеческой деятельности: операционная и проектная. Операционная деятельность применяется, когда внешние условия хорошо известны и стабильны, когда производственные операции хорошо изучены и неоднократно испытаны, а функции исполнителей определены и постоянны. В этом случае основой эффективности служат узкая специализация и повышение компетенции. «Если водитель трамвая начнет искать новые пути, жди беды». Там, где разрабатывается новый продукт, внешние условия и требования к которому постоянно меняются, где применяемые производственные технологии используются впервые, где постоянно требуются поиск новых возможностей, интеллектуальные усилия и творчество, там требуются проекты. Проект — временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. У операционной и проектной деятельности есть ряд общих характеристик: выполняются людьми, ограничены доступностью ресурсов, планируются, исполняются и управляются. Операционная деятельность и проекты различаются, главным образом, тем, что операционная деятельность — это продолжающийся во времени и повторяющийся процесс, в то время как проекты являются временными и уникальными. Ограничение по срокам означает, что у любого проекта есть четкое начало и четкое завершение. Завершение наступает, когда достигнуты цели проекта; или осознано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается. Уникальность также важное отличие проектной деятельности от операционной. Если бы результаты проекта не носили уникальный характер, работу по их достижению можно было бы четко регламентировать, установить производственные нормативы и реализовывать в рамках операционной деятельности (конвейер). Задача проекта — достижение конкретной бизнес-цели. Задача операционной деятельности — обеспечение нормального течения бизнеса. Операционная деятельность уходит в прошлое. В постиндустриальном обществе интеллект — основная производственная сила. Сегодня от 70 до 80% всего, что сегодня делается людьми, производится при помощи их интеллекта. В любом товаре, сделанном в США, доля зарплаты составляет 70 процентов. Но это в среднем по всем товарам. Что касается разработки ПО, то почти все, что в этой отрасли производится, создается при помощи интеллекта. Все меньший объем человеческой деятельности может быть организован в виде повторяющихся операций. Традиционный пример операционной деятельности — это работа бухгалтерии. Но жизнь так стремительно изменяется, что сегодня, по утверждению сведущих людей, подготовка и сдача годового финансового отчета каждый раз реализуется как самостоятельный проект. Проект это основа инноваций. Сделать то, до чего другие компании еще не додумались, сделать это как можно быстрее, иначе это сделают другие. Предложить потребителю более качественный продукт или такой продукт, потребность в котором потребитель даже не может пока осознать. Основные понятия управления проектами Проект обладает определенными свойствами. 1. Проект всегда имеет четко определенную цель, которая выражается в получении некоторого результата. Достижение этого результата означает успешное завершение и окончание проекта. Например, для проекта строительства здания результатом является само здание, принятое в эксплуатацию. 2. Проект имеет четко очерченное начало, которое совпадает с началом первой работы, направленной на достижение поставленной цели. Начало может задаваться директивно, либо рассчитываться в результате составления плана работ по проекту. 3. Проект имеет четко очерченный конец, который совпадает с концом последней работы, направленной на получение заданного результата. Как и начало, конец проекта может задаваться директивно, или рассчитываться при составлении плана работ. Например, для проекта строительства здания конец проекта совпадает с датой акта сдачи/приемки его в эксплуатацию. 4. Проект исполняется командой, в состав которой входит руководитель проекта, менеджеры, исполнители. Помимо основной команды в нем могут участвовать сторонние исполнители, команды и организации, которые привлекаются на временной основе для выполнения отдельных работ. 5. При реализации проекта используются материальные ресурсы. Их номенклатура и количество определяются характером проекта и входящих в него работ. Так при строительстве дома используются песок, щебень, цемент, кирпич и т.п. 6. Проект имеет бюджет. Стоимость проекта складывается из стоимости израсходованных материальных ресурсов, затрат по оплате труда реализующей его команды и прочих расходов, связанных с особенностями конкретных видов работ. Критерии успешности проекта Проект имеет ограничения трех видов. ◦ Ограничения по бюджету устанавливают предельную стоимость всего проекта или отдельных видов работ. ◦ Ограничения по времени задают предельные сроки окончания либо всего проекта, либо некоторых работ. Например, тестовые испытания должны проводиться в присутствии представителя заказчика, который будет присутствовать в заданный период времени. ◦ Ограничения по ресурсам определяются ограниченным составом команды или графиками поступления материальных ресурсов. Цель управления проектом состоит в рациональном распределении имеющихся ресурсов для выполнения всех предусмотренных конкретным проектом работ (задач, технологических операций) в заданные сроки и без сверхнормативных затрат. Задача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений «железного треугольника» (Рисунок 6). Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие. Например, чтобы уменьшить время, потребуется увеличить стоимость и/или сократить содержание. Рисунок 6. «Железный треугольник» ограничений проекта Согласно текущей редакции стандарта PMBOK, проект считается успешным, если удовлетворены все требования заказчика и участников проекта. Поэтому у проекта разработки ПО сегодня не три, а четыре фактора успеха: 1. Выполнен в соответствие со спецификациями. 2. Выполнен в срок. 3. Выполнен в пределах бюджета. 4. Каждый участник команды уходил с работы в 18:00 с чувством успеха. Этот четвертый фактор успеха должен стать воспроизводимым, если предприятие хочет быть эффективным. Для успешного проекта характерно постоянное ощущение его участниками чувства удовлетворения и гордости за результаты своей работы, чувства оптимизма. Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников. Эффективность это отношение полученного результата к произведенным затратам. Нельзя рассматривать эффективность, исходя только из результативности: чем больше ты производишь, чем больше делаешь, тем выше твоя эффективность. С таким подходом можно «зарезать на ужин курицу, несущую золотые яйца». Затраты не следует путать с инвестициями. Оплата аренды, электроэнергии, коммунальные платежи — затраты. Создание и закрепление эффективной команды — это стратегическое приобретение компании. Обучение участников проекта — инвестиции. Вложение в людей — это увеличение числителя в формуле эффективности. Уход из компании всех профессионалов после проекта, выполненного по принципу «любой ценой», — затраты, причем очень тяжело восполняемые. Нарастающая конкуренция указывает на совершенно четкий тренд в мировой экономике — персонал — это форма инвестиций, активов, которые нужно уметь наращивать, управлять и сохранять. Сегодня люди — это капитал. Современное предприятие обязано относиться к своим работникам так же, как к своим лучшим клиентам. Главный капитал современной компании — это знания. Большая часть этих знаний неотъемлема от их носителя — человека. Те предприятия, которые этого не поняли, не выживут потому, что не смогут быть эффективными. Сегодня эффективное предприятие — это сервис. Предприятие, с одной стороны, предоставляет услуги и продукты своим клиентам, а с другой, — рабочие места для профессионального персонала. Принципы «Одно предприятие на всю жизнь», «Работай продуктивно, а предприятие о тебе позаботится» — уходят в прошлое. Посмотрите на рынок рабочей силы в ИТ — правила устанавливают профессионалы. Качество управления проектом оценивается по следующим критериям, расположенным в порядке убывания значимости: ♦ чистая текущая стоимость проекта; ♦ срок сдачи проекта в эксплуатацию; ♦ затраты на реализацию проекта; ♦ своевременность финансирования и поставок; ♦ равномерность загрузки ресурсов; ♦ соблюдение запланированных сроков выполнения работ; ♦ отношения в трудовом коллективе, ♦ взаимоотношения с подрядчиками, инвесторами и другими партнёра- ми. Управление проектами Управление проектом – это процесс планирования, организации и управления работами и ресурсами, направленный на достижение поставленной цели, как правило, в условиях ограничений на время, имеющиеся ресурсы или стоимость работ. Современная концепция управления проектом основана на принципе информативного измерения процессов ЖЦ проекта, его ресурсов и создаваемых рабочих продуктов. По существу, управление без измерения, качественного и количественного, страдает недостаточной обоснованностью принимаемых решений, а измерение без управления, в свою очередь, не имеет цели и контекста применения. Кроме того, и управление, и измерение, одинаково безрезультатны без использования накопленных исторических данных для проведения экспертного сопоставительного оценивания результатов измерений и управления проектом в целом. Управляемыми параметрами проекта являются: 1. Объемы и виды работ; 2. Стоимость, издержки, расходы по проекту; 3. Временные параметры, включающие сроки, продолжительности и резервы выполнения работ и этапов проекта, а также взаимосвязи между работами; 4. Ресурсы, требуемые для осуществления проекта, в том числе человеческие или трудовые, финансовые, материально-технические, а также ограничения по ресурсам; 5. Качество проектных решений, применяемых ресурсов, компонентов проекта и прочее. Задачами управления проекта являются: 1. Определение цели проекта и проведение его обоснования; 2. Создание структуры проекта (подцели, основные этапы работы, которые предстоит выполнить); 3. Определение необходимых объемов и источников финансирования; 4. Подбор команды исполнителей, подготовка и заключение контрактов со сторонними исполнителями; 5. Определение сроков выполнения проекта; 6. Составление графика его реализации; 7. Расчет необходимых для проекта материальных ресурсов, заключение контрактов с поставщиками; 8. Расчет сметы и бюджета проекта; 9. Планирование и учет рисков. Управление проектом включает следующие шаги: 1. Инициация проекта и определение его границ. Предполагает определение требований к проекту посредством применения методов извлечения требований, оценивания их осуществимости с различных точек зрения (технической, технологической, финансовой, социально-политической). 2. Планирование. Предполагает: • выбор модели ЖЦ проекта и оценивание процессов ЖЦ в контексте пригодности для удовлетворения требований к проекту, адаптацию базовых процессов организации и их институциализацию в проекте; • иерархическую декомпозицию задач проекта, их спецификацию наряду с установленными требованиями, ассоциируемыми рабочими и поставляемыми продуктами; • оценки объемов работ, трудоемкости и стоимости реализации проекта; • распределение ресурсов по задачам с учетом графика проекта и с позиций рационального использования персонала проекта, оборудования и материалов; • управление риском проекта, по крайней мере, по критериям стоимости разработки, продолжительности проекта и качества программных продуктов; • управление качеством - применение процедур планирования и контроля качества выполнения процессов и любых рабочих продуктов этих процессов, а также верификация и валидация (V&V) продуктов. Управление качеством и V&V осуществляется по соответствующим планам, синхронизируемым с планом проекта; • управление планом проекта. Необходимость управления планом проекта обусловлена часто изменяющимися требованиями заказчика и условиями выполнения проекта. Это делает процесс планирования проекта итеративным. 3. Ввод в действие. Предполагает выполнение выбранных процессов ЖЦ в соответствии с планом наряду с измерениями, мониторингом и регулированием процессов и составлением отчетов для заинтересованных сторон (руководства организации, заказчиков, соисполнителей). Процесс мониторинга заключается в систематическом периодическом оценивании соблюдения процессами утвержденных планов. Анализируются результаты и условия завершения каждой задачи, определяются характеристики создаваемых рабочих продуктов, исследуются финансовые и временные затраты, использование ресурсов, соответствие требованиям и стандартам по качеству. Оцениваются отклонения измеренных значений величин от ожидаемых (в частности, стоимости, сроков, качества). Пересматриваются величины и приоритеты рисков. Результаты процесса мониторинга создают базис для принятия решения о регулировании процессов в проекте - повторном выполнении определенных действий (например, повторном тестировании компонентов) или инкорпорации новых действий в процесс (например, разработке прототипов компонентов с целью идентификации и утверждения требований к ним). В ходе регулирования возможны также пересмотры плана проекта и сопутствующих планов. Во всех случаях регулирование должно сопровождаться процедурами контроля изменений и управления конфигурацией ПС. Принимаемые решения документируются и доводятся до всех заинтересованных лиц. 4. Обзор и оценка выполнения проекта. Предполагает выполнение всеобъемлющей проверки деятельности по проекту и оценки его продвижения к установленным целям. Проводится в установленных критических точках проекта. Оцениваются не только результаты выполнения процессов, но и эффективность применяемых методов и инструментов, а также продуктивность работы коллектива проекта и возможные трудности (например, конфликты между членами проекта). При необходимости, осуществляется регулирование. 5. Закрытие проекта. Предполагает прекращение проекта по завершении всех процессов и достижении целей, отраженных в плане проекта и сопутствующих планах. Оценивается успешность проекта по отношению к установленным критериям, касающимся состава и качества выпускаемой программной продукции. База данных измерений по выполняемым в организации проектам пополняется новыми данными, которые подвергаются анализу с целью извлечения и обобщения знаний о процессах ЖЦ ПС и необходимого совершенствования базового процесса организации. ПС передается в эксплуатацию. Жизненный цикл проекта. Фазы и продукты Каждый проект разработки ПО имеет свой собственный жизненный цикл, который состоит из четырех фаз. Жизненный цикл проекта – это промежуток времени между моментами его начала и завершения. Он делится на четыре фазы (Рисунок 7). 1. Фаза инициализации. Включает формулирование целей, анализ инвестиционных возможностей, обоснование осуществимости (технико-экономическое обоснование) проекта. 2. Фаза планирования проекта. Включает определение структуры работ и исполнителей, построение календарных графиков работ, бюджета проекта, разработку проектно-сметной документации, переговоры и заключение контрактов с подрядчиками и поставщиками. 3. Фаза реализации проекта. Включает работы по реализации проекта, в том числе маркетинг, обучение персонала и т.п. 4. Фаза завершения проекта. Включает в общем случае приемочные испытания, опытную эксплуатацию и сдачу проекта в эксплуатацию. Рисунок 7. Жизненный цикл и основные продукты программного проекта На фазе инициации проекта необходимо понять, что и зачем мы будем делать — разработать концепцию проекта. Фаза планирования определяет, как мы будем это делать. На фазе реализации происходит материализация наших идей в виде документированного и протестированного программного продукта. И, наконец, на фазе завершения мы должны подтвердить, что мы разработали именно тот продукт, который задумали в концепции проекта, а также провести приемо-сдаточные испытания (ПСИ) продукта на предмет соответствия его свойств, определенным ранее требованиям. Как правило, редкий проект выполняется в соответствие с первоначальными планами, поэтому важным элементом фазы завершения является «обратная связь»: анализ причин расхождения и усвоение уроков на будущее. Помним, что управляющая система без обратной связи не может быть устойчивой. Организация проектной команды Каждый проект разработки ПО имеет свою организационную структуру, которая определяет распределение ответственности и полномочий среди участников проекта, а также обязанностей и отношений отчетности. Чем меньше проект, тем больше ролей приходится совмещать одному исполнителю. Роли и ответственности участников типового проекта разработки ПО можно условно разделить на пять групп: 1. Анализ. Извлечение, документирование и сопровождение требований к продукту. 2. Управление. Определение и управление производственными процессами. 3. Производство. Проектирование и разработка ПО. 4. Тестирование. Тестирование ПО. 5. Обеспечение. Производство дополнительных продуктов и услуг. Группа анализа включает в себя следующие роли: • Бизнес-аналитик. Построение модели предметной области (онтологии). • Бизнес-архитектор. Разрабатывает бизнес-концепцию системы. Определяет общее видение продукта, его интерфейсы, поведение и ограничения. • Системный аналитик. Отвечает за перевод требований к продукту в функциональные требования к ПО. • Специалист по требованиям. Документирование и сопровождение требований к продукту. • Менеджер продукта (функциональный заказчик). Представляет в проекте интересы пользователей продукта. Группа управления состоит из следующих ролей: • Руководитель проекта. Отвечает за достижение целей проекта при заданных ограничениях (по срокам, бюджету и содержанию), осуществляет операционное управление проектом и выделенными ресурсами. • Куратор проекта. Оценка планов и исполнения проекта. Выделение ресурсов. • Системный архитектор. Разработка технической концепции системы. Принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов. • Руководитель группы тестирования. Определение целей и стратегии тестирования, управление тестированием. • Ответственный за управление изменениями, конфигурациями, за сборку и поставку программного продукта. В производственную группу входят: • Проектировщик. Проектирование компонентов и подсистем в соответствие с общей архитектурой, разработка архитектурно значимых модулей. • Проектировщик базы данных. • Проектировщик интерфейса пользователя. • Разработчик. Проектирование, реализация и отладка отдельных модулей системы. В большом проекте может быть несколько производственных групп, ответственных за отдельные подсистемы. Как правило, проектировщик выполняет роль лидера группы и управляет своим подпроектом или пакетом работ. Стоит не забывать, что руководитель проекта делегирует полномочия, но не ответственность. Группа тестирования в проекте состоит из следующих ролей: • Проектировщик тестов. Разработка тестовых сценариев. • Разработчик автоматизированных тестов. • Тестировщик. Тестирование продукта. Анализ и документирование результатов. Участники группы обеспечения, как правило, не входят в команду проекта. Они выполняют работы в рамках своей процессной деятельности. К группе обеспечения можно отнести следующие проектные роли: • Технический писатель. • Переводчик. • Дизайнер графического интерфейса. • Разработчик учебных курсов, тренер. • Участник рецензирования. • Продажи и маркетинг. • Системный администратор. • Технолог. • Специалист по инструментальным средствам. • Другие. В зависимости от масштаба проекта одну роль могут исполнять несколько человек. Например, разработчики, тестировщики, технические писатели. Некоторые роли всегда должен исполнять только один человек. Например, Руководитель проекта, Системный архитектор. Один человек может исполнять несколько ролей. Возможны следующие совмещения ролей: • Руководитель проекта + системный аналитик (+ системный архитектор) • Системный архитектор + разработчик • Системный аналитик + проектировщик тестов (+ технический писатель) • Системный аналитик + проектировщик интерфейса пользователя • Ответственный за управление конфигурациями + ответственный за сборку и поставку (+ разработчик) Крайне нежелательно совмещать следующие роли: • Разработчик + руководитель проекта • Разработчик + системный аналитик. • Разработчик + проектировщик интерфейсов пользователя. • Разработчик + тестировщик Не редко можно видеть, как в критические периоды проекта его менеджер-разработчик с увлечением правит очередную программу, а проектная команда в полном составе стоит у него за спиной и наблюдает за этим процессом. Это плохой пример руководства проектом. Программисты любят и умеют программировать. Пусть они этим и занимаются. Не стоит загружать программистов несвойственной для них работой. В каждом проекте разработки программного продукта много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации. Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо, да еще и дорого. В силу своей интроверсии, граничащей с аутизмом, программист просто не в состоянии увидеть свою программу чужими глазами — глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение программиста, которому гораздо важнее видеть, как работает его программа, чем разбираться в том, что она делает для пользователя. Поэтому, необходимо привлекать в проектную команду бизнес-аналитиков, эргономистов, художников-дизайнеров, документалистов. Разделение труда и специализация — залог перехода от кустарного производства к более эффективному промышленному производству. Из профессиональных программистов получаются отличные тестировщики. Однако, совмещать одновременно роли программиста и тестировщика — плохая практика. Хороший программист убежден, что он пишет программы правильно и ему психологически тяжело допустить, что где-то в его коде может быть ошибка. А ошибки есть всегда! Организационная структура проекта обязательно должна включать в себя эффективную систему отчетности, оценки хода выполнения проекта и систему принятия решений. Можно рекомендовать еженедельные собрания по статусу проекта, на которых анализируются риски, оцениваются результаты, достигнутые на предыдущей неделе, и уточняются задачи на новый период. Важно помнить, что организационная структура проекта — «живой» организм. Она начинает складываться на стадии планирования и может меняться в ходе проекта. Нестабильность организационной структуры (частые замены исполнителей) — серьезная проблема в управлении сложными программными проектами, поскольку существует время вхождения в контекст проекта, которое может измеряться месяцами. ИНИЦИАЦИЯ ПРОЕКТА Управление приоритетами проектов Эффективные процессы инициации программного проекта минимум наполовину определяют его будущую успешность. Недостаточное внимание именно этой фазе проекта неизбежно приводит к существенным проблемам при планировании, реализации и завершении проекта. Инициация состоит из процессов, способствующих формальной авторизации начала нового проекта или фазы проекта. Процессы инициации часто выполняются вне рамок проекта и связаны с организационными, программными или портфельными процессами. В ходе процесса инициации уточняются первоначальное описание содержания и ресурсы, которые организация планирует вложить. На этом этапе также выбирается менеджер проекта, если он еще не назначен, и документируются исходные допущения и ограничения. Эта информация заносится в Устав проекта и, если он одобряется, проект официально авторизуется. Устав проекта — документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта. В российской практике данный документ чаще называется Концепция проекта. Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения. В компании, которая принимает решение о старте того или иного проекта разработки ПО, должна существовать единая система критериев для оценки его значимости. Система критериев должна позволять из множества возможных для реализации проектов выбрать наиболее приоритетные для компании. Приоритет любого проекта должен определяться на основе оценки трех его характеристик: • Финансовая ценность. • Стратегическая ценность. • Уровень рисков. Шкала оценки финансовой ценности проекта может выглядеть следующим образом: • Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованны. • Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания. • Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес. • Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства. Например. Финансовая ценность проектов разработки ПО, проектов внедрения или сопровождения, которые выполняются в соответствие с заключенными коммерческими договорами, может быть оценена как высокая. Проект планового развития функциональности продуктов в соответствии с требованиями рынка, инициируемое менеджером продукта на основе анализа предложений отделов маркетинга, консалтинга, продаж и технической поддержки, может получить оценку финансовой ценности выше среднего, а проекты изменения технологических процессов или проекты внутренней автоматизации могут иметь среднюю финансовую ценность. Одной финансовой ценности для определения приоритета проекта недостаточно. Например, ни одна компания разработчик ПО не возьмется за автоматизацию нелегального оборота наркотиков, если это не соответствует стратегии ее бизнеса. Поэтому, важным показателем приоритета проекта является его соответствие стратегическим целям компании. Шкала оценки стратегической ценности проекта может иметь следующий вид: • Высокая. Обеспечивает стратегическое преимущество, дает устойчивое увеличение рынка или позволяет выйти на новый рынок. Решает значительные проблемы, общие для большинства важных клиентов. Повторение конкурентами затруднено или потребует от 1 до 2 лет. • Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года. • Средняя. Поддерживается доверие рынка к компании. Повышает мнение клиентов о качестве предоставляемых услуг или способствует выполнению обязательств перед несколькими клиентами. Конкуренты уже имеют или способны повторить новые возможности в пределах года. • Низкая. Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта. Третьим обязательным показателем приоритета проекта должна быть оценка уровня его риска. Ни один проект, который имеет даже самую высокую оценку финансовой выгодности, не будет запущен в производство, если достижение этой сверхвыгоды имеет минимальные шансы. Примерная шкала оценки уровня рисков проекта может иметь следующий вид: • Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы. • Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе. • Выше среднего. Цели проекта недостаточно четки. Задачи системы или бизнес-приложения поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы. • Высокий. Цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Системы создаются на новой технологической платформе, в отношении которой крайне мало ясности. Технологии имеют неподтвержденную стабильность. Если компания уделяет мало внимания управлению приоритетами своих проектов, то это приводит к переизбытку реализуемых проектов, перегруженности исполнителей, постоянным авралам и сверхурочным работам и, как следствие, к низкой эффективности производственной деятельности. При старте нового проекта с высоким приоритетом, компания должна остановить или закрыть менее значимые проекты, чтобы обеспечить новый проект необходимыми ресурсами, а не пытаться сделать все и сразу за счет интенсификации работ, как правило, это не получается. Концепция проекта У каждого проекта должна быть концепция. Если проект небольшой, то для изложения концепции часто достаточно несколько абзацев. Однако, стартовать проект без концепции, это все равно, что отправлять корабль в плавание, не определив для него пункт назначения. Концепция проекта разрабатывается на основе анализа потребностей бизнеса. Главная функция документа — подтверждение и согласование единого видения целей, задач и результатов всеми участниками проекта. Концепция определяет что и зачем делается в проекте. Концепция проекта это ключевой документ, который используется для принятия решений в ходе всего проекта, а также на фазе приемки — для подтверждения результата. Она содержит, как правило, следующие разделы: • Название проекта • Цели проекта • Результаты проекта • Допущения и ограничения • Ключевые участники и заинтересованные стороны • Ресурсы проекта • Сроки • Риски • Критерии приемки • Обоснование полезности проекта В качестве примера, который позволит иллюстрировать теоретическое изложение основ управления проектами, возьмем реальный проект разработки ПО для автоматизации одного из подразделений крупной производственной компании. Назовем его «Автоматизированная система продажи документации». Краткая легенда проекта. Заказчик ОАО «XYZ» является одним из ведущих производителей сложных технических изделий. Отдел «123», входящий в ОАО «XYZ», отвечает за продажу дополнительной сопроводительной документации для клиентов ОАО. Дополнительная документация не входит в стандартную поставку, поскольку владелец этого технического изделия не всегда сам его эксплуатирует, а передает в эксплуатацию другой компании, которая становится клиентом «XYZ», и закупает у нее эксплуатационную документацию. Ремонт и техобслуживание конкретного изделия может выполнять третья компания, которой уже потребуется детальная техническая документация по ремонту и обслуживанию. Она также становится клиентом «XYZ» и закупает у нее требуемую продукцию. Основная функция отдела «123» — получение и обработка заказов на дополнительную документацию, согласно ежегодно рассылаемому каталогу. В связи с переездом отдела «123» в новое здание, была поставлена задача на разработку и поставку системы, автоматизирующей основную деятельность отдела «123». Текст документа Концепция проекта, который будет приводиться в качестве примера, будем выделять цветом фона. Цели и результаты проекта При постановке целей проекта по разработке программного продукта очень важно различать цель – создание программного обеспечения и цель, ради достижения которой создается программное обеспечение. В очень редких случаях программное обеспечение создается «ради себя самого». В качестве исключительных примеров можно указать только учебные проекты, когда программное обеспечение разрабатывается ради демонстрации возможностей разработчиков или же академические проекты, когда программное обеспечения разрабатывается ради доказательства принципиальной возможности разработки. В подавляющем большинстве случаев программные продукты разрабатываются с целью последующего использования. Очень важно не потерять из виду основную цель разработки, которая формулируется заказчиками и пользователями программного продукта и не подменить эту основную цель собственными целями разработчиков программного продукта. Цели проекта должны отвечать на вопрос, зачем данный проект нужен. Цели проекта должны описывать бизнес-потребности и задачи, которые решаются в результате исполнения проекта. Целями проекта могут быть: • Изменения в Компании. Например, автоматизация ряда бизнес-процессов для повышения эффективности основной производственной деятельности. • Реализация стратегических планов. Например, завоевание значительной доли растущего рынка за счет вывода на него нового продукта. • Выполнение контрактов. Например, разработка программного обеспечения по заказу. • Разрешение специфических проблем. Например, доработка программного продукта в целях приведения его в соответствие с изменениями в законодательстве. Описание целей проекта Цели проекта должны быть описаны явно и удовлетворять определенным критериям. • Конкретность. Цель проекта должна быть конкретной, выраженной в терминах проекта, с указанием условий и сроков. Например, цель «добиться максимальной степени удовлетворенности потребителей продукта» не конкретна. В то же время цель «получить положительный отзыв на продукт от 90% потребителей за первые полгода продаж» достаточно конкретна для проекта по разработке «коробочного» продукта. • Реалистичность. Цель должна быть реалистичной, то есть достижимой с учетом имеющихся ресурсов. Например, цель «разработать программу автоматического художественного перевода поэзии с английского языка на русский за год» нереалистична для компании среднего размера. В то же время цель «разработать программу подстрочного перевода технического текста с английского языка на русский за год» может быть вполне реалистична, если есть опыт и задел. • Измеримость. Должен быть указан эффективно проверяемый критерий, который позволял бы определить, достигнута ли цель и в какой степени. Например, цель «разработать программу, существенно повышающую эффективность процесса продаж» неизмерима: неясно, как измеряется эффективность и какое повышение можно считать существенным. В то же время цель «разработать программу, ускоряющую процесс оформления заявки в среднем на 10%» измерима. • Непротиворечивость. Цели не должны быть внутренне противоречивыми и взаимно исключающими друг друга. Например, цели «разработать продукт с максимальным набором функций» и «затратить минимальное количество ресурсов на разработку» противоречат друг другу (и неконкретны, к тому же). Минимальное количество ресурсов (ноль) будет затрачено, если разработку не проводить, но тогда и возможностей у продукта не будет. В то же время цель «разработать продукт, имеющий не меньше функций, чем конкурент Х и затратить на разработку не более Y человеко-часов» не является противоречивой (но может оказаться нереалистичной). Цели должны быть значимыми (направленными на достижение стратегических целей Компании), конкретными (специфичными для данного проекта), измеримыми (т.е иметь проверяемые количественные оценки), реальными (достижимыми). Четкое определение бизнес-целей важно, поскольку существенно влияет на все процессы и решения в проекте. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным. Например, если реальные затраты на проект будут превосходить будущие доходы от его реализации. Результаты проекта отвечают на вопрос, что должно быть получено после его завершения. Результаты проекта должны определять: • Какие именно бизнес-выгоды получит заказчик в результате проекта. • Какой продукт или услуга. Что конкретно будет произведено по окончании проекта. • Высокоуровневые требования. Краткое описание и при необходимости ключевые свойства и/или характеристики продукта/услуги. Следует помнить, что результаты проекта должны быть измеримыми. Это означает, что при оценке результатов проекта должна иметься возможность сделать заключение достигнуты оговоренные в концепции результаты или нет. Соответствующий раздел документа концепция проекта создания «Автоматизированной системы продажи документации» будет выглядеть следующим образом. 1. Цели и результаты проекта 1.1. Целью проекта является повышение эффективности основной производственной деятельности отдела «123». 1.2. Дополнительными целями проекта являются: 1.2.1. Установление долгосрочных отношений с важным заказчиком ОАО «XYZ». 1.2.2. Выход на новый перспективный рынок современных B2C систем. 2. Результаты проекта должны обеспечить: 2.1. Снижение затрат на обработку заявок. 2.2. Снижение сроков обработки заявок. 2.3. Повышение оперативности доступа к информации о наличии продукции. 2.4. Повышение оперативности доступа к информации о прохождении заявок. 2.5. Повышение надежности и полноты хранения информации о поступивших заявках и результатах их обработки. 3. Продуктами проекта являются: 3.1. Прикладное ПО и документация пользователей. 3.2. Базовое ПО. 3.3. Оборудование ЛВС, рабочие станции, сервера и операционно-системное ПО. 3.4. Проведение пуско-наладочных работ и ввод в опытную эксплуатацию. 3.5. Обучение пользователей и администраторов системы. 3.6. Сопровождение системы на этапе опытной эксплуатации. 3.7. Передача системы в промышленную эксплуатацию. 4. Система должна автоматизировать следующие функции: 4.1. Авторизация и аутентификация пользователей. 4.2. Просмотр каталога продуктов. 4.3. Поиск продуктов по каталогу. 4.4. Заказ выбранных продуктов. 4.5. Просмотр информации о статусе заказа. 4.6. Информирование клиента об изменении статуса заказа. 4.7. Просмотр и обработка заказов исполнителями из службы продаж. 4.8. Просмотр статистики поступления и обработки заказов за период. 4.9. Подготовка и сопровождение каталога продукции. Допущения и ограничения Данный раздел описывает исходные допущения и ограничения. Допущения, как правило, тесно связаны с управлением рисками, о котором мы будем говорить далее. В разработке ПО часто приходится формулировать риски в виде допущений, тем самым передавая его заказчику. Например, оценивая проект разработки и внедрения по схеме с фиксированной ценой, мы должны записать в допущения предположение о том, что стоимость лицензий на стороннее ПО не изменится, до завершения проекта. Ограничения, как правило, сокращают возможности проектной команды в выборе решений. В частности они могут содержать: • Специфические нормативные требования. Например, обязательная сертификация продукта, услуги на соответствие определенным стандартам. • Специфические технические требования. Например, разработка под заданную программно-аппаратную платформу. • Специфические требования к защите информации. В этом разделе также уместно сформулировать те требования к системе, которые могут ожидаться заказчиком по умолчанию, но не включаются в рамки данного проекта. Например, в данный раздел может быть включен пункт о том, что разработка программного интерфейса (API) для будущей интеграции с другими системами заказчика не входит в задачи данного проекта. Содержание этого раздела для нашего проекта-примера выглядит следующим образом. 5. Допущения и ограничения 5.1. Проектирование прикладного ПО выполняется с использованием UML. 5.2. Средством разработки ПО является Symantec Visual Cafe for Java 5.3. В качестве промежуточного ПО сопровождения и поддержки каталога используется ОО БД «Poet». 5.4. Нагрузка на систему не должна быть более 100 одновременно работающих пользователей. 5.5. В рамки проекта не входят: 5.5.1. Защита системы от преднамеренного взлома. 5.5.2. Разработка B2B API и интеграция с другими системами. Ключевые участники и заинтересованные стороны Одна из задач фазы инициации проекта это выявить и описать всех его участников. Согласно к участникам проекта относятся все заинтересованные стороны (stakeholders), лица и организации, например заказчики, спонсоры, исполняющая организация, которые активно участвуют в проекте или чьи интересы могут быть затронуты при исполнении или завершении проекта. Участники также могут влиять на проект и его результаты поставки. К ключевым участникам программного проекта, как правило, относятся: • Спонсор проекта — лицо или группа лиц, предоставляющая финансовые ресурсы для проекта в любом виде. • Заказчик проекта — лицо или организация, которые будут использовать продукт, услугу или результат проекта. Следует учитывать, что заказчик и спонсор проекта не всегда совпадают. • Пользователи результатов проекта. • Куратор проекта — представитель исполнителя, уполномоченный принимать решение о выделении ресурсов и изменениях в проекте. • Руководитель проекта — представитель исполнителя, ответственный за реализацию проекта в срок, в пределах бюджета и с заданным качеством. • Соисполнители проекта. Субподрядчики и поставщики. Содержание этого раздела в концепции-примере будет иметь вид. 6. Ключевые участники и заинтересованные стороны 6.1. Спонсор проекта — директор Департамента информатизации ОАО «XYZ» В.Васильев. 6.2. Заказчик — начальник Отдела «123» Ф.Федотов 6.3. Пользователи автоматизированной системы: 6.4. Клиенты ОАО «XYZ» (поиск и заказ документации). 6.5. Руководство ОАО «XYZ» (анализ деятельности Отдела «123»). 6.6. Сотрудники производственных департаментов ОАО «XYZ» (сопровождение каталога). 6.7. Сотрудники Отдела «123» (обработка заявок и поставка документации). 6.8. Сотрудники департамента информатизации ОАО «XYZ» (администрирование системы). 6.9. Куратор проекта — начальник отдела заказных разработок И.Иванов. 6.10. Руководитель проекта — ведущий специалист отдела заказных разработок МП П.Петров. 7. Соисполнители: 7.1. Поставщик оборудования и операционно-системного ПО — ООО «Альфа». 7.2. Поставщик базового ПО — ООО «Бета». Ресурсы Для того чтобы понять, сколько будет стоить реализация программного проекта, требуется определить и оценить ресурсы необходимые для его выполнения: • Людские ресурсы и требования к квалификации персонала. • Оборудование, услуги, расходные материалы, лицензии на ПО, критические компьютерные ресурсы. • Бюджет проекта. План расходов и, при необходимости, предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта. Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами. О том, как следует подходить к оценкам трудозатрат на реализацию проекта разработки ПО, мы будем подробно говорить в следующих лекциях. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до +100%. Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом: Рисунок 1.Распределение трудозатрат по основным производственным процессам при разработке ПО Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы. Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час. Исходя из эмпирической кривой Б. Боэма (Рисунок 15), численность команды, близкая к оптимальной, составила 10 человек, из них 8. Ресурсы проекта 8.1. Требования к персоналу 8.1.1. 1 — руководитель проекта, 8.1.2. 1 — технический лидер (архитектура, проектирование), 8.1.3. 1 — системный аналитик (требования, тест-дизайн, документирование), 8.1.4. 4 — программисты (с учетом работ по конфигурационному управлению), 8.1.5. 3 — тестировщика. 8.2. Материальные и другие ресурсы 8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий 8.2.2. 2 серверных комплекса (для разработки и тестирования): 8.2.3. Сервер приложений с установленным BEA Weblogic AS 8.2.4. Сервер оперативной БД с установленной Oracle RDBMS 8.2.5. Сервер каталога с установленной OODB "Poet" 8.3. Лицензии на средства разработки и тестирования: 8.3.1. Oracle Designer — 1 лицензия 8.3.2. Symantec Visual Cafe for Java — 5 лицензий. 8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия на клиент). 8.4. Расходная часть бюджета проекта4 8.4.1. Разработка и сопровождение прикладного ПО: 8.4.1.1. 9000 чел.*час. * $40 = $360 000 8.4.2. Поставка оборудования и операционно-системного ПО: 8.4.2.1. 3 сервера * $10 000 = $30 000 8.4.3. Поставка базового ПО: 8.4.3.1. BEA Weblogic AS $20 000 8.4.3.2. Oracle RDBMS $20 000 Итого: $430 000 9. Сроки проекта 9.1. 03.03 старт 9.2. 28.11 завершение 9.3. Контрольные точки: 9.3.1. 15.04 ТЗ утверждено 9.3.2. 30.04 1-я итерация завершена. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика). 9.3.3. 15.05 Монтаж оборудования у заказчика завершен. 9.3.4. 30.05 Базовое ПО установлено у заказчика. 9.3.5. 15.06 2-я итерация завершена. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика 9.3.6. 02.09 3-я итерация завершена. Акт передачи системы в опытную эксплуатацию утвержден 9.3.7. 28.11 Система передана в промышленную эксплуатацию. Риски Риск — неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта. Как правило, в случае возникновения негативного риска, почти всегда стоимость проекта увеличивается и происходит задержка в выполнении мероприятий, предусмотренных расписанием проекта. Управлению рисками проекта будет посвящена отдельная лекция. На этапе инициации, когда нет необходимых данных для проведения детального анализа, часто приходится ограничиваться качественной оценкой общего уровня рисков: низкий, средний, высокий. В случае нашего проекта-примера раздел «риски» будет выглядеть следующим образом. 10. Риски проекта 10.1. Задачи системы поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы. Суммарный уровень рисков следует оценить выше среднего. Критерии приемки Критерии приемки должны определять числовые значения характеристик системы, которые должны быть продемонстрированы по результатам приемосдаточных испытаний или опытной эксплуатации и однозначно свидетельствовать о достижении целей проекта. В рассматриваемом примере раздел «Критерии приемки» будет выглядеть следующим образом: 11. Критерии приемки. По итогам опытной эксплуатации система должна продемонстрировать следующие показатели: 11.1. Средние затраты сотрудников Отдела «123» на регламентную обработку одного заказа не превышают 4 чел.*час. 11.2. Срок регламентной обработки 1-го заказа не более 2 недель. 11.3. Время поиска и предоставления информации о наличии дополнительной документации не более 1 мин. 11.4. Время предоставления информации о сделанных заказах и истории их обработки не более 1 мин. 11.5. Система хранит всю информацию о сделанных заказах и истории их обработки. 11.6. Показатель доступности системы 98%. Обоснование полезности проекта Этот раздел концепции должен содержать краткое технико-экономическое обоснование проекта: • Для кого предназначены результаты проекта. • Описание текущей ситуации «As Is». Какие у потенциального заказчика существуют проблемы. • Каким образом результаты проекта решают эти проблемы («To Be»). • Насколько значимо для клиента решение данных проблем (оценка экономического эффекта). • Какие преимущества в итоге из этого может извлечь компания-исполнитель проекта. Соответствующий раздел в концепции проекта-примера будет иметь следующий вид. 12. Обоснование полезности проекта 12.1. Для Заказчика: 12.1.1. Повышение производительности обработки заказов в 2 раза. 12.1.1.1. "As Is": 2500 заказов/год по 8 чел.*час. 12.1.1.2. "To Be": 2500 заказов/год по 4 чел.*час. 12.1.1.3. Экономия: 2500 * 4 * $50 = $500 000 в год. 12.1.2. Повышение оперативности контроля 12.1.2.1. "As Is": Ежемесячная отчетность. 12.1.2.2. "To Be": Отчетность on-line. 12.1.3. Повышение удовлетворенности клиентов: 12.1.3.1. Сокращение срока обработки заказа в 2 раза. 12.1.3.2. Сокращение времени на поиск необходимой документации в 10 раз 12.1.3.3. Повышение оперативности обновления каталога 10 раз. 12.2. Для компании-исполнителя: 12.2.1. Высокая стратегическая ценность. Дает устойчивое увеличение рынка и завоевание нового рынка. 12.2.2. Финансовая ценность выше среднего. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Выводы Эффективные процессы инициации программного проекта во многом определяют его будущую успешность. Недостаточное внимание этой фазе проекта неизбежно приводит к существенным проблемам при планировании, реализации и завершении. Концепция проекта это ключевой документ, который используется для принятия решений в ходе всего проекта, а также на фазе приемки — для подтверждения результата. Приоритет проекта определяется на основе оценки трех показателей: • Финансовая ценность. • Стратегическая ценность. • Уровень рисков.    ПЛАНИРОВАНИЕ ПРОЕКТА Зачем вообще нужен план проекта? Вот ответ на этот вопрос. • План помогает создать ясное и четкое понимание – как будущие работы будут выполняться. • План определяет роль каждого человека в исполнении проекта. • План увязывает части работ вместе. План позволяет видеть все взаимозависимости между разными частями работы. • План – это точка отсчета для любых последующих изменений. • С помощью плана мы видим, когда цель, поставленная перед проектом, достигнута и проект заканчивается. КАЛЕНДАРНЫЙ ПЛАН ПРОЕКТА Заказчика, а значит, и менеджера проекта, в первую очередь интересуют сроки выполнения проекта. Для определения длительности проекта в целом и каждой из его фаз служит календарный план (или план-график) проекта, лежащий по сути дела в основе любого планирования. Календарное планирование заключается в составлении временной диаграммы работ и распределении между работами трудовых ресурсов (исполнителей). Результатом календарного планирования является диаграмма (диаграмма Ганта или сетевой график), графически отображающая периоды выполнения работ на оси времени. На этом этапе может выполняться оптимизация ресурсов и бюджета проекта. В самом простейшем варианте календарный план – это просто список всех работ проекта с указанием дат их начала и окончания. Менеджер проекта в любой момент, глядя на календарный план, в состоянии понять, насколько проект отстает от плана или опережает план. Иногда укрупненный календарный план согласуется с заказачиком и включается в качестве приложения в договор (так делают, например, если оплата по договору предусмотрена в несколько этапов). Из сказанного следует, что создание календарного плана проходит в несколько шагов: 1. разбиение проекта на совокупность отдельных работ, выполнение которых необходимо для реализации проекта, т.е. формируется структура декомпозиции работ (СДР) проекта; 2. для каждой задачи проекта выставляются сроки в соответствии с возможностями команды разработчиков; 3. построение диаграммы, описывающей последовательность выполнения работ. Структура декомпозиции работ (СДР) «Если не получается проглотить слона целиком, то его надо порезать на отбивные». Человечество пока не придумало ничего более эффективного для решения сложной задачи, чем анализ и ее декомпозиция на более простые подзадачи, которые, в свою очередь, могут быть разделены на еще более простые подзадачи и так далее. Получается некоторая иерархическая структура, дерево, в корне которого находится проект, а на листьях элементарные задачи или работы, которые надо выполнить, чтобы завершить проект в условиях заданных ограничений. Структура декомпозиции работ (СДР) (Work Breakdown Structure, WBS) — ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. Основой для разработки СДР служит концепция проекта, которая определяет продукты проекта и их основные характеристики. СДР обеспечивает выявление всех работ, необходимых для достижения целей проекта. Многие проекты проваливаются не от того, что у них нет плана, а от того что в этом плане забыты важные работы, например тестирование и исправление ошибок, и продукты проекта, например пользовательская документация. Поэтому, если СДР составлена корректно, то любая работа, которая в нее не вошла не может считаться работой по проекту. Структура декомпозиции работ (СДР) имеет следующие характеристики: • описывает с необходимой точностью содержание работ по проекту; • определяет весь объем работ по проекту; • формируется в виде иерархической структуры (проект декомпозируется на пакеты/субпакеты и т.д. вплоть до отдельных работ). Глубина детализации СДР зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо выполнить. Каждый пакет работ включает весь объем работ, выполняемый основной организацией, ответственной за данный пакет работ, так же, как и организациями, с которыми заключены подрядные договора. Разработка СДР. Уточнение содержания и состава работ СДР разрабатывается путем итерационного рассмотрения целей и результатов проекта, объема работ, реализации технических требований и других атрибутов. Верхние уровни СДР могут быть разработаны на ранней, концептуальной стадии проекта. Дальнейшая детализация СДР возможна, как только будут определены цели проекта и подготовлены спецификации. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. Компонентами могут быть как прикладные подсистемы, так и инфраструктурные или ядерные, например, подсистема логирования, безопасности, библиотека визуальных компонентов GUI. Должна быть установлена персональная ответственность за все части проекта (подпроекты и пакеты работ). Для каждого пакета работ должен быть четко определен результат на выходе. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компании-исполнителя и, при необходимости, с заказчиком. В результате согласования члены команды принимают на себя обязательства по реализации проекта, а руководство принимает на себя обязательства по обеспечению проекта необходимыми ресурсами. СДР является одним из основных инструментов (средств) в механизме управления проектом, с помощью которого измеряется степень достижения результатов проекта. Важнейшая ее функция это обеспечить консистентное представление всех участников проекта относительно того, как будет делаться проект. В последующем базовый план будет служить ориентиром для сравнения с текущим исполнением проекта и выявления отклонений для целей управления. Следует отметить, что при составлении базового плана работ не стоит стремиться максимально детализировать все работы. СДР не должна. Результаты моделирования проекта наиболее чувствительны к данным о продолжительности работ. Наиболее надёжным источником сведений о продолжительности работ служит опыт прошлых проектов, при выполнении которых производились аналогичные работы. Во многих случаях о продолжительности предстоящих работ можно судить по опыту проектов, предусматривавших выполнение схожих работ, если ввести необходимые корректировки. При отсутствии собственного опыта организация может воспользоваться опытом других организаций, поддерживающих с ней партнёрские отношения. Данный источник следует использовать всякий раз, когда он доступен, исключая случаи, когда имеющийся опыт отражает выполнение работы в экстраординарных условиях. Если опыт прошлых проектов привлечь невозможно, продолжительность наиболее ответственных работ, которые предположительно могут оказаться на критическом пути, рассчитывают на основе технологических карт или других документов, описывающих технологию выполнения работы. Этот способ весьма трудо- и времяёмок; он не отражает фактические изменения продолжительности работы в случаях отклонения технических условий выполнения работы от нормативных; к тому же технологические карты не всегда содержат информацию, необходимую для однозначного установления продолжительности работы. Третий по надёжности способ — использование опубликованных нормативов продолжительности работ либо разработка собственных внутрифирменных нормативов с привлечением методов нормирования. Реальные затраты времени могут, однако, существенно отличаться от норматива, установленного для определённых целей: например, для контроля, анализа с целью выявления узких мест в проектной деятельности и т.д. Но при отсутствии другой информации нормативные данные позволяют составить представление о вероятной продолжительности работы. Следует также иметь в виду, что разработка внутрифирменных нормативов продолжительности предстоящих работ — весьма дорогостоящее мероприятие, оправданное лишь для тех работ, которые имеют значительные шансы оказаться критическими. Последний способ — экспертную оценку продолжительности работ — следует применять тогда, когда ни один из предыдущих неприменим. Он тем надёжнее (и дороже), чем больше экспертов опрошено с целью установления продолжительности работы, но, сколько бы экспертов ни удалось опросить, нельзя быть уверенным, что в их представлении о продолжительности работ не содержится систематической ошибки, одной и той же для всех или большинства опрошенных экспертов. Этот метод чаще других становится причиной ошибочного определения продолжительности всего проекта. Если работа, продолжительность которой из-за отсутствия времени или средств на более глубокое изучение вопроса определена экспертом (экспертами), оказалась на критическом пути, целесообразно вернуться к её определению методами нормирования или на основе технологических карт. В столбце «примечание» таблицы работ целесообразно указывать, каким способом определена продолжительность работы и в какой степени эта информация заслуживает доверия. После определения ожидаемой продолжительности работ, как показывает практика, целесообразно увеличить её значения на некоторый резерв (в процентах к ожидаемой продолжительности). Резерв этот менеджеру следует согласовать с руководителем проекта, чтобы разделить с ним ответственность за возможный срыв сроков проекта из-за недостаточного запаса либо за потери, обусловленные неполным использованием возможностей скорейшего завершения проекта, если план предусматривал чрезмерный резерв. Величина резерва зависит от специфики области проектной деятельности. Существуют проекты, для которых предусматривать запас времени бессмысленно. Информация о связях между работами обычно берётся из технического проекта либо определяется экспертами. Здесь риск ошибки значительно меньше, чем при определении продолжительности работ, зато цена ошибки может оказаться выше. На практике проблемы обычно возникают не из-за неправильного определения связей между работами, а из-за ошибок при вводе модели проекта в ЭВМ. Поэтому, получив первоначальный вариант сетевого плана, целесообразно обсудить полученный критический путь с экспертами с целью выявления ошибочных связей, назначенных по крайней мере критическим работам. При реализации самых ответственных проектов можно поручить разработку предварительного варианта модели проекта двум независимым менеджерам (или командам менеджеров), что позволит сравнить оба варианта и прийти к согласованному решению, устранив причины расхождений. Потребность в ресурсах определяется теми же способами, что и продолжительность работ, с аналогичными замечаниями относительно надёжности результатов. Резерв в этом случае не предусматривается: он не снизит риски, а только увеличит простои ресурсов. Стоимостные показатели определяются: для трудовых ресурсов — согласно штатному расписанию, тарифным сеткам или расценкам, существующим на рынке труда; для других ресурсов — согласно эксплуатационным сметам, рыночным ценам или арендной плате, запрашиваемой владельцами данных или аналогичных ресурсов. Часто организации, занимающиеся управлением проектами, ведут собственные систематически обновляемые базы данных стоимостной информации. После определения трудоемкости работ необходимо определить график их выполнения и общие сроки реализации проекта — составить расписание работ по проекту. Базовое расписание — утвержденный план-график с указанными временными фазами проекта, контрольными точками и элементами иерархической структуры работ. Пример. В качестве примера рассмотрим проект "Разработка программного комплекса". Предположим, что проект состоит из работ, характеристики которых приведены в табл.1. Таблица 1. Номер работы Название работы Длитель-ность Исполнитель 1 Начало реализации проекта - 2 Постановка задачи 10 Постановщик 3 Разработка интерфейса 5 Программист1 4 Разработка модулей обработки данных 7 Программист1 5 Разработка структуры базы данных 6 Программист2 6 Заполнение базы данных 8 Программист2 7 Отладка программного комплекса 5 Программист1 Программист2 8 Тестирование и исправление ошибок 10 Программист1 Программист2 Постановщик 9 Составление программной документации 5 Постановщик 10 Завершение проекта - Диаграммы, описывающей последовательность выполнения работ Диаграмма Ганта Базовое расписание может быть наиболее наглядно представлено диаграммой Ганта. Диаграмма Ганта отображает следующие параметры проекта: 1. структуру декомпозиции работ; 2. состав используемых ресурсов и их распределение между работами; 3. календарные даты, к которым привязываются моменты начала и завершения работ. В этой диаграмме плановые операции или элементы иерархической структуры работ перечислены с левой стороны, даты отображаются сверху, а длительность операций показана горизонтальными полосками от даты начала до даты завершения. Источники данных, используемые при разработке модели проекта, во многом определяют степень её достоверности, а значит, и качество управления проектом. Результаты моделирования проекта наиболее чувствительны к данным о продолжительности работ. Наиболее надёжным источником сведений о продолжительности работ служит опыт прошлых проектов, при выполнении которых производились аналогичные работы. Во многих случаях о продолжительности предстоящих работ можно судить по опыту проектов, предусматривавших выполнение схожих работ, если ввести необходимые корректировки. При отсутствии собственного опыта организация может воспользоваться опытом других организаций, поддерживающих с ней партнёрские отношения. Данный источник следует использовать всякий раз, когда он доступен, исключая случаи, когда имеющийся опыт отражает выполнение работы в экстраординарных условиях. Если опыт прошлых проектов привлечь невозможно, продолжительность наиболее ответственных работ, которые предположительно могут оказаться на критическом пути, рассчитывают на основе технологических карт или других документов, описывающих технологию выполнения работы. Этот способ весьма трудо- и времяёмок; он не отражает фактические изменения продолжительности работы в случаях отклонения технических условий выполнения работы от нормативных; к тому же технологические карты не всегда содержат информацию, необходимую для однозначного установления продолжительности работы. Третий по надёжности способ — использование опубликованных нормативов продолжительности работ либо разработка собственных внутрифирменных нормативов с привлечением методов нормирования. Реальные затраты времени могут, однако, существенно отличаться от норматива, установленного для определённых целей: например, для контроля, анализа с целью выявления узких мест в проектной деятельности и т.д. Но при отсутствии другой информации нормативные данные позволяют составить представление о вероятной продолжительности работы. Следует также иметь в виду, что разработка внутрифирменных нормативов продолжительности предстоящих работ — весьма дорогостоящее мероприятие, оправданное лишь для тех работ, которые имеют значительные шансы оказаться критическими. Последний способ — экспертную оценку продолжительности работ — следует применять тогда, когда ни один из предыдущих неприменим. Он тем надёжнее (и дороже), чем больше экспертов опрошено с целью установления продолжительности работы, но, сколько бы экспертов ни удалось опросить, нельзя быть уверенным, что в их представлении о продолжительности работ не содержится систематической ошибки, одной и той же для всех или большинства опрошенных экспертов. Этот метод чаще других становится причиной ошибочного определения продолжительности всего проекта. Если работа, продолжительность которой из-за отсутствия времени или средств на более глубокое изучение вопроса определена экспертом (экспертами), оказалась на критическом пути, целесообразно вернуться к её определению методами нормирования или на основе технологических карт. В столбце «примечание» таблицы работ целесообразно указывать, каким способом определена продолжительность работы и в какой степени эта информация заслуживает доверия. После определения ожидаемой продолжительности работ, как показывает практика, целесообразно увеличить её значения на некоторый резерв (в процентах к ожидаемой продолжительности). Резерв этот менеджеру следует согласовать с руководителем проекта, чтобы разделить с ним ответственность за возможный срыв сроков проекта из-за недостаточного запаса либо за потери, обусловленные неполным использованием возможностей скорейшего завершения проекта, если план предусматривал чрезмерный резерв. Величина резерва зависит от специфики области проектной деятельности. Существуют проекты, для которых предусматривать запас времени бессмысленно. Информация о связях между работами обычно берётся из технического проекта либо определяется экспертами. Здесь риск ошибки значительно меньше, чем при определении продолжительности работ, зато цена ошибки может оказаться выше. На практике проблемы обычно возникают не из-за неправильного определения связей между работами, а из-за ошибок при вводе модели проекта в ЭВМ. Поэтому, получив первоначальный вариант сетевого плана, целесообразно обсудить полученный критический путь с экспертами с целью выявления ошибочных связей, назначенных по крайней мере критическим работам. При реализации самых ответственных проектов можно поручить разработку предварительного варианта модели проекта двум независимым менеджерам (или командам менеджеров), что позволит сравнить оба варианта и прийти к согласованному решению, устранив причины расхождений. Потребность в ресурсах определяется теми же способами, что и продолжительность работ, с аналогичными замечаниями относительно надёжности результатов. Резерв в этом случае не предусматривается: он не снизит риски, а только увеличит простои ресурсов. Стоимостные показатели определяются: для трудовых ресурсов — согласно штатному расписанию, тарифным сеткам или расценкам, существующим на рынке труда; для других ресурсов — согласно эксплуатационным сметам, рыночным ценам или арендной плате, запрашиваемой владельцами данных или аналогичных ресурсов. Часто организации, занимающиеся управлением проектами, ведут собственные систематически обновляемые базы данных стоимостной информации. Диаграмма Ганта позволяет по заданным значениям длительностей работ найти критические работы проекта и его критический путь. Критической называется такая работа, для которой задержка ее начала приведет к задержке срока окончания проекта в целом. Такие работы не имеют запаса времени. Некритические работы имеют некоторый запас времени, и в пределах этого запаса их начало может быть задержано. Критический путь проекта (Critical path) — самая длинная цепочка работ в проекте. Суммарная длительность работ критического пути определяет минимальное время реализации проекта. Увеличение длительности любой работы в этой цепочки приводит к увеличению длительности всего проекта. В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей. Практическая рекомендация: на критическом пути должны стоять работы с нежесткими связями, которые всегда можно перепланировать, если возникает угроза срыва сроков. Чтобы проиллюстрировать понятие критического пути рассмотрим пример «суперпроекта». Концепция проекта выглядит следующим образом. Цель проекта. Сделать завтрак в постель Результаты проекта. Завтрак в постели из вареного яйца, тоста и апельсинового сока. Ресурсы. Имеется один оператор и обычное кухонное оборудование. Сроки. Проект начинается на кухне в 8:00 и завершается в спальне. Критерий приемки. Используются минимальные трудовые ресурсы и срок. Конечный продукт имеет высокое качество: яйцо свежесваренное, тост теплый, сок холодный. Обоснование полезности. Проект служит достижению стратегических целей. Структура декомпозиции работ, ориентированная на конечный продукт, с оценкой их длительности представлена на рисунке 1. Рисунок 1. Структура декомпозиции работ «суперпроекта» На следующем шаги мы должны учесть зависимости между работами, например, нельзя жарить хлеб, пока мы его не нарезали. С учетом зависимостей мы получим следующую диаграмму расписания нашего проекта (Рисунок 2) Рисунок 2. Диаграмма расписания «суперпроекта» с учетом зависимостей между работами. В результате мы определили, что минимальный срок реализации нашего проекта составляет 10 минут. Однако мы не можем на этом остановиться, поскольку должны еще учесть ограничение по ресурсам. У нас только один оператор. Если мы посмотрим на диаграмму загруженности ресурсов (Рисунок 3), то увидим, что наш критический ресурс загружен на первой минуте на 400%. что недопустимо. Рисунок 3. Диаграма загруженности ресурсов в «суперпроекте» Следовательно, мы должны выполнить выравнивание ресурсов. Поскольку одним из критериев успеха проекта является его минимальная длительность, то если мы не хотим ее увеличивать, мы должны выявить критический путь в проекте (Рисунок 4) и не сдвигать работы, которые на нем находятся. Рисунок 4. Критический путь в «суперпроекте» Поэтому, после выравнивания ресурсов, расписание нашего проекта будет выглядеть следующим образом (Рисунок 5). Рисунок 5. Расписание «суперпроекта» после выравнивания ресурсов Теперь диаграмма загруженности ресурсов (Рисунок 6) выглядит приемлемо и у оператора даже появилось три минуты свободного времени на перекур. При этом общая длительность реализации проекта по-прежнему составляет 10 минут. Рисунок 6. Диаграмма загруженности ресурсов после выравнивания Сетевой график Сетевой график – это ориентированный граф, в котором вершинами обозначены работы проекта, а дугами – временные взаимосвязи работ. Сетевой график должен удовлетворять следующим свойствам. 1. Каждой работе соответствует одна и только одна вершина. Ни одна работа не может быть представлена на сетевом графике дважды. Однако любую работу можно разбить на несколько отдельных работ, каждой из которых будет соответствовать отдельная вершина графика. 2. Ни одна работа не может быть начата до того, как закончатся все непосредственно предшествующие ей работы. То есть если в некоторую вершину входят дуги, то работа может начаться только после окончания всех работ, из которых выходят эти дуги. 3. Ни одна работа, которая непосредственно следует за некоторой работой, не может начаться до момента ее окончания. Другими словами, если из работы выходит несколько дуг, то ни одна из работ, в которые входят эти дуги, не может начаться до окончания этой работы. 4. Начало и конец проекта обозначены работами с нулевой продолжи­тельностью. Такие работы называются вехами и обозначают начало или конец наиболее важных этапов проекта. Сетевой график для проекта "Разработка программного комплекса". изображен на рис.1. На нем вершины, соответствующие обычным работам, обведены тонкой линией, а толстой линией обведены вехи проекта. На рис.1 критический путь показан пунктирными стрелками. Программное обеспечение управления проектами Системы управления проектами образуют отдельный сектор программного обеспечения, который достаточно широко представлен на российском рынке. Появление подобных систем способствовало преобразованию искусства управления проектами в науку, в которой имеются четкие стандарты, методы и технологии. 1. Стандарт, разработанный Институтом управления проектами (Project Management Institute) принят в качестве национального стандарта в США (стандарт ANSI). 2. Стандарт по качеству в управлении проектами ISO 10006. Применение этих технологий способствует своевременной реализации проектов в рамках выделенных бюджетов и с требуемым качеством. Наиболее известные и широко используемые из них — Microsoft Project, OpenPlan, Spider Project. Модели проекта, используемые в них, основаны на методе критического пути и отличаются лишь в деталях. Как правило, овладев одной из программ, не составляет труда воспользоваться любой другой. Все эти программы предназначены для автоматизации управления инвестиционными проектами. Они обеспечивают разработку детальных календарных планов, отслеживание (мониторинг) хода выполнения календарного плана и его оперативную корректировку применительно к меняющимся условиям. Большая часть работы по управлению проектом – это сбор и анализ информации о нём. Вышеназванные программные продукты обеспечивают достаточно удобные средства ввода, структурирования и анализа информации, автоматизации плановых расчётов и подготовки отчётов. Они обладают следующими возможностями: ♦ реализуют метод критического пути с учётом ресурсов, необходимых для выполнения предусмотренных проектом работ, и распорядка рабочего времени; ♦ обеспечивают согласование использования ресурсов, перенося часть работ на более поздние сроки, если некоторые ресурсы в дефиците; ♦ допускают вмешательство менеджера в процесс согласования использования ресурсов, предоставляя ему возможность произвольного сочетания приёмов согласования, описанных в предыдущем разделе. На российском рынке в настоящее время наиболее популярными являются несколько систем управления проектами - Microsoft Project, Spider Project, OpenPlan. Microsoft Office Project 2012 – это комплексное решение корпорации Microsoft по управлению корпоративными проектами, которое позволяет управлять проектами любой сложности и включает в себя семейство следующих программных продуктов: 1. MS Office Project Standart – пакет начального уровня для управления простыми проектами; 2. MS Office Project Professional – пакет для профессионального управления проектами любой сложности на любом уровне управления; 3. MS Office Project Server – серверный продукт, который используется для взаимодействия менеджеров проекта при управлении распределенными проектами; 4. MS Office Project Web Access – веб-интерфейс MS Project, позволяющий участникам проектов получить доступ к проектной информации через Internet Explorer. Программа Microsoft Project интегрирована в Microsoft Office, что упрощает её взаимодействие с базами данных, электронными таблицами, подготовку текстовых документов на основе создаваемых ею выходных документов и, при необходимости, публикацию их на сайтах корпоративных сетей или сети Интернет. Набор предлагаемых ею возможностей не столь широк, как в наиболее мощных программах аналогичного назначения, что вполне компенсируется: ♦ возможностью выполнения многих операций другими программами, входящими в состав семейства Microsoft Office; ♦ поддержкой универсального языка программирования VBA, общего для всех программных средств семейства, который даёт возможность использовать средства различных программ из одного и того же VBA-модуля; ♦ доступностью для освоения в приемлемый срок менеджером средней квалификации; ♦ развитыми средствами поддержки коллективного управления проектами; ♦ мощными и разнообразными (во многом, на наш взгляд, избыточными, неоправданно увеличивающими сложность программы) возможностями управления интерфейсом пользователя; ♦ умеренной ценой; ♦ наличием службы обучения и поддержки. По этим причинам Microsoft Project стала наиболее распространённой из числа программ, предназначенных для управления проектами. Spider Project Professional (также существуют версии Desktop и Lite, разработчик "Технологии управления Спайдер") - отечественная разработка, ориентированная преимущественно на российского пользователя. Обладая мощными средствами автоматизации управления ресурсами и богатыми сервисными возможностями, она отличается от вышеназванных учётом российских стандартов и практики календарного планирования. Данный пакет в отличие от западных аналогов, имеет следующие особенности: 1. встроенная система анализа рисков и управления резервами по срокам и стоимости работ; 2. возможность создания, хранения и включения в проекты типовых фрагментов проектов; 3. оптимизированная для российских условий организация групповой работы и мультипроектного управления. Open Plan (разработчик Welcom Software Technology, сейчас Deltek) обеспечивает полномасштабное мультипроектное управление, планирование по методу критического пути и оптимизацию использования ресурсов в масштабах предприятия. Может эффективно использоваться на всех уровнях контроля и управления проектами – от высшего руководства и менеджеров проектов, до начальников функциональных подразделений и рядовых исполнителей. Open Plan позволяет руководителям разного уровня выполнять следующие функции: 1. создавать оперативные планы проектов с учетом различных ограничений; 2. определять уровень приоритетности проектов; 3. задавать относительную степень важности проектов для распределения ресурсов; 4. минимизировать риски; 5. проводить анализ хода выполнения работ. Welcom предлагает использовать профессиональную и "облегченную" версию продукта в совокупности (OpenPlan Professional + OpenPlan Desktop), так как они полностью интегрированы. Программные продукты компании Primavera Inc: 1. Primavera Project Planner Professional – профессиональная версия, предназначенная для автоматизации процессов управления проектами в соответствии с требованиями PMI (Project Management Institute) и стандартами ISO. В первую очередь этот пакет предназначен для использования в составе корпоративной информационной системы, хотя вполне может работать и автономно, помогая решать задачи календарно-сетевого планирования, определения критического пути, выравнивания ресурсов, и других задач моделирования проектов, групп проектов, портфелей и программ. 2. SureTrack Project Manager ориентирован на контроль выполнения небольших проектов или фрагментов крупных проектов. Может работать как самостоятельно, так и совместно с Project Planner в корпоративной системе управления проектами. Нижеследующие программы используют метод критического пути и могут быть использованы на отдельных этапах процесса управления проектами. Программа 1С–Рарус фактически представляет собой субмодуль к модулю бухгалтерского учёта программы 1С–Предприятие — популярного в России средства комплексной автоматизации документооборота на фирме среднего масштаба. Она ориентирована не столько на управление проектами как таковыми, сколько на управление ресурсами предприятия, распределяемыми между различными задачами офисной и производственной деятельности. Тем не менее, она содержит необходимые средства для представления модели проекта и мониторинга процесса его выполнения. Глубокая интеграция в систему внутрифирменного документооборота делает программу 1С–Рарус хорошим выбором для организации, основным источником дохода которой являются торговая, финансовая деятельность или продажа услуг, а реализуемые ею проекты преследуют преимущественно внутрифирменные цели. Пользующаяся широкой известностью программа Project Expert фирмы Про-Инвест-ИТ, реализующая автоматизированную технологию разработки бизнес-плана в соответствии с российскими стандартами и требованиями российских банков, содержит блок составления сетевого плана, основанный на методе CPM. Программа ориентирована на специалистов по бизнес-планированию и анализу проектов, поэтому не предусматривает развитых средств мониторинга. Однако составленная при её помощи модель проекта может быть экспортирована в специализированные программы для управления проектом, используемые менеджерами. Информацию об этих и других программах, используемых менеджерами проектов, можно получить на сайте Российской ассоциации управления проектами (http://www.sovnet.ru). ОПИСАНИЕ МОДЕЛИ ПРОЕКТА СРЕДСТВАМИ MICROSOFT PROJECT Прежде чем использовать Microsoft Project для разработки сетевого плана, необходимо ввести данные, описывающие модель проекта. Программа Microsoft Project предусматривает множество способов ввода модели проекта: посредством диалоговых окон; непосредственно в таблицы работ и ресурсов; с использованием диаграмм. Основные формы представления данных в программе Microsoft Project следующие: ♦ график Ганта; ♦ таблица ресурсов; ♦ календарь. Project, как и все остальные приложения, связанные с пакетом Microsoft Office 2010, использует ленточный интерфейс. При первом запуске создаётся новый проект, и вы видите на экране окно, разделённое на две большие части (см. рис. 1). Окно Microsoft Project изображено на рис. 1 и состоит из следующих элементов: 1. строка меню; 2. строка ввода; 3. панель представлений; 4. рабочая область; 5. строка состояния. Рисунок 1 – Окно Project 2010 Панель представлений используется для переключения между представлениями рабочей области окна. Все данные о проекте хранятся в единой базе данных, состоящей из большого количества полей. Представление – это способ отображения части связанных между собой данных из общей базы данных проекта. В системе реализовано достаточно большое количество представлений – диаграмма Ганта, сетевой график, календарь, график ресурсов и т.д. При желании можно изменять стандартные представления, добавляя или удаляя отображаемые в их таблицах поля данных. При первом запуске программы панель представлений может отсутствовать. Переключение между представлениями производится щелчком мыши по значку нужного представления. Рабочая область предназначена для отображения выбранного представления. При первом запуске Microsoft Project 2010 слева отображается таблица, похожая на лист Excel, справа – поле с календарём. Она может содержать таблицы, диаграммы, графики, формы и используется как для просмотра, так и для редактирования данных проекта. Приемы работы с рабочей областью зависят от представления и будут рассмотрены в лабораторных работах. Строка состояния являются стандартными для всех Windows-приложений, и приемы работы с ними такие же, как и в Microsoft Office. Режимы планирования В Microsoft Project 2010 имеется два режима планирования – ручное или автоматическое. • Автоматическое планирование обозначает, что задачи этого типа назначаются с помощью модуля планирования проекта с учетом ограничений, зависимостей, календарей проектов и ресурсов. Автоматическое планирование встречалось во всех предыдущих версиях Microsoft Project. • Ручное планирование обозначает, что задачи этого типа можно расположить в любом месте расписания без изменения их расписания в проекте. Они не перемещаются, поскольку представляют собой связанные сведения об изменении задач, т.е. Microsoft Project никогда не изменяет даты планируемых вручную задач, но может выдавать предупреждения при наличии потенциальных проблем с введенными значениями. Можно изменить параметры задачи, чтобы ее планирование выполнялось автоматически. В этом случае программа Project будет планировать задачу на основе зависимостей, ограничений, календарей и других факторов. Ручное планирование предпочтительней использовать когда не известны точные даты основных вех, и когда этапы проекта не конкретным и/или полностью не определены. Создание нового проекта Для создания нового проекта прежде всего необходимо задать ключевые параметры проекта в окне сведений о проекте (пункт меню Проект/Сведения о проекте), изображенном на рис. 2. Установки этого пункта имеют определяющее значение для всего последующего процесса планирования. Рис. 2.  Окно сведений о проекте В системе возможно два варианта планирования проекта, задаваемых полем Планирование. 1. Значение даты начала проекта означает, что фиксируется начальная дата проекта. Эта дата становится директивной датой начала первой работы. Остальные работы планируются как можно раньше, т.е. для них назначаются самые ранние из возможных сроки начала работ. Дата окончания проекта является вычисляемой величиной и не может быть изменена вручную. 2. Значение даты окончания проекта позволяет зафиксировать конечную дату проекта. Эта дата становится директивной датой завершения последней работы. Остальные работы планируются как можно позже, т.е. для них назначаются самые поздние из возможных сроков окончания работ. Дата начала проекта является вычисляемой и не может быть изменена вручную. Поле Календарь устанавливает календарь (график) рабочего времени, используемый по умолчанию при планировании работ. В качестве такового следует использовать календарь, по которому работает большинство сотрудников, занятых в проекте. В системе предопределены три базовых календаря: 1. стандартный – соответствует обычной 40-часовой рабочей неделе с часовым перерывом и выходными в субботу и воскресенье. Рабочим считается время с 9 до 18 часов; 2. 24 часа – непрерывный календарь рабочего времени без перерывов и выходных. Используется для планирования непрерывных технологических процессов (например, выплавка стали); 3. ночная смена – календарь, в котором используется 40-часовая рабочая неделя, но рабочим считается время с 23 до 8 часов с часовым перерывом. Предопределенные календари могут не соответствовать графику работы организации, поэтому Стандартный календарь не учитывает официальные праздники и выходные дни, принятые в конкретной организации. Кроме того, график работы организации в течение рабочего дня может не совпадать со стандартным. Поэтому менеджер проекта имеет возможность изменить предопределенный календарь или создать свой собственный. Семейство календарей проекта состоит из календарей трех видов: базовые, календари ресурсов и календари задач. Базовый календарь – некоторая заготовка календаря, которая соответствует графику рабочего времени организации, подразделения, сотрудников, совместителей, подрядчиков, отдельных работ проекта. Один из базовых календарей (Стандартный) должен соответствовать наиболее распространенному в организации графику рабочего времени и используется как календарь по умолчанию. Календарь ресурса – задает график работы отдельных исполнителей или групп исполнителей. Этот календарь должен учитывать конкретные особенности рабочего времени сотрудников: отпуска, командировки, отгулы, пропуски по больничным листам и т.п. В качестве календаря ресурса используется один из предварительно созданных базовых календарей. Календарь задачи – индивидуальный календарь реализации некоторой задачи (работы) проекта, отличающийся от стандартного. Календарь задачи должен учитывать ее специфику и особенности. Он назначается из перечня предварительно созданных базовых календарей. Создание и редактирование базовых календарей происходит в пункте меню Сервис/Изменить рабочее время. Окно для работы с календарем изображено на рис. 3. Рис.3.  Окно настройки календарей Поле Дата отчета устанавливает дату, для которой будут рассчитываться характеристики проекта при формировании системой различных форм отчетности. В основном, этот параметр влияет на показатели проекта, относящиеся к этапу его реализации, что будет рассматриваться в соответствующем разделе. Для сохранения нового проекта следует выбрать пункт меню Файл/Сохранить как и задать в открывшемся диалоге сохранения файла папку, тип файла – проект и имя файла. Сохранение существующего проекта выполняется пунктом меню Файл/Сохранить. В этом случае все параметры расположения файла проекта уже известны. Поэтому диалог не открывается и сохранение происходит автоматически. Для загрузки проекта нужно выбрать пункт меню Файл/Открыть и в появившемся диалоге открытия файла выбрать ранее сохраненный файл проекта. Особенности планирования работ в системе Microsoft Project 2010 Работы проекта могут быть нескольких видов: 1. обычная работа (в дальнейшем обозначается словом работа или задача); 2. веха; 3. фаза; 4. суммарная задача проекта. Работа обозначает какие-то действия, направленные на выполнение некоторой части проекта. Веха – это работа нулевой длины. Вехи предназначены для фиксации в плане проекта контрольных точек, в которых происходят важные с точки зрения управления проектом события. Например, завершение одного этапа работ и начало другого. Обычно вехи используются для обозначения начала и окончания проекта, а также для обозначения конца каждой фазы. Фаза – это составная работа, состоящая из нескольких работ и завершаемая вехой. Фаза описывает определенный логически законченный этап проекта и может состоять как из работ, так и из других фаз. Для разграничения работ и фаз в системе принято следующее правило. Все работы разделены на уровни, задающие их иерархию. Любая работа, имеющая подчиненные работы низшего уровня, является фазой. Все остальные работы фазами не являются. Суммарная задача проекта – это искусственно создаваемая системой работа, длительность которой равна длительности всего проекта. Эта работа используется для вычисления, отображения и анализа обобщенных данных о проекте, используемых им ресурсах и его стоимостных характеристиках. Связь между задачами определяет, каким образом время начала или окончания одной задачи влияет на время окончания или начала другой. В Microsoft Project существует четыре типа связей: 1. окончание–начало; 2. начало–начало; 3. окончание–окончание; 4. начало–окончание. Связь типа окончание–начало – это наиболее распространен­ный случай связи между работами. При такой связи работа В не может начаться раньше, чем закончится работа А. Этот тип связи изображен на рис. 7а. Связь типа начало–начало означает, что работа В не может начаться, пока не начнется работа А. При помощи такой связи обычно объединяются задачи, которые могут выполняться параллельно. Например, обучение персонала работе с программой и ввод данных в программу могут проходить одновременно, но ввод данных не может начаться, пока не начнется обучение персонала. Связь начало–начало изображена на рис. 7б. Связь окончание–окончание обозначает зависимость, при которой задача В не может закончиться до тех пор, пока не закончится задача А. Обычно такой связью объединяются работы, которые выполняются одновременно, но при этом одна не может закончиться раньше другой. Например, ввод в эксплуатацию программы и ее тестирование и отладка могут выполняться параллельно. В процессе ввода в эксплуатацию происходит обучение персонала, подготовка и ввод данных. Однако ввод в эксплуатацию не может быть завершен, пока не завершено тестирование и исправление найденных в программе ошибок. Связь окончание–окончание изображена на рис. 7в. Связь типа начало–окончание обозначает зависимость, при которой работа В не может закончиться, пока не началась работа А. Например, А – ввод программы в промышленную эксплуатацию, начало которого намечено на строго определенную дату. В – опытная эксплуатация программы, которая не может быть закончена, пока не начнется ввод программы в промышленную эксплуатацию. При этом увеличение длительности задачи А не влечет увеличение длительности задачи В. Связь начало–окончание изображена на рис. 4г Рис. 4.  Типы связей между работами На этом рисунке прямоугольником изображена длительность работы. Левая сторона прямоугольника соответствует началу работы, а правая – окончанию. Взаимное расположение сторон, связанных стрел­ками, характеризует зависимость между началом и окончанием работ. При планировании реальных проектов часто оказывается, что изображенных на рис. 4 связей между работами оказывается недоста­точно. Например, работы "тестирование программного комплекса и исправление ошибок" и "составление программной документации" не обязательно должны строго следовать друг за другом. Составление документации может быть начато, не дожидаясь окончания тестирования. Для таких случаев в Microsoft Project предназначены задержки и опережения. На рис. 5 изображено их влияние на связи типа окончание–начало (а), начало–начало (б), окончание–окончание (в) и начало–окончание (г). Левый рисунок соответствует задержке, а правый – опережению. Рис. 5.  Действие задержки и опережения Нередко некоторые работы проекта нужно привязать к реальной календарной дате. Например, представитель заказчика приезжает 15 сентября для ознакомления с разрабатываемой программой. Поэтому работа "Подготовка демонстрационной версии" должна быть закончена не позднее 15 сентября. Подобная привязка работы к дате называется ее ограничением. В табл. 1 приведены используемые в Microsoft Project ограничения работ и их действие. Ограничение является жестким условием и влияет на процесс планирования: система ведет планирование так, чтобы выполнить все заданные ограничения. Альтернативой ограничениям являются крайние сроки. Крайний срок – это дата, позже которой задача не может быть завершена. Однако, в отличие от ограничения, наличие крайнего срока не оказывает влияния на процесс планирования. Система лишь сигнализирует соответствующими индикаторами о наличии или нарушении установленного крайнего срока. Таблица 1 Тип ограничения Действие ограничения Как можно раньше Задача размещается в расписании как можно раньше. Это ограничение используется по умолчанию при планировании проекта от даты его начала Как можно позже Задача размещается в расписании как можно позже. Это ограничение используется по умолчанию при планировании проекта от даты его окончания Окончание не позднее заданной даты Указанная в ограничении дата задает самую позднюю дату завершения работы. Для проекта, планируемого от даты окончания, это ограничение назначается работе, если для нее явно указать дату ее окончания Начало не позднее указанной даты Заданная дата означает наиболее позднюю дату начала работы. Для проекта, планируемого от даты окончания, это ограничение назначается работе, если явно указать дату ее начала Окончание не ранее заданной даты Эта дата задает наиболее ранний срок завершения работы. Для проекта, планируемого от даты начала, это ограничение назначается работе, если явно указать дату ее окончания Начало не ранее заданной даты Эта дата означает наиболее ранний срок начала работы. Для проекта, планируемого от даты начала, это ограничение назначается работе, если явно указать дату ее начала Фиксированное начало Работа всегда будет начинаться с указанной даты. Связи с предыдущими и последующими работами не способны изменить положение такой задачи в расписании Фиксированное окончание Работа всегда будет заканчиваться в указанную дату. Ее связи с другими задачами не способны изменить эту дату Некоторые задачи могут носить регулярный, повторяющийся характер (еженедельная профилактика, составление месячной или квартальной отчетности и т.п.). Такие задачи называются повторяющимися. Ввод данных о задачах проекта После создания проекта, настройки его параметров и календарей, следует ввести данные о работах проекта. Ввод данных выполняется в следующей последовательности: 1. составить полный перечень работ, выделив в нем фазы и вехи; 2. ввести перечень фаз, задач и вех проекта; 3. создать связи между задачами; 4. для каждой задачи определить длительность; 5. установить типы связей, задержки и опережения; 6. установить точную дату начала или окончания проекта; 7. задать ограничения, крайние сроки и календари задач. Составление перечня задач начинается с выделения этапов проекта. Каждому этапу будет соответствовать фаза. При необходимости, особенно для крупных проектов, этапы могут разделяться на более мелкие этапы. В этом случае фаза будет состоять из более мелких фаз. Когда перечень этапов готов, составляется список задач, выполняемых на каждом этапе. В качестве последней работы этапа используется задача нулевой длины, которой соответствует веха. В качестве примера рассмотрим проект "Разработка программного комплекса". Предположим, что проект состоит из работ, характеристики которых приведены в табл. 2. Таблица 2 Номер работы Название работы Длительность 1 Начало реализации проекта 2 Постановка задачи 10 3 Разработка интерфейса 5 4 Разработка модулей обработки данных 7 5 Разработка структуры базы данных 6 6 Заполнение базы данных 8 7 Отладка программного комплекса 5 8 Тестирование и исправление ошибок 10 9 Составление программной документации 5 10 Завершение проекта Перечень его фаз, задач и вех приведен в табл. 3 Таблица 3 № Название Вид Задачи 1 Начало реализации проекта Веха 2 Программирование Фаза 3 Постановка задачи Задача 4 Разработка интерфейса Задача 5 Разработка модулей обработки данных Задача 6 Разработка структуры базы данных Задача 7 Заполнение базы данных Задача 8 Программирование завершено Веха 9 Отладка Фаза 10 Отладка программного комплекса Задача 11 Тестирование и исправление ошибок Задача 12 Составление программной документации Задача 13 Отладка завершена Веха 14 Конец проекта Веха Вехи начала и конца проекта не относятся ни к одной из фаз, поскольку относятся к проекту в целом. Остальные работы и вехи расположены непосредственно ниже фазы, к которой они принадлежат. Проект состоит из множества небольших задач, которые необходимо выполнить для успешного завершения. Ввод перечня задач проекта выполняется в любом из представлений, имеющем таблицу для ввода данных. Лучше всего для этого подходит Диаграмма Ганта, в которой помимо таблицы отображается календарный график проекта. Для ввода задачи достаточно в пустой строке таблицы ввести ее название в столбец Название задачи. Не нужно писать в названии длинных текстов. Чем короче, тем лучше, лишь бы потом было понятно. Непременное условие ввода: задачи, входящие в некоторую фазу должны следовать в таблице непосредственно после названия этой фазы. По умолчанию длительность новой задачи принимается равной одному дню, а дата начала задачи – дате начала проекта. Рядом с величиной длительности изображается вопросительный знак, что говорит о том, что это значение длительности является предварительным и задано системой. После назначения длительности пользователем вопросительный знак исчезает. Для преобразования задачи в веху достаточно установить нулевую длительность работы. Для преобразования задачи в фазу нужно выполнить следующие действия: 1. проверить правильность расположения названия фазы и названий входящих в нее задач (они должны быть расположены непосредственно после фазы); 2. выделить все входящие в фазу задачи, используя в качестве области выделения номера задач (кроме самой фазы); 3. нажатием кнопки (увеличить отступ) выделенные задачи помещаются на один уровень иерархии ниже и подчиняются первой предшествующей им не выделенной задаче, которая становится фазой. Результат преобразования задач в вехи и фазы изображен на рис. 6. Вехи изображены на диаграмме ромбиками с указанием даты, а фазы – горизонтальными скобками, охватывающими все свои задачи от момента начала первой и до момента окончания последней. В заголовок фазы помещается значок структуры или , предназначенный для сворачивания/разворачивания перечня включенных в нее задач. Рис. 6.  Результат преобразования задач в вехи и фазы В настоящий момент мы имеем не совсем корректную картину, т.к. задачи не должны начинаться в одно время – между ними имеются определённые зависимости. Так, программирование следует начинать после разработки проекта базы данных, XSL-вёрстка осуществляется на основе HTML-шаблона, а раскрутку незавершённого сайта делать невозможно. Давайте зададим зависимости между нашими задачами. Последовательность задач определяется ориентируясь на приоритеты задач и особенности технологии Создание связей между задачами выполняется как непосредственно в календарном графике, так и в таблице ввода данных. Самый простой способ установления связей – перетаскивание одного временного отрезка на другой. При этом курсор принимает вид небольшой цепочки, а за ним тянется прямая линия. На календарном графике следует навести указатель мыши на значок задачи, нажать левую кнопку мыши и, не отпуская ее, переместить указатель на значок другой задачи, после чего отпустить мышь. Между ними будет установлена связь. Связывание задач в таблице ввода данных выполняется при помощи столбца Предшественник, в который вводятся номера непосредственно предшествующих задач, разделенные точкой с запятой. Создание линейной последовательности связей можно выполнить так: 1. выделить в таблице все последовательно связываемые задачи: 2. выбрать пункт меню Правка/Связать задачу – связи устанавливаются в соответствии с последовательностью выделения задач. Календарный график проекта "Разработка программного комплекса" после создания связей изображен на рис. 7. Рис. 7.  Результат добавления связей между задачами Назначение длительности задач Это можно сделать это в явном виде, введя даты начала и окончания каждой задачи, но тогда вы лишите себя гибкости в управлении. Лучше указывать предполагаемую длительность в соответствующем столбце. По умолчанию длительность задается в днях. Однако единицу измерения можно изменить, указав ее рядом с числовым значением. Например, 10д означает 10 дней, 10ч – 10 часов, 10м – 10 минут, 10мес – 10 месяцев. Знак вопроса в этом столбце означает предполагаемую длительность, но мы пока не будет пользоваться этой возможностью. Результат преобразований изображен на рис. 7. На календарном графике автоматически учтены заданные в календаре рабочего времени выходные и праздничные дни. Если работа прерывается нерабочими днями, ее календарная длительность будет увеличена на количество прервавших ее дней. Рис. 7.  Результат ввода длительности задач По умолчанию создаваемая связь имеет тип "окончание-начало" без задержек или опережений. Уточнение типа связей и ввод значений задержек или опережений может быть выполнено тремя способами. 1. Первый способ – двойной щелчок мыши по линии со стрелкой, обозначающей связь между задачами на календарном графике. В открывшемся окне Зависимость задач имеется всего два поля: тип и запаздывание. Тип принимает одно из четырех значений: ОН (окончание–начало), НН (начало–начало), ОО (окончание–окончание), НО (начало–окончание). Запаздывание задается числом и единицей измерения, аналогично длительности задачи. Положительное значение запаздывания означает задержку работы-последователя, отрицательное значение – опережение. Помимо двух полей окно имеет кнопку Удалить для удаления связи. Этот способ не очень удобен тем, что при большом количестве работ и связей между ними найти нужную связь на календарном графике может оказаться непросто. 2. Второй способ – окно Сведения о задаче (двойной щелчок мыши по строке задачи), на вкладке Предшественники которого находится таблица с перечнем всех задач-предшественников. Столбцы Тип и Запаздывание этой таблицы устанавливают свойства соответствующей связи. Для удаления связи нужно в качестве типа связи выбрать значение Нет. 3. Третий способ – редактирование связей при помощи формы. Этот способ применяется, когда требуется редактировать большое количество связей. Дата начала/окончания проекта устанавливается в окне сведений о проекте, изображенном на рис. 2. После ее изменения система автоматически перепланирует проект с учетом нового значения. Ограничения, крайние сроки и календари задач устанавливаются в окне Сведения о задаче на вкладке Дополнительно, которая изображена на рис. 8. Рис. 8.  Вкладка Дополнительно окна сведений о задаче Ограничение задается полями Тип ограничения и Дата ограничения. В эти поля вводятся соответственно тип ограничения (см. табл. 2) и дата, в том случае, когда тип ограничения требует указать конкретную дату. Крайний срок вводится в поле Крайний срок. Задача, для которой установлено ограничение помечается значком в столбце идентификаторов таблиц представлений. Установленный крайний срок обозначается значком на диаграмме Ганта. Календарь задачи выбирается из числа базовых календарей в поле Календарь. По умолчанию это поле содержит Нет. В этом случае задача планируется по стандартному календарю и календарю назначенных на нее ресурсов. Если указать календарь задачи, она будет планироваться на периоды времени, которые являются рабочими как в календаре задачи, так и в календаре ее ресурсов. В этом же окне имеется поле Код СДР, которое содержит уникальный код задачи в структуре проекта. По умолчанию этот код автоматически формируется системой. Пользователь сам может определить порядок формирования кода СДР при помощи пункта меню Проект/СДР/Определить код. Добавление в проект повторяющейся задачи выполняется при помощи пункта меню Задача/Задача/Повторяющаяся задача, который открывает окно ее свойств (рис. 9), задающее сроки и периодичность повторения. В качестве примера используется задача Профилактика, которая имеет длительность один день, проводится раз в две недели с 30 июня по 30 сентября. Рис. 9.  Окно свойств периодической задачи Результат планирования этой задачи на диаграмме Ганта изображен на рис.17. Рис. 17.  Периодическая задача на диаграмме Ганта РЕСУРСЫ И НАЗНАЧЕНИЯ 1. Создание списка ресурсов Ресурс– это трудовая, материальная, финансовая, техническая или иная единица, которая используется для выполнения задач проекта. В Microsoft Project ресурсы могут быть трех видов: • Трудовые – это работники или коллективы, выполняющие запланированные в рамках проекта работы. • Материальные –материалы, которые потребляются при выполнении работ проекта. • Затратные – различные виды денежных расходов сопряженных с работами проекта, которые напрямую не зависят от объема, длительности работ и потребляемых ими трудовых или материальных ресурсов. Например, стоимость железнодорожных или авиационных билетов, командировочные расходы и т.п. Основными характеристиками трудового ресурса являются. 1. График доступности. Задает периоды времени, когда ресурс может быть задействован для выполнения работ проекта. Этот график может учитывать отпуска, командировки, занятость ресурса в других проектах и т.п. 2. Индивидуальный календарь рабочего времени. Задает график рабочего времени ресурса. 3. Стоимость. Она складывается из двух составляющих: повременной оплаты (стандартная и сверхурочная ставки), которая начисляется пропорционально длительности работы ресурса в проекте, и стоимости использования, которая является разовой фиксированной суммой, не зависящей от времени работы; 4. Максимальное количество единиц доступности. Устанавливает максимальный процент рабочего времени, которое ресурс может ежедневно выделять для выполнения работ данного проекта. Например, 50% – половина рабочего времени установленного в день по календарю. Данная величина не препятствует планированию большего процента участия ресурса в проекте, но используется для контроля его перегруженности. Так для ресурса с 50% максимальной доступности можно запланировать все 100% использования, но при этом он будет считаться перегруженным на 50%. Материальный ресурс характеризуется только стоимостью, складывающейся из двух частей. 1. Стандартная ставка. Задает стоимость единицы материала. Общая стоимость материала вычисляется как произведение потребленного количества на значение стандартной ставки. 2. Стоимость использования. Фиксированная сумма, которая не зависит от количества потребляемых материалов. Например, стоимость доставки. Для создания списка ресурсов, задействованных при выполнении проекта, нужно выбрать представление Лист ресурсов или пункт меню Вид/Лист ресурсов. Это представление изображено на рис. 1. Ввод перечня ресурсов заключается в последовательном заполнении строк таблицы их названиями и выбором типа ресурса в колонке Тип. Для редактирования остальных параметров ресурса используется окно его свойств. Рис. 1. Лист ресурсов проекта 2. Окно свойств ресурса Окно свойств ресурса открывается двойным щелчком мыши по соответствующей строке таблицы ресурсов и содержит вкладки Общие, Затраты, Заметки, Настраиваемые поля. Вкладка Общие изображена на рис. 2. Здесь вводятся название, краткое название ресурса, его тип, график доступности, максимальное количество единиц доступности и индивидуальный календарь рабочего времени. Рис. 2. Вкладка Общие окна свойств ресурса График доступности задается только для трудовых ресурсов и вводится в таблицу, состоящую из трех столбцов: 1. Доступен с – начальная дата периода доступности ресурса (значение НД означает неограниченный начальный срок); 2. Доступен по – конечная дата периода доступности (НД означает неограниченный конечный срок); 3. Единицы – максимально возможный процент рабочего времени от установленного по индивидуальному календарю, который ресурс может потратить ежедневно на выполнение работ проекта. При использовании ресурса свыше заданного процента он будет считаться перегруженным на величину превышения. Поля Группа и Код позволяют сгруппировать ресурсы по группам и назначить им определенные коды. Их значения используются для выполнения операций фильтрации и группировки. Тип резервирования принимает одно из двух значений: 1. выделенный – ресурс принимает участие в проекте; 2. предложенный – ресурс может принять участие в проекте, но окончательное решение еще не принято. Кнопка Изменить рабочее время активна только для трудовых ресурсов. Она открывает индивидуальный календарь рабочего времени, приемы работы с которым совпадают с рассмотренными ранее в лекции 3 приемами обработки календаря. Вкладка Затраты предназначена для ввода стоимости как трудовых, так и материальных ресурсов. Она изображена на рис. 3. Рис. 3. Вкладка Затраты окна свойств ресурса 3. Понятие назначения Назначение – это сопоставление задаче перечня трудовых, материальных или затратных ресурсов, которые будут задействованы при ее выполнении. При назначении трудовых ресурсов указывается объем назначения ресурса, выделяемый для данной задачи. Он измеряется в процентах от рабочего времени по индивидуальному календарю ресурса. 100% означает занятость ресурса исключительно данной задачей. При назначении материальных ресурсов указывается либо фиксированное количество его единиц измерения, расходуемых на всю задачу, либо скорость потребления за некоторый период времени (например, количество штук в день). При назначении затратных ресурсов указывается сумма затрат. Задача, получившая назначение трудовых ресурсов, приобретает три взаимосвязанных параметра: • длительность, • трудозатраты, • объем назначения ресурсов. Трудозатраты измеряются в часах, которые должны отработать трудовые ресурсы для успешного завершения всей задачи. Например, если задача длится 5 дней и ее выполняет один работник со стандартным 8-часовым рабочим днем, то ее трудозатраты равны 40ч. Если же используется 2 работника – 80ч. Трудозатраты рассчитываются по формуле: где L – длительность задачи, V – объем назначений ресурса, H – ежедневная длительность работы ресурса в часах, а сумма берется по всем назначенным задаче трудовым ресурсам. Факт создания для задачи первого назначения трудовых ресурсов очень важен, поскольку в этот момент вычисляются ее трудозатраты. В этот же момент длительность задачи, трудозатраты и объем назначения ресурсов связываются в единое целое. В дальнейшем при попытке изменить любой из этих параметров, добавить или удалить трудовые ресурсы система самостоятельно пересчитывает значения остальных связанных параметров. Характер пересчета зависит от значения поля Тип задачи, который расположен в окне свойств задачи на вкладке Дополнительно, изображенной на рис. 5. Это поле имеет одно из трех значений: • Фиксированный объем ресурсов (ФОР). Устанавливается по умолчанию; • Фиксированная длительность (ФД); • Фиксированные трудозатраты (ФТ). Рис. 5. Окно свойств задачи В табл. 1 приведены зависимости длительности, трудозатрат и объема назначения ресурсов друг относительно друга для разных типов задач. Таблица 1. Длительности Трудозатрат Объема назначения ресурса Состава ресурсов ФОР Трудозатраты Длительность Длительность Трудозатраты ФД Трудозатраты Объем назначения Трудозатраты Трудозатраты ФТ Объем назначения Длительность Длительность Длительность Пример. • Тип задачи – фиксированный объем ресурсов, длительность – 5 дней, назначение – один трудовой ресурс объемом 100%, трудозатраты – 40ч. Вариант изменений: Результат: Длительность – 10 дней Трудозатраты – 80 часов Трудозатраты – 48 часов Длительность – 6 дней Объем назначения ресурса – 50% Длительность – 10 дней Добавляем аналогичный ресурс Трудозатраты – 80 часов • Тип задачи – фиксированная длительность, длительность – 5 дней, назначение – один трудовой ресурс объемом 100%, трудозатраты – 40ч. Вариант действий: Результат: Длительность – 10 дней Трудозатраты – 80 часов Трудозатраты – 48 часов Объем назначения ресурса – 120% Объем назначения ресурса – 50% Трудозатраты – 20 часов Добавляем аналогичный ресурс Трудозатраты – 80 часов • Тип задачи – фиксированные трудозатраты, длительность – 5 дней, назначение – один трудовой ресурс объемом 100%, трудозатраты – 40ч. Вариант действий: Результат: Длительность – 10 дней Объем назначения ресурса – 50% Трудозатраты – 48 часов Длительность – 6 дней Объем назначения ресурса – 50% Длительность – 10 дней Добавляем аналогичный ресурс Длительность – 2,5 дня Для упрощения зависимостей между длительностью, трудозатратами и объемом назначения ресурсов в окне свойств задачи имеется флажок Фиксированный объем работ (рис. 5). Его установка позволяет зафиксировать трудозатраты задач с фиксированным объемом ресурсов или фиксированной длительностью. По умолчанию этот флаг является включенным. В табл. 2 приведены зависимости параметров задач для этого случая. Таблица 2. Длительности Трудозатрат Объема назначения ресурса Состава ресурсов ФОР Трудозатраты Длительность Длительность Длительность ФД Трудозатраты Объем назначения Трудозатраты Трудозатраты Пример. • Тип задачи – фиксированный объем ресурсов, установлен флажок Фиксированный объем работ, длительность – 5 дней, назначение – один трудовой ресурс объемом 100%, трудозатраты – 40ч. Вариант действий: Результат: Длительность – 10 дней Трудозатраты – 80 часов Трудозатраты – 48 часов Длительность – 6 дней Объем назначений ресурса – 50% Длительность – 10 дней Добавляем аналогичный ресурс Длительность – 2,5 дня • Тип задачи – фиксированная длительность, установлен флажок Фиксированный объем работ, длительность – 5 дней, назначение – один трудовой ресурс объемом 100%, трудозатраты – 40ч. Вариант действий: Результат: Длительность – 10 дней Трудозатраты – 80 часов Трудозатраты – 48 часов Объем назначений ресурса – 120% Объем назначений ресурса – 50% Трудоемкость – 20 часов Добавляем аналогичный ресурс Объем ресурса – 50% Каждая задача может иметь свой собственный календарь из числа определенных в проекте базовых календарей. Календарь задачи устанавливается полем Календарь вкладки Дополнительно окна свойств задачи (рис.5). При расчете графика работы ресурса учитывается календарь задачи и индивидуальный календарь ресурса. При этом последний имеет больший приоритет. Если ресурс может работать больше по своему календарю, чем по календарю задачи, то он работает больше. Если же его календарь требует работать меньше, чем указано в календаре задачи, то он работает меньше. Для просмотра величины трудозатрат задач лучше всего использовать таблицу Использование в одном из представлений Диаграмма Ганта, Использование задач или Использование ресурсов. Эта таблица имеет столбец Трудозатраты, в котором находятся присвоенные задачам значения трудозатрат. 4. Создание назначений трудовых ресурсов Создание назначения трудовых ресурсов выполняется в окне свойств задачи на вкладке Ресурсы, изображенной на рис. 6. Это окно можно открыть двойным щелчком мыши по строке задачи в таблице любого из представлений задач. Щелчок мыши в поле Название ресурса первой пустой строки таблицы приводит к появлению списка всех введенных ранее ресурсов проекта, из которого следует выбрать необходимый. Далее в поле Единицы устанавливается объем назначения в процентах. Необходимо помнить, что трудозатраты задачи вычисляются после первого назначения. Поэтому все ресурсы следует назначать сразу, а не в несколько приемов. Столбец Затраты показывает стоимость эксплуатации используемых ресурсов в данной задаче. Рис. 6. Создание назначений трудовых ресурсов в окне свойств задачи После создания назначения система рассчитывает календарный график распределения трудозатрат ресурса, учитывая календари задачи и его собственный индивидуальный календарь, график его доступности и объем назначения. Для просмотра и анализа полученного графика трудозатрат предназначены следующие представления: 1. Использование задач (Вид/Использование задач); 2. Использование ресурсов (Вид/Использование ресурсов); 3. График ресурсов (Вид/График ресурсов). Отличительной особенностью представления Использование ресурсов является выделение факта перегрузки ресурсов: • в левой таблице красным цветом шрифта отмечается суммарная строка перегруженного ресурса (Постановщик на рис. 5.8); • в правой строке красным цветом отмечаются трудозатраты в те дни, когда имеется перегрузка. Представление График ресурсов изображено на рис. 9. Каждый его лист соответствует одному из ресурсов. По умолчанию на графике в виде гистограммы изображено распределение пиковой занятости ресурса. Значение 100% соответствует полной занятости в соответствии с индивидуальным календарем. Области перегрузки выделены красным цветом. При помощи контекстного меню области графика можно выбрать другой параметр, распределение которого будет изображено на графике (название отображаемого параметра написано в нижнем левом углу): 1. трудозатраты – гистограмма распределения абсолютных значений трудозатрат, 2. совокупные трудозатраты – график трудозатрат ресурса нарастающим итогом с начала проекта, 3. превышение доступности – на графике отображается только гистограмма распределения трудозатрат, превышающих максимально допустимый объем назначения, 4. процент загрузки – график загруженности ресурса в процентах от максимально допустимого объема его участия в проекте, 5. оставшаяся доступность – распределение свободных объемов трудозатрат, которые могут быть назначены ресурсу без его перегрузки, 6. затраты – график распределения затрат ресурса в ходе выполнения проекта, 7. совокупные затраты – график накопления затрат нарастающим итогом с начала проекта, 8. доступность по трудоемкости – график допустимой трудоемкости, которую можно назначить ресурсу, без учета уже выполненных назначений 9. доступность в единицах – график распределения максимально допустимого процента использования ресурса. Рис. 9. Представление График ресурсов АНАЛИЗ ПРОЕКТА Настраиваемые поля Настраиваемое поле – это зарезервированное поле базы данных проекта, которое изначально не содержит никаких значений. Такое поле используется для того, чтобы пользователь сам мог разместить в нем необходимое значение или формулу расчета значения, затем поместить это поле в какую-либо таблицу с целью его просмотра или выполнения операций фильтрации или группировки данных. В Microsoft Project имеются две непересекающиеся группы настраиваемых полей: 1. поля задач – в них заносятся параметры задач проекта; 2. поля ресурсов – содержат параметры ресурсов. Состав типов, количество полей и характеристика размещаемых в них данных для каждой группы полей совпадают и приведены в табл. 1. Таблица 1. Тип поля Количество полей Характеристика данных Дата 10 Даты Длительность 10 Длительность или трудозатраты Затраты 10 Данные о стоимости задач или ресурсов Код структуры 10 Код структуры из заданного перечня кодов Начало 10 Даты начала или другие даты Окончание 10 Даты окончания или другие даты Текст 30 Текстовые данные Флаг 20 Значения Да или Нет Число 20 Числа Таким образом, в системе предусмотрено 130 полей задач и 130 полей ресурсов. При этом каждое поле задач содержит индивидуальные значения для всех задач проекта, а каждое поле ресурса – для всех определенных в проекте ресурсов. Создание настраиваемого поля выполняется в окне Настраиваемые поля, изображенном на рис. 1 и открываемом выбором пункта меню Проект/Настраиваемые поля. Переключатели Задач и Ресурсов задают группу полей, с которой мы будем работать. Выпадающий список Тип позволяет выбрать тип поля согласно табл. 1 и отобразить полный перечень список полей этого типа (на рис. 1 изображен список полей типа Текст). Кнопка Переименовать позволяет задать имя поля, а Удалить – удаляет поле. При удалении восстанавливается первоначальное имя поля и теряются все ранее введенные в него значения. Кнопка Импорт поля позволяет импортировать его описание из другого проекта. Рис. 1.  Окно настройки полей Параметрический анализ Параметрический анализ заключается в том, что имеется некоторый показатель, характеризующий задачу или ресурс, который требуется проанализировать менеджеру проекта. Для реализации параметрического анализа используется одно или несколько настраиваемых полей, при помощи которых вычисляется значение такого показателя. Далее столбец соответствующего настраиваемого поля помещается в таблицу представления задач или ресурсов и выполняется собственно анализ путем сравнения значений или выполнения операций фильтрации, группировки или сортировки данных. Приведенная схема имеет слишком общий вид. Поэтому в качестве примера рассмотрим параметрический анализ длительностей задач. Вопрос оценки длительности задачи имеет важное значение с точки зрения качества планирования проекта. При заниженной длительности исполнителям не хватит времени для ее успешного завершения, в результате фактическая длительность и затраты превысят плановые показатели. Это, в конечном счете, приведет к более позднему завершению проекта и увеличению его бюджета. Завышенная длительность приведет к недозагруженности ресурсов, их нерациональному использованию и неэффективной растрате бюджета. Чтобы правильно оценить длительность задачи, менеджер должен обладать некоторым опытом в области планирования и управления релевантными проекту технологическими процессами. Однако, для некоторых задач существует способ ее оценки, опирающийся на некоторые показатели или характеристики этих задач. Например, длительность кладки стены зависит от количества кирпича (или площади стены), настила полов – от площади пола, ввода данных – от количества элементов данных и т.д. Для таких случаев и используется параметрический анализ длительности. Основной его идеей является назначение задачам некоторого параметра, который назовем УсловныйОбъемРаботы. Кроме него для задачи вводится параметр НормативнаяДлительность, значение которого равно длительности выполнения одной единицы условного объема. Тогда оценку длительности задачи можно рассчитать как произведение условного объема на нормативную длительность. Для реализации параметрического анализа нужно выполнить определенную последовательность действий. 1. Создать настраиваемое поле типа Флаг и назвать его ПараметрическаяЗадача. Это поле должно иметь значение Да для тех задач, длительность которых должна рассчитываться параметрически, и Нет для остальных. 2. Создать настраиваемое поле типа Число и назвать его УсловныйОбъемРаботы. 3. Создать два настраиваемых поля типа Длительность и назвать их НормативнаяДлительность и ОценкаДлительности. 4. Для поля ОценкаДлительности создать формулу, в которой перемножаются УсловныйОбъемРаботы и НормативнаяДлительность. 5. Создать таблицу представления с именем ПараметрическийАнализ, включив в нее поля Ид, Название, ПараметрическаяЗадача, УсловныйОбъемРаботы, НормативнаяДлительность, ОценкаДлитель. Окно создания таблицы представления изображено на рис. 4. 6. Переключиться в представление Диаграмма Ганта и выбрать таблицу ПараметрическийАнализ. Заполнить значение поля ПараметрическаяЗадача для всех задач проекта. 7. Заполнить поля УсловныйОбъемРаботы и НормативнаяДлительность для параметрических задач. 8. Сравнить столбцы ПараметрическаяДлительность и Длительность и при необходимости изменить значения в последнем. При желании можно установить фильтр по полю ПараметрическаяЗадача, который отображает только задачи со значением Да этого поля. Таблица ПараметрическийАнализ изображена на рис. 6.5. В примере значения флага ПараметрическаяЗадача обозначаются графическими индикаторами красного (Нет) и зеленого (Да) цвета. Рис. 4.  Окно создания таблицы представления Рис. 5.  Пример таблицы параметрический анализ 3. PERT-анализ длительностей задач Необходимо понимать при оценке проекта, это то, что любая оценка это всегда вероятностное утверждение. Если мы просто скажем, что трудоемкость данного пакета работ составляет М чел.*мес., то это будет плохой оценкой потому, что одно единственное число ничего не скажет нам о вероятности того, что на реализацию этого проекта потребуется не более, чем М чел.*мес. Вряд ли мы можем считать себя «предсказамусами», которые точно знают что произойдет в будущем и сколько потребуется затрат на реализацию этого пакета работ. Для того, чтобы понять, откуда берется неопределенность, рассмотрим простейший пример, попытаемся оценить трудоемкость добавления поля ввода телефонного номера клиента к уже существующей форме. Менеджер, наблюдающий работу программистов только со стороны, скажет, что эта работа потребует не больше 15 минут рабочего времени. Человек, умудренный программистским опытом, скажет, что эта работа может занять от 2 до 200 часов, и чтобы дать более точную оценку ему надо получить ответы на ряд вопросов: • Может ли вводиться несколько номеров? • Должна ли быть проверка номеров на действительность? • Простая или сложная проверка? • Если реализуем простую проверку, то не захочет ли клиент заменить ее на более сложную? • Должна ли проверка работать для иностранных номеров? • Можно ли воспользоваться готовым решением? • Каково должно быть качество реализации? Вероятность ошибки после поставки? • Сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя). Называя такую «размытую» оценку опытный программист резервирует все риски разработки, связанные с перечисленными неопределенностями данного требования, которые он вынужден принимать на себя, не имея в данный момент необходимой уточняющей информации. То, что наша оценка должна быть вероятностным утверждением, означает, что для нее существует некоторое распределение вероятности (Рисунок), которое может быть очень широким (высокая неопределенность) или достаточно узким (низкая неопределенность). Рисунок. Оценка — всегда вероятностная величина Если M — наиболее вероятное значение, то это не означает что это хорошая оценка, поскольку вероятность того, что фактическая трудоемкость превысит эту оценку, составляет более 50%. В программостроении уже стало банальностью то, что разработчики без достаточного основания называют слишком оптимистичные сроки. Среди руководителей даже распространено неписаное правило: умножать на 2 оценку трудоемкости, которую сделал программист. Это пессимистичный подход. Реалисты умножают на π = 3.14 . Прагматичный подход. Метод PERT Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат. Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис». Входом для данного метода оценки служит список элементарных пакетов работ. Для инженерного подхода нет необходимости точно знать закон распределения нашей оценки трудоемкости каждого такого элементарного пакета. PERT-анализ длительностей задач позволяет оценить длительность, исходя из трех величин: 1. Oi - оптимистической длительности задачи (при самых благоприятных условиях; Ни один риск не реализовался. Быстрее точно не сделаем. Вероятность такого, что мы уложимся в эти затраты, равна 0); 2. Mi - ожидаемой длительности (при обычных условиях); 3. Pi - пессимистической длительности (при самых неблагоприятных условиях: Все риски реализовались.). Для каждой работы вводятся 3 оценки длительности, а реальная длительность задачи вычисляется по формуле: Ei = (Pi + 4Mi + Oi)/6. Для расчета среднеквадратичного отклонения используется формула: CKOi = (Pi - Oi)/6. Если наши оценки трудоемкости элементарных пакетов работ статистически независимы, а не испорчены, например, необоснованным оптимизмом то, согласно центральной предельной теореме теории вероятностей суммарная трудоемкость проекта может быть рассчитана по формуле: Е = ∑ Ei А среднеквадратичное отклонение для оценки суммарной трудоемкости будет составлять: Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, можно применить формулу: E95% = E + 2 * СКО. Это значит, что вероятность того, что проект превысит данную оценку трудоемкости составляет всего 5%. А это уже вполне приемлемая оценка, под которой может расписаться профессиональный менеджер. Анализ критического пути Критический путь – это последовательность задач, определяющих дату завершения проекта. Если увеличить длительность задач, находящихся на критическом пути, то увеличится и длительность проекта в целом. Если же уменьшить длительность таких задач, то и длительность проекта также может уменьшиться (при этом критическими могут стать другие задачи). К критическим задачам также относятся задачи, имеющие ограничения: 1. фиксированное начало; 2. фиксированное окончание; 3. как можно позже (если проект планируется от даты начала); 4. как можно раньше (если проект планируется от даты конца). Для отображения критического пути следует либо воспользоваться представлением Диаграмма Ганта с отслеживанием (там он уже обозначен красным цветом), либо в представлении Диаграмма Ганта запустить мастер диаграмм Ганта (Фориат/Мастер диаграмм Ганта). На втором шаге этого мастера выбрать переключатель Критический путь и нажать кнопку Готово, а затем Форматировать. После этого отрезки критических задач будут выделены красным цветом, что изображено на рис. 9. Следующим этапом анализа является попытка уменьшить длительности критических задач при помощи следующих приемов: 1. сокращение трудозатрат, если они оказались завышенными; 2. добавление трудовых ресурсов для более быстрого выполнения задачи, если имеются подходящие свободные ресурсы; 3. разбить задачу на несколько параллельных, выполняемых различ­ными сотрудниками. Рис. 9.  Критический путь на диаграмме Ганта РЕАЛИЗАЦИЯ ПРОЕКТА Принципы количественного управления «Тем, что нельзя измерить, нельзя управлять». Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1-2 недели. Для каждого измеримого показателя должны быть определены его плановые значения. Для каждого планового значения должны быть определены три области критичности отклонений: • Допустимые отклонения. Предполагается, что никаких управляющих воздействий не требуется. • Критичные отклонения. Требуется тщательный анализ причин отклонения и при необходимости применение корректирующих действий. • Недопустимые отклонения. Требуется срочный анализ причин отклонения и обязательное применение корректирующих действий. Измерения необходимо производить регулярно. Цель — выявить причины наступивших или возможных критичных и недопустимых отклонений. Результатом анализа должны стать планирование корректирующих действий по компенсации недопустимых отклонений, их реализация и мониторинг результативности применения этих корректирующих действий. Все измерения необходимо сохранять в репозитарии проекта. Измерения, накопленные в ходе проекте, являются наиболее достоверной основой при детальной оценке и планировании работ на следующих итерациях проекта. Поскольку главная задача менеджера удержать проект в пределах «железного» треугольника, то, в первую очередь, необходимо анализировать отклонения проекта по срокам и затратам. Делается это при помощи метода освоенного объема. Приходилось сталкиваться с мнением, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки. Но если ИСР проекта, ориентирована на инкрементальную разработку, то это означает, что на верхних уровнях декомпозиции находятся компоненты проектного продукта и их функционал, а не производственные процессы. Следовательно, если в проекте реализованы, протестированы и документированы 50 % функциональных требований, то есть все основания полагать, что осталась приблизительно половина проектных работ. Суть метода оценки проекта по освоенному объему заключается в следующем. Сначала оценивается отклонение от графика SV (Shedule Variance) в денежных единицах: SV = EV - PV, где EV (Earned Value) — освоенный объем. Плановая стоимость выполненных работ. Объем выполненных работ, выраженный в терминах одобренного бюджета, выделенного на эти работы для плановой операции и элемента иерархической структуры работ; PV (Planned Value) — плановый объем. Плановая стоимость запланированных работ. Утвержденный бюджет, выделенный на плановые работы, выполняемые в рамках плановой операции или элемента иерархической структуры работ. Например. Пусть мы на текущий момент реализовали (протестировали и документировали) 20 функциональных требований, на каждое из которых было запланировано затратить по 40 чел.*час. по 1000 руб, то освоенный объем будет EV = 20 * 40 * 1000 = 800 000 руб. Если же на текущий момент планировалось реализовать только 15 требований, то плановый объем будет PV = 15 * 40 * 1000 = 600 000 руб. Следовательно, мы опережаем график (отклонение от графика положительное) на величину SV = EV - PV = 800 000- 600 000 = 200 000 руб. Как пересчитываете отклонение от графика, выраженное в денежных единицах, в сокращение сроков проекта иллюстрируется на Рисунке 43. Если мы опережаем график, то это не обязательно означает что проект идет успешно. Хорошо это или плохо зависит от значения другого показателя метода освоенного объема: CV (Cost Variance) — отклонения по затратам, которое оценивается по формуле: CV = EV - AC где AC (Actual Cost) — фактические затраты. Фактическая стоимость выполненных работ. Фактические затраты на выполнение работ за определенный период в рамках плановой операции или элемента иерархической структуры работ. Например, если мы для того что сократить время работ по проекту работали 25% времени сверхурочно и в выходные дни с двойной оплатой, то фактические трудозатраты составили: AC = 20 * (30 * 1000 + 10 * 2000) = 1 000 000 руб. Поэтому отклонения по затратам в нашем случае будет CV = EV - AC PV = 800 000 - 1 000 000 = - 200 000 руб. Отрицательное значение отклонения по затратам означает, что мы превысили бюджет, что, в общем случае, не очень хорошо. Но если срок завершения проекта для нас имеет высший приоритет, и наши прогнозируемые затраты по завершению проекта не превышают плановых с учетом управленческого резерва (Рисунок 1), то в этом случае можно считать, что проект выполняется успешно. Рисунок 1. Оценка и прогноз показателей по методу освоенного объема Отклонение от бюджета и по срокам в абсолютных денежных единицах недостаточно для характеристики проектов разных масштабов. Более наглядны относительные показатели: индекс выполнения сроков SPI (Schedule Performance Index) SPI = EV / PV и индекс выполнения стоимости CPI (Cost Performance Index) CPI = EV/ AC, которые характеризуют проект независимо от его размера. Если значения обоих индексов больше 1, то это свидетельствуют о благополучном состоянии в проекте. Какие еще измеримые показатели целесообразно применять в управлении программным проектом? В первую очередь это показатель прогресса проекта, доля реализованных и проверенных высокоуровневых требований к проекту, например отношение числа завершенных сценариев использования продукта к их общему числу. Другой показатель — стабильность проекта, общее количество принятых (утвержденных спонсором или заказчиком) изменений в плане управления проектом. Чем выше нестабильность в проекте, тем больше сложность в управлении работами и ниже производительность участников. Если кто-то думает что код это решение проблемы, то это не так. Код это новый источник проблем. Поэтому всегда следует измерять текущий размер проекта — количество строк исходного кода, добавленных, измененных и удаленных в ходе выполнения проекта разработки ПО. Чем больше объем исходного кода, тем больше времени потребуется на внесение изменений и исправление ошибок. При увеличении объема проектного продукта трудозатраты на каждую новую строку исходного кода увеличиваются. Если за номинал взять производительность проектной команды при производстве продукта в 10 KSLOC, то та же команда на проекте в 100 KSLOC покажет производительность в 1.3–1.7 раз меньшую, а на проекте в 1000 KSLOC следует ожидать, что производительность снизится в 1.6–3.0 раза. Большой объем кода так же потребует большего количества людей на его сопровождение.. Еще одна группа количественных показателей, которые следует наблюдать в ходе реализации проекта, характеризует качество программного продукта: • Дефектность продукта — количество выявленных дефектов на единицу объема продукта (например, KSLOC). • Доля не устраненных дефектов — отношение количества незакрытых максимально критичных и критичных дефектов к количеству выявленных несоответствий. • Средние затраты на сопровождение — средние трудозатраты на исправление одного дефекта. Высокое значение этого показателя может свидетельствовать о некачественной архитектуре программного продукта. • Документированность кода — определяет процент строк исходного кода с комментарии по отношению к общему количеству строк. Следует подчеркнуть, что наблюдать надо за средними по проекту значениями показателей, и ни в коем случае не пытаться измерять индивидуальные характеристики производительности и качества. Главные причины, почему это не следует делать, заключаются в том, что, во-первых, в этом случае вместо слаженной командной работы мы получим личную конкуренцию, а, во-вторых, наиболее «продвинутые» разработчики станут работать на формальные показатели, а не на достижение целей проекта. Если команда действительно состоялась, то для нее характерна коллективная ответственность за достижение общих целей. И, как пишет, Т.Демарко [3], «менеджер проекта должен занимать очередь, чтобы покритиковать сотрудника, не выполняющего свои обещания», поскольку в правильной команде для этого всегда найдется масса желающих. Выводы Для оперативного управления проектом используется рабочий план. Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист. Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1–2 недели. Для каждого измеримого показателя должны быть определены его плановые значения и допустимые отклонения. В состав измеряемых показателей должны входить следующие характеристики проекта: • Освоенный и плановый объемы работ и фактические затраты по проекту. • Показатели прогресса и стабильности проекта. • Размер продукта. • Показатели качества программного продукта. По результатам проекта обязательно должна быть реализована обратная связь. Цель — сохранить результаты, знания и опыт, полученные в проекте, для более эффективного и качественного выполнения аналогичных проектов в будущем. Мониторинг проекта в Microsoft Project На практике, едва приступив к выполнению согласованного плана, менеджер под влиянием самых разных обстоятельств столкнётся с тем, что выполнить его в точности практически невозможно. Вот почему мониторинг проекта и систематическое уточнение сетевого плана с учётом текущей ситуации является неотъемлемой составляющей частью технологии PERT. Но вводить информацию о состоянии тысяч работ ежедневно, а тем более несколько раз в день, — процесс неоправданно трудоёмкий. В связи с этим в большинстве программ для управления проектами принят подход, состоящий в том, что менеджер вводит лишь наиболее существенные отклонения от сетевого плана — те, которые затрагивают критические работы или, как предполагается, могут изменить критический путь. Об остальных работах делается предположение, что они выполняются без существенных отклонений от графика. Реализуется этот подход следующим образом. Вначале менеджер предлагает программе пометить в качестве выполненных все работы, которые должны завершиться к текущему моменту времени, и установить соответствующий процент завершённости для выполняющихся. Затем он вручную вводит поправки к изменениям, внесённым программой, основываясь на поступающих сведениях о фактическом выполнении работ. Эти две операции относятся к мониторингу выполнения проекта. Наконец, менеджер уточняет расписание предстоящих работ и назначение ресурсов с учётом произошедших отклонений от согласованного плана — осуществляет оперативное планирование на основе данных мониторинга. Виды планов проекта Основной задачей отслеживания является контроль над фактическим ходом выполнения ранее запланированных работ. Для реализации такого контроля необходимы данные двух видов: 1. утвержденный график работ, 2. фактический график работ. Эти графики могут не совпадать, что свидетельствует об отклонении фактической реализации проекта от плана. Для отслеживания предусмотрены базовый и фактический планы, взаимодействие которых изображено на рис. 1. Текущий план – это результаты текущей работы по составлению плана проекта. До сих пор при планировании мы сталкивались именно с текущим планом. Именно он отображается во всех представлениях (Диаграмма Ганта, Сетевой график и т.д.). Текущий план подвергается всевозможным изменениям и корректировкам с целью создания такого плана, который является приемлемым по длительности, стоимости и загрузке ресурсов. Рис. 1.  Взаимодействие базового и фактического планов После создания такого плана он утверждается руководителем организации и сохраняется как базовый план. Базовый план – это руководство к действию. Все работы должны выполняться в строгом соответствии с предписываемым им графиком. Система позволяет одновременно хранить несколько вариантов базового плана. Каждый вариант – это точная копия сохраненного текущего плана, в том числе даты начала и окончания работ, стоимости работ, объемы трудозатрат и т.д. Фактический план – это данные о фактически выполненной работе, которые регулярно вводятся менеджером на основе информации, поступающей с рабочих мест. В соответствии с этими данными изменяется текущий план проекта: та часть работ (или работы) текущего плана, которая уже выполнена, приводится в полное соответствие с фактическими данными, а оставшаяся (еще не выполненная) часть работ (или работы) перепланируется системой. Таким образом, фактический план – это часть текущего, но только та часть, которая уже выполнена. Благодаря такому подходу текущий план содержит два вида данных: 1. данные о фактически выполненной части работ, полностью соответствующие фактическому плану; 2. план невыполненной части работ, измененный вследствие отклонений фактического плана от базового. Взаимодействие трех видов планов изображено на рис. 1. Стрелки между блоками означают: 1. базовый план создается как копия текущего; 2. фактический план изменяет текущий, фиксируя параметры уже выполненных задач и приводя к перепланированию оставшихся; 3. фактический и базовый планы сравниваются между собой с целью анализа хода реализации проекта. Помимо перечисленных планов проекта в системе используется еще промежуточный план. Промежуточный план – это набор значений дат начала и окончания задач, который может быть использован для целей анализа или временного хранения данных. Показатели промежуточного плана хранятся в вычисляемых полях Начло1 .. Начало10 и Окночание1 .. Окончание10.