Студент группы с-115 Черезов О. В icon

Студент группы с-115 Черезов О. В



НазваниеСтудент группы с-115 Черезов О. В
Черезов О.В
Дата конвертации06.02.2013
Размер188.48 Kb.
ТипОтчет
скачать >>>

.Московский Институт Электроники и Математики

(Технический университет)


Отчёт

по преддипломной практике


Выполнил:

студент группы С-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), со свойственной этому течению лаконичностью, могут быть объединены в четыре группы:

  • Короткий цикл обратной связи

  • Разработка через тестирование

  • Игра в планирование

  • Заказчик всегда рядом

  • Парное программирование

  • Непрерывный, а не пакетный процесс

  • Непрерывная интеграция

  • Рефакторинг

  • Частые небольшие релизы

  • Понимание, разделяемое всеми

  • Простота

  • Метафора системы

  • Коллективное владение кодом

  • Единый стандарт кодирования

  • 40-часовая рабочая неделя

ICONIX


Одна из методологий, по своему духу находящаяся где-то между RUP и XP, носит название ICONIX. Она, как и RUP, базируется на UML, однако создатели сознательно использует только 20% типов UML диаграмм и в этом его основное отличие. Процесс ICONIX компактнее, легче в изучении и больше подходит для небольших проектов.

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

Crystal


Crystal - это не просто методология, это уже целое семейство методологий. Главные принципы:

  • Вся команда в одном помещении. Это позволяет сократить временные затраты на коммуникацию.

  • Частые поставки продукта позволяют выработать "ритм" проекта. Ничто так не вдохновляет команду, как поставленный вовремя продукт.

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

  • Средства контроля версий кода обеспечивают коллективное владение кодом.

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

Adaptive Software Development


Методология ASD (Adaptive Software Development). Здесь обычный жизненный цикл проекта заменен на более динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие – Обучение). Каждый шаг подразумевает выполнение сложного комплекса действий.

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

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

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

^ Feature Driven Development (FDD). Как и остальные адаптивные методологии, она делает основной упор на коротких итерациях, каждая из которых служит для проработки определенной части функциональности системы. Согласно FDD, одна итерация длится две недели.

FDD насчитывает пять процессов. Первые три из них относятся к началу проекта.

• Разработка общей модели;

• Составление списка требуемых свойств системы;

• Планирование работы над каждым свойством;

• Проектирование каждого свойства;

• Конструирование каждого свойства.

При этом каждый процесс разбивается на задачи и имеет критерии верификации.

Все разработчики делятся на два вида: "class owners" (владельцы классов) и "chief programmers" (старшие программисты). Старшие программисты - это наиболее опытные разработчики. Именно им поручается разработка конкретных свойств системы. Однако они не занимаются этим самостоятельно: старший программист определяет, какие классы заняты в реализации данного конкретного свойства, после чего собирает команду из владельцев необходимых классов, которая и будет заниматься разработкой. Сам он действует как координатор, главный проектировщик и руководитель, а на долю владельцев классов остается, по большей части, непосредственное кодирование.
^

Dynamic System Development Method


И наконец, Dynamic System Development Method (DSDM). Первая стадия – серия коротких семинаров, где программисты узнают о той сфере бизнеса, для которой им предстоит работать. Здесь же обсуждаются основные положения, касающиеся архитектуры будущей системы и план проекта.

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

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


Заключение


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

По результатам работы были выделены следующие ключевые критерии:

  • Важность проекта;

  • Требуемая длительность цикла обратной связи с заказчиком;

  • Численность проектной команды;

  • Стиль управления;

  • Готовность команды работать в задаваемом методологией ритме.


^

Список использованных источников


  1. http://www.koltunova.com/Publications/ITMethodologyClassification.pdf

  2. http://www.interface.ru/rational/rup01_t.htm

  3. https://msdb.ru/Downloads/Msdn/Msf/MSF_team_model_rus.doc

  4. http://ru.wikipedia.org/wiki/Экстремальное_программирование

  5. http://www.caseclub.ru/articles/iconix.html

  6. http://nrd.pnpi.spb.ru/UseSoft/Journals/Soft&Script/ssm066/wa-scrum.html

  7. http://www.maxkir.com/sd/RLCD_highsmith.html

  8. http://www.silicontaiga.ru/home.asp?artId=4889





Похожие:

Студент группы с-115 Черезов О. В iconСтудент группы с-115 Черезов О. В

Студент группы с-115 Черезов О. В iconПрограмма для вычислительной машины. Выполнила студентка группы 04-115 Малкова Екатерина Сергеевна Москва
Алгоритм формальное описание последовательности действий, которое необходимо выполнить для решения задачи
Студент группы с-115 Черезов О. В iconГотфрид Вильгельм Лейбниц Выполнил студент группы 2У00

Студент группы с-115 Черезов О. В iconОтчет по лабораторной работе №1 Соболевский А. А. (студент группы с-85) Москва 2007

Студент группы с-115 Черезов О. В iconСоглашение на использование лицензионного программного обеспечения
Я, ­­, студент группы № фен нгу
Студент группы с-115 Черезов О. В iconСовмещение анимации и реального видео в среде Macromedia Flash mx студент группы с-54 Неумолотов А. С

Студент группы с-115 Черезов О. В iconКурсовая работа особенности организации маркетинга в кризисный период студент группы 3620

Студент группы с-115 Черезов О. В iconЛабораторная работа по дисциплине: «теория кодирования» Векторный код с коррекцией студент группы с-65

Студент группы с-115 Черезов О. В iconЛабораторная работа по дисциплине: «теория кодирования» Код Хэмминга с d min студент группы с-65

Студент группы с-115 Черезов О. В iconКонтрольные вопросы по курсу «Операционные системы» студент группы с-44 Бизюк С. И. Проверил: Истратов А. Ю

Разместите кнопку на своём сайте:
Документы


База данных защищена авторским правом ©rushkolnik.ru 2000-2015
При копировании материала обязательно указание активной ссылки открытой для индексации.
обратиться к администрации
Документы