Дипломный руководитель Леохин Ю. Л. Москва 2007 г. Содержание 2 анализ методологий 4 - umotnas.ru o_O
Дипломный руководитель Леохин Ю. Л. Москва 2007 г. Содержание 2 анализ методологий 4 - umotnas.ru o_O
|
страница 1
|
|||||||||||||||||||||||||||||||||||||||||||
|
Похожие работы
|
Дипломный руководитель Леохин Ю. Л. Москва 2007 г. Содержание 2 анализ методологий - страница №1/1
.Московский Институт Электроники и Математики (Технический университет) Отчёт по преддипломной практике Выполнил: студент группы С-115 Черезов О.В. Проверил: дипломный руководитель Леохин Ю.Л. Москва 2007 г. СодержаниеСодержание 2 Введение 3 Анализ методологий 4 Классификация методологий, моделей и стандартов управления разработкой ПО 4 Анализ методологий разработки ПО 10 Rational Unified Process 10 MOF/MSF 11 Extreme Programming 11 ICONIX 12 Crystal 12 Adaptive Software Development 12 Dynamic System Development Method 13 Заключение 15 Список использованных источников 16 ВведениеВыбор адекватных проектных методологий, моделей ЖЦПО, метрик проектирования и других инструментальных средств управления ПО представляет собой достаточно сложную задачу для компаний-разработчиков ПО и проектных команд. На практике они не всегда представляют себе все существующие варианты выбора методов, моделей, стандартов и методологий, рассматривают их ограниченный набор, подходят к решению проблемы выбора без учета специфики компании и проекта. Для изучения упомянутых ключевых элементов в ЖЦПО, в течение восьми недель была пройдена преддипломная практика на кафедре ЭВА Московского института электроники и математики. Анализ методологийКлассификация методологий, моделей и стандартов управления разработкой ПОЗачем нужны методологии? Подходы к выбору методологий, моделей и стандартов зависят от предполагаемой цели использования. Чаще всего они используются следующим образом:
Выбор методологий. Менеджмент и участники проектных команд должны сформировать единое понимание в отношении целей и методов управления ИТ-проктами. Решение проблемы выбора требует двух типов компетенций:
Классификации. Полезным инструментом для решения задачи выбора является классификация. Для создания классификации методов, моделей и стандартов определены различные признаки группировки и выделены группы по этим признакам. По характеру обоснования рекомендаций: концептуальные и эмпирические. Концептуальные модели получены рационально-логическим методом, а эмпирические – чувственно-опытным. В основе концептуальных инструментальных средств лежат концепции теории менеджмента, такие как процессное управление и ре-инжиниринг бизнес-процессов, управление проектами, управление качеством. Универсальные концепции адаптируются к особенностям управления разработкой ПО, которую отличают проектный характер деятельности, технологическая гибкость процесса разработки, неопределенность требований в отношении ожидаемого результата и высокие риски. Примером концептуальной модели является модель зрелости технологических процессов SEI (Capability Maturity Model, CMM). Концептуальной является методология PRINCE и рациональный унифицированный процесс (Rational Unified Process, RUP). Эмпирические методологии разработаны на основе теоретического обобщения успешных практик ИТ-проектов. Примерами эмпирической модели служат SCRUM, XP, Crystal. В зависимости от назначения: модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики. Модель зрелости CMMI, модель оценки процессов SPICE и стандарт ISO 9000 используются для управления ИТ-компанией (подразделением). Проектные методологии: MSF, SCRUM, XP, используются для управления ИТ-проектами разработки ПО. Методологии внедрения информационных систем используются для организации проекта внедрения. Командные и индивидуальные практики (PSP, Personal Software process; TSP, Team Software process) служат для непрерывного повышения эффективности работы команд и индивидуальных разработчиков. В зависимости от условий реализации проекта: прогнозируемые и адаптивные. Прогнозируемые методологии основываются на предпосылке о возможности и целесообразности детального планирования будущего. Для ИТ-проекта формулируются требования к разрабатываемой системе, формируется план проекта и определяется потребность в ресурсах. Изменения в плане проекта и требованиях считаются нежелательными. Проектные методологии этого класса используют каскадную модель жизненного цикла. Адаптивные методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. В основе адаптивных методологий лежит итерационная модель жизненного цикла. Примером адаптивных методологий являются Scrum, Crystal, Extreme Programming. Адаптивные методологии учитывают психологические особенности процесса разработки ПО. Одним из значимых факторов успеха использования адаптивных методологий является высокая квалификация специалистов, в первую очередь – разработчиков. По характеру знаний и фокусу: инженерные, управленческие и интегрированные. Инженерные инструменты (software engineering) основываются на технологических принципах и направлены на совершенствование конечных продуктов, таких как программный код, тестовые примеры, прототипы, документация. Инженерные инструментальные необходимы квалифицированному разработчику. Управленческие инструментальные средства (software project management and process management) основываются на принципах теории управления (менеджмента), в их основе лежат такие концепции, как тотальное управление качеством, управление проектами, управление знаниями. Интегрированные инструментальные средства объединяют инженерные концепции и концепции управления. Проектные методологии находятся в центре теории управления разработкой ПО, поэтому для них можно предложить расширенный набор групп на основе различных характеристик проекта. В зависимости от проектных рисков (предложено А. Коберном). В зависимости от характера потерь в случае неудовлетворительной работы ПО выделяются проекты с различными видами рисков:
В зависимости от технологии проекта (для проектных методологий): универсальные, структурные, объектные и метрологии для сервисно-ориентированной архитектуры (SOA). На Рис. 1. представлена предлагаемая нами классификация инструментальных средств управления разработкой ПО. В центр классификации помещены две группы методологий: методологии управления разработкой ПО и методологии внедрения информационных систем (ИС). Методологии содержат рекомендации по использованию отдельных инструментов: метрик, технических стандартов, языков графического моделирования. Методологии включают в себя: описание рекомендуемой модели жизненного цикла разработки (внедрения) ПО, модель команды проекта и ролей, а также используемых методик, техник. В зависимости от лежащей в основе методологии управления проектом разработки ПО модели жизненного цикла, проектные методологии варьируют от классической каскадной до итеративных методологий. Методологий внедрения информационных систем представляют собой набор методологий, разработанных специально для внедрения той или иной информационной системы. В некоторых случая для одной системы может существовать несколько альтернативных методологий внедрения. Методологии управления ИТ-проектами формируются на основе теории управления проектами. Модели управления ИТ-компаниями опираются на концепции тотального управления качеством и процессного управления. В левой части классификации представлены универсальные концепции менеджмента: всеобщее управление качеством (TQM), процессное управление и реинженеринг безнес-процессов (BPR) и управление проектами (PM), а также различные вычислительные техники. Самостоятельную группу образуют управленческие стандарты, среди которых наиболее известен стандарт ISO 9000. Универсальные концепции менеджмента аккумулируют опыт и лучшие управленческие практики, которые стали основой методологий совершенствования деятельности компаний- разработчиков, таких как модели зрелости (CMM/CMMI), стандарты оценки и улучшения процессов (SPICE), и TickIT. Эти модели и стандарты регламентируют организационно- управленческую и технологическую среду, в условиях которой применяются проектные методологии. Самостоятельный кластер представляют собой индивидуальные техники, среди которых выделяется собственный процесс разработки (PSP). В основе индивидуальных техник также лежат концепции управления. Вычислительные техники представляют собой алгоритмы оценки, анализа и оптимизации, используемые в управлении компанией и отдельными проектами. В правой части представлены метрики и языки моделирования. Метрики служат для получения фактических и плановых количественных оценок для процессов, проектов и продуктов. Использование метрик является косвенным признаком применения концепций управления качеством в разработке ПО и зрелости организации процессов разработки. Языки графического моделирования используются для создания понятных и согласованных требований и проектных решений. Универсальный язык моделирования (UML) позволяет однозначно транслировать графические нотации в проектный код, а также порождать графические описания на основе программного кода. Развитие графических нотаций, как составной части автоматизированного проектирования, оказывает влияние на проектные методологии. В управлении проектами разработки ПО существует набор стандартных (типовых) задач, которые могут решаться одинаково, вне зависимости от технических и организационных особенностей проекта и выбранной для него методологии. Для решения этих задач предназначены методики. Методика служат для решения одной задачи и включают в себя описание области применения, алгоритмы использования, описание необходимых исходных данных. Методики могут предусматривать использование определенных метрик, языков моделирования и стандартов. Методики содержат полные рекомендации по решению отдельных проектных задач, таких как управление рисками, или оценка трудоемкости проекта. Примерами методик служат SEI Risk Evaluation Method или COCOMO. В нижней части классификации представлены группы стандартов, регламентирующих различные аспекты разработки ПО. Стандарты разрабатываются международными и государственными организациями по стандартизации, отраслевыми комитетами, исследовательскими институтами, крупными компаниями, такие как ISO (International Organization for Standardization), SEI (Software Engineering Institute), DoD (Department of Defense USA), IEEE (Институт Электронной и Электротехнической Инженерии, Institute of Electrical and Electronics Engineers), МЭК (Международная Электротехническая комиссия), а так ИТ-компании: Bell, Hewlett Packard, Sun Microsystems, IBA, Oracle, Microsoft и др. Стандарты, регламентирующие требования к процессам разработки и выходным продуктам, дополняют методологии управления разработкой ПО.
Модели и стандарты, регламентирующие процессы и жизненный цикл, лежат в основе системы менеджмента качества компании, используются при разработке проектных планов. Рисунок 1. Классификация методологий, моделей и стандартов управления разработкой ПО Методологии. В результате анализ методологий управления разработкой ПО были выявлены две группы методологий, которые отличаются целью их использования, историей создания и назначением. Первая группа представляет собой методологии, целью которых является успешное выполнение отдельного проекта. К этой группе относится большинство проектных методологий, и практически все адаптивные методологии. Логика успешного функционирования организации выглядит как рост компетенций, создание технических активов за счет последовательного выполнения успешных проектов. Вторая группа включает в себя методологии, обеспечивающие устойчивое функционирование компании-разработчика ПО, нацелены на последовательное развитие компетенций. К этой группе относятся модели зрелости (CMM, CMMI). Логика успешного функционирования предполагает создание, контроль и непрерывное улучшение способностей организации к выполнению проектов, и, как следствие, успешное выполнение проектов. Две выделенные группы отличаются не только целью использования, но и историей создания и развития, а также практикой использования. Проектные методологии представляют собой ядро теории управления разработкой ПО. К существующей классификации в зависимости от используемой в ней модели жизненного цикла (водопадные (каскадные) и итерационные методологии) добавилась более общая классификация на прогнозируемы и адаптивные методологии. К адаптивным относятся все методологии, которые удовлетворяют требованиям, сформулированным в Манифесте адаптивной разработки. Прогнозируемые (предикативные) методологии фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Часто создается специальный комитет по «управлению изменениями» (change control board) чтобы в проекте учитывались только самые важные требования (ГОСТ 19, 32). Адаптивные методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать будущее проекта. Существует точный план лишь на ближайшее время. Более удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах. Среди адаптивных методологий: (Scrum, Crystal, Extreme Programming, Adaptive Software Development, DSDM, Feature Driven Development, Lean software development). Предлагаемая классификация структурирует дальнейшую работу по определению подходов к выбору методов моделей и стандартов в следующих направлениях:
Анализ методологий разработки ПОЗавершать хороший проект приятно. Особенно если проект не просто хороший, а еще и успешный. А вот если задание не выполнено или выполнено не полностью, то чувства могут быть совсем другие. Каким должен быть проект? Как достичь поставленной цели? Как сделать это наиболее эффективно в существующих условиях? Если речь идет о разработке информационных систем, то ответ на многие подобные вопросы, возникающие на протяжении всей длительности проекта дает методология разработки ПО. Если с самого начала точно и корректно определить ключевые задачи и предъявляемые требования, то правильно выбранная методология, положенная в основу проекта, станет надежным базисом, компасом, ведущим к его успешному завершению. Однако задачи настолько разнообразны, а требования порой настолько непредсказуемы, что осознанный выбор методологии и способа её реализации представляется крайне нетривиальной задачей. Именно наличие такого большого количества привходящих факторов и их комбинаций послужило толчком к рождению нескольких десятков методологий и их вариаций. В подобных условиях оптимальный выбор методологии с первого взгляда кажется если не случайностью, то по крайней мере, большой удачей. И как, к сожалению, порой бывает в России, многие предприятия и проекты проводятся по методу «Code and fix». А от себя бы добавил, что скорее по методу «Соde and fix... or not fix». Однако такой выбор вполне возможен. Из всех методологий разработки программного обеспечения рассмотрим самые распространенные и интересные на сегодняшний день: RUP, MOF/MSF, XP, Iconix, Crystal, ASD, Scrum, FDD, DSDM, dX. Rational Unified ProcessПервая из них - Rational Unified Process (RUP), разработана и поддерживается компанией Rational Software, с 2002-ого годя являющейся подразделением IBM. RUP обеспечивает строгий подход к распределению задач и ответственности внутри организации-разработчика и одновременно адаптивный подход Он акцентирует внимание на создании точно в срок и в рамках установленного бюджета качественного ПО, отвечающего нуждам конечных пользователей. RUP предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. RUP гарантирует, согласованность работы внутри команды разработчиков. Принципиальное отличие RUP от многих других итеративных подходов состоит в большом внимании к разработке архитектуры системы. Архитектура в RUP — это еще и ключевая часть кода (обычно, до 20% общего объема), которая которая выполняет основные тривиальные функциональные и нефункциональные требования. Поэтому в RUP часто говорится об исполняемой архитектуре (executable architecture). Дух RUP заключен в восьми принципах: • атаковать риски как можно раньше, пока они сами не перешли в атаку; • разрабатывать именно то, что нужно заказчику; • главное внимание - исполняемой программе; • приспосабливаться к изменениям с самого начала проекта; • создавать архитектурный каркас как можно раньше; • разрабатывать систему из компонентов; • работать как одна команда; • сделать качество стилем жизни. Особенностью RUP является то, что в результате работы над проектом создаются и совершенствуются модели. RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. MOF/MSFМетодология от компании Microsoft – MOF/MSF - состоит из двух «структур» Microsoft Operations Framework (MOF) и Microsoft Solutions Framework (MSF). MOF состоит из технических руководств, помогающих компаниям достигать требуемых от информационной системы уровней надежности, доступности, простоты в технической поддержке и управляемости при построении решений на базе продуктов Microsoft. Рекомендации MOF касаются вопросов персонала, процессов, технологий и стратегии управления в сложных, распределенных, гетерогенных IT-средах. Вторая структура, MSF, предлагает гибкий и масштабируемый путь к удовлетворению нужд организации или проектной группы любого размера. MSF включает в себя принципы, модели и знания для управления людьми, процессами, технологическими элементами, а также о том, как эти ресурсы могут взаимно дополнять друг друга в рамках типичных проектов. Модель жизненного цикла IT-решений, применяемая в Microsoft, комбинирует отдельные операции, осуществляемые IT-подразделением компании, таким образом, чтобы оказываемые им услуги были бесперебойными, а издержки — минимальными. MOF и MSF нацелены на различные, но связанные между собой фазы жизненного цикла IT-решений. А вот во многом в противовес архаичному мнению о тяжеловесности и неповоротливости приведенных технологий, группа идеологов течения, которое со временем получила название «Agile Alliance» разработала ряд основных принципов: тесная коммуникация, постоянное тестирование, минимум документации и максимум гибкости. Впрочем, лучше привести текст манифеста: «Мы открываем лучшие способы разработки ПО, создавая его сами и помогая другим. Благодаря этой работе мы стали ценить: • индивидуумов и взаимодействия выше процессов и инструментов; • работающее ПО выше всеобъемлющей документации; • сотрудничество с заказчиками выше согласований условий договора; • реагирование на изменения выше соблюдения плана. Это означает, что, хотя элементы в правой части также имеют свою ценность, но больше мы ценим элементы, расположенные слева». Extreme ProgrammingНаибольшее распространение среди таких течений получила методология Extreme Programming (XP). Двенадцать основных практик которой (по первому изданию книги Extreme programming explained), со свойственной этому течению лаконичностью, могут быть объединены в четыре группы:
ICONIXОдна из методологий, по своему духу находящаяся где-то между RUP и XP, носит название ICONIX. Она, как и RUP, базируется на UML, однако создатели сознательно использует только 20% типов UML диаграмм и в этом его основное отличие. Процесс ICONIX компактнее, легче в изучении и больше подходит для небольших проектов. ICONIX также как и RUP основан на прецедентах, является итеративным и инкрементным, но фокусирует свое внимание на фазе анализа и дизайна. Его основная задача найти ответ на вопрос: каким образом максимально быстро добраться от прецедентов к работающей системе используя минимум промежуточных шагов. CrystalCrystal - это не просто методология, это уже целое семейство методологий. Главные принципы:
Важной особенностью Crystal является непрерывная корректировка, настройка методологии. А точнее переход от одной вариации к другой. По одной оси отмерено размер требуемой команды разработчиков, по другой откладывается критичность потенциального сбоя разрабатываемой системы. Таким образом получается таблица применяемых методологий, определяющих минимально необходимое число разрабатываемых элементов и используемых технологий. Но и это еще не все. Настройка каждой из методологий производится в соответствии с дополнительными целями проекта в: требуемой скоростью реализации, четкости документирования, ценой. Перед каждой итерацией производится корректировка. Adaptive Software DevelopmentМетодология ASD (Adaptive Software Development). Здесь обычный жизненный цикл проекта заменен на более динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие – Обучение). Каждый шаг подразумевает выполнение сложного комплекса действий. Этот цикл ставит своей целью непрерывное обучение. Он связан с постоянными изменениями, повторными оценками, попытками предугадать неизвестное на текущий момент будущее проекта и требует тесного взаимодействия между разработчиками, тестировщиками и заказчиками. Весь этот цикл не всегда представляет собой правильный круг. Даже при итеративном процессе можно иногда отклоняться в сторону, чтобы изучить неисследованные до сих пор области). Методология ASD построена на концептуальной базе теории сложных адаптивных систем. Она рассчитана на использование в экстремальных проектах, в которых превалируют быстрый темп разработок, непредсказуемость и частые изменения. Есть проекты, которые не могут считаться экстремальными, однако для всех остальных ASD подходит гораздо лучше, чем любой традиционный подход к разработке ПО. В конце этой статьи вы найдете ссылки на более подробное изложение теории адаптивных систем.) FDD насчитывает пять процессов. Первые три из них относятся к началу проекта. • Разработка общей модели; • Составление списка требуемых свойств системы; • Планирование работы над каждым свойством; • Проектирование каждого свойства; • Конструирование каждого свойства. При этом каждый процесс разбивается на задачи и имеет критерии верификации. Все разработчики делятся на два вида: "class owners" (владельцы классов) и "chief programmers" (старшие программисты). Старшие программисты - это наиболее опытные разработчики. Именно им поручается разработка конкретных свойств системы. Однако они не занимаются этим самостоятельно: старший программист определяет, какие классы заняты в реализации данного конкретного свойства, после чего собирает команду из владельцев необходимых классов, которая и будет заниматься разработкой. Сам он действует как координатор, главный проектировщик и руководитель, а на долю владельцев классов остается, по большей части, непосредственное кодирование. Dynamic System Development MethodИ наконец, Dynamic System Development Method (DSDM). Первая стадия – серия коротких семинаров, где программисты узнают о той сфере бизнеса, для которой им предстоит работать. Здесь же обсуждаются основные положения, касающиеся архитектуры будущей системы и план проекта. Далее процесс делится на три взаимосвязанных цикла: цикл функциональной модели отвечает за создание аналитической документации и прототипов, цикл проектирования и конструирования - за приведение системы в рабочее состояние, и наконец, последний цикл - цикл реализации - обеспечивает развертывание программной системы. Базовые принципы, на которых строится DSDM, это активное взаимодействие с пользователями, частые выпуски версий, самостоятельность разработчиков в принятии решений и тестирование в течение всего цикла работ. Как и большинство других гибких методологий, DSDM использует короткие итерации, продолжительностью от двух до шести недель каждая. Особый упор делается на высоком качестве работы и адаптируемости к изменениям в требованиях. ЗаключениеАдекватный выбор проектных методологий, моделей ЖЦПО, метрик проектирования и других инструментальных средств управления ПО является комплексной задачей, требующей продолжения исследований в данной области, накопления и систематизации опыта. По результатам работы были выделены следующие ключевые критерии:
Список использованных источников
|
|
|