обеспечивается эффективное выполнение остальных практик.
Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при смене партнёров в парах возникает больше затруднений; в общем и целом, продвижение проекта затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, - вся команда работает унифицировано, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Не нужно тратить слишком много времени на предварительную разработку стандарта.
Коллективное владение.
Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом - в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Право каждого программиста изменять код ведёт к риску появления ошибок, вносимых программистами, которые считают, что знают, что делают, но не рассматривают некоторые зависимости. Хорошо определённые юнит-тесты решают эту проблему: если нерассмотренные зависимости порождают ошибки, то следующий запуск юнит-тестов будет неудачным.
Microsoft Solutions Framework (MSF) - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.представляет собой согласованный набор концепций, моделей и правил.
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.
Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.
В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться.
Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:
· управление программой (program manager) - разработку архитектуры решения, административные службы;
· разработку (developer) - разработку приложений и инфраструктуры, технологические консультации;
· тестирование (QAE) - планирование, разработку тестов и отчетность по тестам;
· управление выпуском (release manager) - инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
· удовлетворение заказчика (user experience) - обучение, эргономику, графический дизайн, техническую поддержку;
· управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.
Наличие шести ролевых кластеров не означает, что количество членов команды должно быть кратным шести - один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.
В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:
· Роль команды разработчиков не может быть объединена ни с какой другой ролью.
· Избежание сочетания ролей, имеющих предопределенные конфликты интересов.
Как и в любой другой командной деятельности, подходящая комбинация ролей зависит от самих членов команды, их опыта и профессиональных навыков. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:
· ответственность за управление проектом распределенная между лидерами ролевых кластеров внутри команды - каждый член проектной группы отвечает за общий успех проекта и качество создаваемого продукта.
· профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней - в эффективно работающей команде каждый её член имеет необходимые полномочия для выполнения своих обязанностей и уверен, что получит от коллег все необходимое.
Как следует из вышесказанного, одна из характерных особенностей MSF - отсутствие должности менеджера проекта!
Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.
Использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.
Модель проектной группы MSF не обеспечивает успех сама по себе. Есть много других факторов, определяющих успех или неудачу проекта, но структура проектной группы, безусловно, вносит существенный вклад.
Подходящая структура команды является фундаментом успеха, и реализация модели MSF с использованием лежащих в её основе принципов поможет сделать проектные группы более эффективными и, как следствие, более успешными.
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена ещё одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.
Процесс MSF ориентирован на «вехи» (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?», «В достаточной ли степени готов план действий?», «Соответствует ли продукт утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т.д.
Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду.
Модель процессов MSF тесно связана с базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:
подход, основанный на фазах и вехах
итеративный подход
интегрированный подход к созданию и внедрению решений
Модель процессов включает такие основные фазы процесса разработки:
выработка концепции (Envisioning)
разработка (Developing)
стабилизация (Stabilizing)
внедрение (Deploying)
В рамках MSF программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для одного решения ряда версий. С созданием новых версий эволюционирует функциональность решения.
Следует отметить, что MSF не навязывает использование других продуктов Microsoft. Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Borland, хотя будущая версия MSF 4.0 будет жестко привязана к Microsoft Team System - новому инструментальному средству Майкрософт для поддержки командной работы над проектами.
Первая версия MSF появилась в 1994 году. Текущая версия - MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.
Кроме этого, появилась роль архитектора и поддержка методологии в инструменте - Visual Studio Team System.
Технология (или процесс) ICONIX, которую мы будем подробно рассматривать, представляет собой нечто среднее между компактными и большими процессами. Технология ICONIX, как и RUP, основана на прецедентах (вариантах использования). В этом процессе тоже применяется язык моделирования UML (Unified Modeling Language), однако основное внимание уделяется анализу требований.был разработан Дугом Розенбергом в компании ICONIX SoftWare Engineering. Хотя название процесса пишется прописными буквами, оно не является аббревиатурой.
В то время, когда UML разрабатывался тремя программистами-инженерами из Rational SoftWare, которые пропагандировали ОО методы разработки ПО, Дуг Розенберг создавал средство объектного моделирования Object Modeler. В 1992 году он разработал собственный процесс и назвал его ICONIX, взяв все лучшее из оригинальных методик Буча, Рамбо и Якобсена.использует только 20% диаграмм UML и больше подходит для небольших проектов по сравнению с RUP. Сложный процесс разработки ПО упрощается до использования минимума шагов, ведущих к создания ПО.
В отличие от довольно сложного RUP ICONIX не требует привлечения консультантов, которые бы преобразовали этот процесс для конкретной компании. ICONIX компактнее, легче в изучении. RUP полностью показывает весь ЖЦ разработки ПО, ICONIX же фокусирует свое внимание на фазе анализа.
В настоящее время в процессе RUP на фазе анализа и дизайна применяется ICONIX, которая является подключаемым модулем от Rational SoftWare.как и RUP основан на прецедентах, является итеративным и инкрементным. Его основная задача - найти ответ на вопрос: как максимально быстро добраться от прецедентов к работающей системе, используя минимум промежуточных шагов.
Основные этапы процесса следующие:
• анализ требований
• предварительное проектирование
• детальное проектирование
• реализация
Процесс основан на построении минимального количества моделей, которые отражают будущую систему. Это динамические и статические модели.
На этапе анализа:
. Проводится архитектурный анализ программного обеспечения
. Создаются модели прецедентов
. Создается модель пользовательского интерфейса
На этапе предварительного проектирования:
1. Дополняется и уточняется модель прецедентов
2. Создаются классы уровня предварительного проектирования, участвующие в вариантах использования
. Создаются предварительные диаграммы классов для каждого варианта использования
. Осуществляется распределение классов по пакетам
. Дополняется Модель предметной области
На этапе детального проектирования:
. Проектируется архитектура системы
. Создаются диаграммы последовательности
. Уточняются классы уровня детального проектирования и уточняются диаграммы классов
. Создается общая диаграмма классов и диаграммы классов по пакетам
. Создается модель данных с атрибутами и связями (ER-диаграмма)
. Создается диаграмма состояний
На этапе реализации:
. Создаются диаграмма компонентов, если это необходимо
. Создается физическая база данных
. Создаются исходный код
Каждый этап завершается рецензирование, когда созданные диаграммы
обсуждаются с коллегами.
Для проектирования ИС была выбрана технология ICONIX, т.к.:
- она подходит для относительно не больших проектов
- основной упор делает на анализе и проектирование ПО
- может использоваться небольшой группой разработчиков
- обеспечивает высокое качество разрабатываемого проекта ИС
При проектировании ИС используется объектно-ориентированный подход CASE - средство Rational Rose, язык визуального объектно-ориентированного моделирования UML.
Основной функцией Rational Rose является построение различного рода диаграмм и спецификаций UML, которые определяют архитектуру системы, а также ее статические и динамические аспекты. Rational Rose средство визуального моделирования с использованием языка UML. Это язык <#"787486.files/image001.gif">
Рисунок
1 - диаграмма вариантов использования
В
ходе детального изучения обязанностей сотрудников фирмы ДВИ была переработана и
представлена в Рисунок 2 - диаграмма вариантов использования.