Rational unified process (rup) как методология разработки программного обеспечения кратко

Жизненный цикл

Усилия в деятельности в соответствии с этапом проекта.

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

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

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

На начальном этапе итерации уделяют больше внимания деятельности по моделированию бизнеса и требований.

На этапе проработки итерации ориентированы на разработку базового плана архитектуры, охватывая больше рабочих процессов требований, бизнес-модели (уточнение), анализа, проектирования и части реализации, ориентированной на базовый план архитектуры.

На этапе конструирования конструирование продукта осуществляется посредством серии итераций.

Для каждой итерации выбираются несколько вариантов использования, уточняется их анализ и дизайн, проводится их реализация и тестирование. Делается небольшой водопад для каждого цикла. Итерации проводятся до тех пор, пока не будет закончено внедрение новой версии продукта.

На этапе перехода цель состоит в том, чтобы гарантировать, что продукт готов к доставке сообществу пользователей.

Как видно, все дисциплины участвуют в каждой фазе, но в зависимости от фазы усилия, затрачиваемые на дисциплину, различаются.

Why RUP — Best Practices

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

• Develop Software Iteratively
• Manage Requirements
• Use component-based architectures
• Visually model software
• Continuously verify software quality
• Control changes to software

Develop Software iteratively

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end — user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

Manage requirements

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

Use component-based architectures

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

Continuously verify software quality

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

Control changes to software

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

Комментарии к методу

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

Что касается «управления вариантами использования», это означает, что требования сосредоточены на обеспечении ценности для клиента и что процесс должен гарантировать, что вся разработка, тестирование, планирование, документация и т. д. направлены на удовлетворение этих ожиданий. эти ценностные требования внедряются в производство.

Когда речь идет об «ориентированности на архитектуру», это означает, что упор делается на проектирование качественной архитектуры, и именно архитектура определяет, как следует планировать и выполнять разработку.

Что касается «итеративного и инкрементного», то это означает, что проект делится на несколько жизненных циклов (называемых итерациями), результатом которых должен стать исполняемый файл. Для каждой из итераций добавляются требования и, прежде всего, ценность для клиента; по этой причине он является инкрементным.

3.Проектирование

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

 Для создания модели
проектирования используются целый набор UML
диаграмм: диаграммы классов (рис. 5),
диаграммы кооперации, диаграммы
взаимодействия, диаграммы активности.

 

рис 6. Пример диаграммы классов

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

What is Rational Unified Process (RUP)?

A processed product — the development team for RUP is working closely with customers, partners, groups organizations to ensure that the process is constantly updated

The RUP leverages team productivity — it allows the team to have a free access to a knowledge base with all the guidelines and tool mentors that help them overcome critical issues. This helps the entire team share the same language when developing a software

The RUP creates and maintain models — instead of producing a large amount of paperwork, this method creates models — semantically rich representations of the software system your team is developing

The RUP is a guide how to use Unified Modelling Language (UML) — UML allows your team to communicate their requirements, architecture, and design of the project.

The RUP is a configurable process — it is a simple and clear process that can fit both small development teams as well as large organizations.

Процессы и стадии RUP

RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Первые идеи итеративной модели разработки были заложены в «спиральной модели»

Полный жизненный цикл разработки продукта состоит из четырёх фаз, каждая из которых включает в себя одну или несколько итераций:

Графическое представление процесса разработки по RUP

1. Начальная стадия (Inception)

В фазе начальной стадии:

• Формируются видение и границы проекта.
• Создается экономическое обоснование (business case).
• Определяются основные требования, ограничения и ключевая функциональность продукта.
• Создается базовая версия модели прецедентов.
• Оцениваются риски.

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

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

Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).

3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

What is a Rational Unified Process (RUP)?

Rational Unified Process (RUP) is an agile software development method, in which the life cycle of a project, or the development of software, is divided into four phases. Various activities take place during these phases: modelling, analysis and design, implementation, testing and application.

The Rational Unified Process (RUP) is iterative, meaning repeating; and agile. Iterative because all of the process’s core activities repeat throughout the project. The process is agile because various components can be adjusted, and phases of the cycle can be repeated until the software meets requirements and objectives.

Do you want unlimited and ad-free access?   Find out more

The process, as visualised in the image in this article, should be looked at from two dimensions. Firstly, there is the time dimension, represented by the horizontal axis. The time dimension is expressed in terms of the phases and cycles, iterations, and milestones. The vertical axis is the process dimension. This dimension represents the static aspect of the process and is described in terms of activities, artefacts, workers, and workflow.

История

Истоки RUP восходят к оригинальной спиральной модели Барри Боэма. Кен Хартман, один из ключевых участников RUP, сотрудничал с Бёмом в исследовании. В году Rational Software купила шведскую компанию под названием Objectory AB, основанную Иваром Якобсоном, известным тем, что включал варианты использования в методы объектно-ориентированной разработки. Рациональный унифицированный процесс стал результатом слияния рационального подхода и возражения (процесс из возражения АВ). Первым результатом этого слияния стал Rational Objectory Process , первая версия RUP, выпущенная на рынок в году под руководством Филиппа Крухтена в качестве главного архитектора.

Первая книга, описывающая этот процесс, называлась «Унифицированный процесс разработки программного обеспечения »

В году IBM создала подмножество RUP, предназначенное для проектов гибкой разработки , которое было выпущено как бесплатный метод под названием OpenUP на сайте Eclipse .

More information

1. Ambler, S., Nalbone, J., & Vizdos, M. (2005). Enterprise unified process, the: extending the rational unified process. Prentice Hall Press.
2. Kroll, P., & Kruchten, P. (2003). The rational unified process made easy: a practitioner’s guide to the RUP. Addison-Wesley Professional.
3. Kruchten, P. (2004). The rational unified process: an introduction. Addison-Wesley Professional.
4. Manzoni, L. V., & Price, R. T. (2003). Identifying extensions required by RUP (rational unified process) to comply with CMM (capability maturity model) levels 2 and 3. IEEE Transactions on Software engineering, 29(2), 181-192.

How to cite this article:
Janse, B. (2019). Rational Unified Process (RUP). Retrieved from toolshero: https://www.toolshero.com/information-technology/rational-unified-process-rup/

Add a link to this page on your website:
<a href=”https://www.toolshero.com/information-technology/rational-unified-process-rup/”>toolshero: Rational Unified Process (RUP)</a>

Принципы

В основе RUP лежат следующие принципы:

• Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
• Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
• Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
• Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
• Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
• Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Артефакты и роли RUP

Неотъемлемую часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов — начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п. Ниже приведен набор артефактов (моделей, документов и т.п.) для каждого из потоков.

Business modeling

Артефакты-модели — используется Rational Rose:

• модель бизнес-процессов — определение бизнес-требований к разрабатываемой системе;
• модель структуры предприятия — артефакт для разработки функциональной модели системы;
• модели документов, бизнес-сущностей, модели сценариев бизнес-функций, модели состояний бизнес-сущностей — для проектирования пользовательского интерфейса, БД системы; представляют собой описание статического и динамического состояний системы с различных точек зрения;
• модели бизнес-правил — артефакт используется для моделирования правил в ПО.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, Microsoft Project:

• оценка организации заказчика, структура бизнеса;
• словарь терминов предметной области;
• набор бизнес-правил;
• коммерческое предложение;
• спецификации бизнес-функций;
• план работ на этапе бизнес-моделирования;
• рекомендации по проведению бизнес-моделирования;
• запросы на изменение.

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

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

Analysis and design

Артефакты-модели — используется Rational Rose:

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

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• архитектура программного обеспечения;
• спецификации программных компонентов;
• рекомендации на этапе анализа и проектирования;
• план работ на этапе анализа и проектирования;
• запросы на изменение.

Implementation

Артефакты-модели — используется Rational Rose:

компонентная модель приложения.

Артефакты-код — используются Rational Rose, средства программирования, текстовые процессоры:

• элементы генерации кода, полученные в Rational Rose;
• собственно код приложения;
• документация.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• план сборки приложения;
• план работ на этапе реализации.

Test

Артефакты-модели — используется Rational Rose:

• модель тестовых примеров;
• функциональная модель тестовой программы;
• модель спецификации компонентов тестовой программы;
• сценарии взаимодействия классов, реализующих взаимодействие компонентов тестовой программы.

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

• описание тестовых примеров;
• план тестирования;
• план работ на этапе тестирования;
• запросы на изменение.

Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Deployment

Артефакты-модели — используется Rational Rose:

модель размещения — описание размещения компонентов по узлам обработки.

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

• обучающие материалы;
• документы по инсталляции;
• описание версий системы;
• план внедрения.

Conclusion

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end — users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be experts in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

The structure of RUP

This approach describes who is doing what, how and when. RUP can be presented by using four main elements:

Workers — the “Who”

It defines the behavior and responsibilities of all team members who are all focus on one common goal — to produce artifacts. In RUP, the worker is more of a role defining how individuals should carry out their work. A worker should not only perform a certain set of activities but also be the owner of a set of artifacts.

Activities — the “How”

It refers to the unit of work that a worker is to perform. Each activity has a clear purpose and is assigned to the specific worker. Activities mainly include creating or updating some artifacts such as a model, a class, or a plan.

Artifacts — the “What”

The thing or the information that the process produces modifies or uses while working towards the final outcome. Artifacts serve as input that workers use to perform an activity and are also results or output of those activities.

Workflows — the”When”

Workflow represents a sequence of activities that produce an observable value. In UML terms, we can present workflow in a sequence diagram, a collaboration diagram, and activity diagram.

Характеристики

Unified Process
основан на сценариях использования
, описывающих одно или несколько действующих лиц, взаимодействующих с системой и получающих результаты, представляющие ценность для участников процесса. Именно сценарии использования являются основной движущей силой, управляющей всем процессом разработки, начиная со сбора и обсуждения требований, и заканчивая анализом, дизайном и имплементацией. Сценарии использования описываются простым и понятным языком, так, чтобы быть понятным стороннему читателю.

Согласно Unified Process
, в центре процесса разработки лежит архитектура
— фундаментальная организация всей системы. Она может включать в себя статические и динамические элементы, их взаимодействие, и позволяет решать вопросы эффективности работы продукта, расширяемости, возможности переиспользования элементов, помогать преодолеть экономические и технические ограничения. Проектная команда начинает работу над описанием архитектуры как можно раньше, и в процессе разработки постоянно расширяет и улучшает его. Архитектура считается важным аспектом Unified Process
по ряду причин, ключевыми из которых являются возможность увидеть полную картину происходящего, правильное приложение усилий разработчиков, фасилитация возможностей по переиспользованию компонентов, развитие системы, правильный подбор сценариев использования.

Третьим фундаментальным принципом Unified Process
является использование итеративного и инкрементного подхода
. Итерациями называются миниатюрные проекты, которые позволяют запустить более новую версию системы. Результат итерации, изменения, внесённые в систему, называются инкрементом. В частности, итеративный подход позволяет последовательно улучшать архитектуру системы, обрабатывать постоянные изменения требований, гибко подстраивать план всего проекта. Приверженность принципу непрерывной интеграции позволяет выявлять возможные проблемы на ранней стадии. Помимо этого, итеративность помогает минимизировать риски, связанные с техническими ограничениями, архитектурой и изменяющимися требованиями .

Предназначение RUP

     Rational
Unified Process – это модель создания 
программного обеспечения, оформленная 
в виде размещаемой на Web базы 
знаний, которая снабжена поисковой 
системой.

     Продукт
Rational Unified Process (RUP) разработан и поддерживается
Rational Software. Он регулярно обновляется с
целью учета передового опыта и улучшается
за счет проверенных на практике результатов.

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

     RUP
способствует повышению производительности 
коллективной разработки и предоставляет 
лучшее из накопленного опыта по созданию
ПО, посредством руководств, шаблонов
и наставлений по пользованию инструментальными
средствами для всех критически важных
работ, в течение жизненного цикла создания
и сопровождения ПО. Обеспечивая каждому
члену группы доступ к той же самой базе
знаний, вне зависимости от того, разрабатывает
ли он требования, проектирует, выполняет
тестирование или управляет проектом
— RUP гарантирует, что все члены группы
используют общий язык моделирования,
процесс, имеют согласованное видение
того, как создавать ПО. В качестве языка
моделирования в общей базе знаний используется
Unified Modeling Language (UML), являющийся международным
стандартом.

     Особенностью
RUP является то, что в результате
работы над проектом создаются и 
совершенствуются модели. Вместо создания
громадного количества бумажных документов,
RUP опирается на разработку и развитие
семантически обогащенных моделей, всесторонне
представляющих разрабатываемую систему.
RUP – это руководство по тому, как эффективно
использовать UML. Стандартный язык моделирования,
используемый всеми членами группы, делает
понятным и для всех описания требований,
проектирование и архитектуру системы.

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

     RUP
– это конфигурируемый процесс,
поскольку, вполне понятно, что невозможно
создать единого руководства на все случаи
разработки ПО. RUP пригоден как для маленьких
групп разработчиков, так и для больших
организаций, занимающихся созданием
ПО. В основе RUP лежит простая и понятная
архитектура процесса, которая обеспечивает
общность для целого семейства процессов.
Более того, RUP может конфигурироваться
для учета различных ситуаций. В его состав
входит Development Kit, который обеспечивает
поддержку процесса конфигурирования
под нужды конкретных организаций.

     RUP
описывает, как эффективно применять 
коммерчески обоснованные и практически 
опробованные подходы к разработке 
ПО для коллективов разработчиков, 
где каждый из членов получает 
преимущества от использования 
передового опыта в: 

     •
итерационной разработке ПО,

     •
управлении требованиями,

     •
использовании компонентной архитектуры,

     •
визуальном моделировании,

     •
тестировании качества ПО,

     •
контроле за изменениями в ПО.

     RUP
организует работу над проектом 
в терминах последовательности 
действий (workflows), продуктов деятельности,
исполнителей и других статических аспектов
процесса с одной стороны, и в терминах
циклов, фаз, итераций и временных отметок
завершения определенных этапов в создании
ПО (milestones), т.е. в терминах динамических
аспектов процесса, с другой .

6.Заключение

 Здесь были рассмотрены
только основные процессы методологии Rational.
RUP довольно
обширен, и содержит рекомендации по ведению
различныхпрограммных
проектов, от создания программ группой
разработчиков в несколько человек, до
распределенных программных проектов,
объединяющих тысячи человек на разных
континентах. Однако, несмотря их
колоссальную разницу, методы применения
моделей, создаваемых при помощи UML будут одни и те же. Диаграммы UML,
создаваемые на различных этапах разработки,
неотделимы от остальных артефактов
программного проекта и часто являются
связующим звеном между отдельными
процессами RUP.

 Решение о применении
конкретных диаграмм зависит от
поставленного в компании процесса
разработки, который, хотя и называется
унифицированным, однако не есть нечто
застывшее. Компания Rational
не только предлагает его улучшать и
дорабатывать, но и предоставляет
специальные средства внесения изменений в
базу данных RUP.

 Но в любом случае, применение
UML вместе с
унифицированным процессом позволит
получить предсказуемый результат,
уложиться в отведенный бюджет, повысить
отдачу от участников проекта и качество
создаваемого программного продукта.

 
Крачтен.Ф.
Введениев Rational
Unified Process. Изд. 2-е.- М.:
Издательский дом «Вильямс», 2002. — 240 с.:
ил.

  Якобсон А., Буч Г., Рамбо Дж.
Унифицированный процесс разработки
программного обеспечения- Спб.: Питер,
2002. — 496 с.: ил.

  Фаулер М., Скотт К. UML в
кратком изложении. Применение стандартного
языка объектного моделирования: Пер. с англ.
– М.:Мир, 1999. – 191 с., ил.

  Бек. Е. Экстремальное
программирование. – Спб.: Питер, 2002. – 224 с.:
ил.

  ТрофимовС. CASE-технологии: Практическая работа в
Rational Rose.
Изд. 2-е.- М.: Бином-Пресс, 2002 г. — 288 с.

Заключение

В любом случае, все вышеприведенные выводы являются обобщёнными, поскольку ситуация в каждом конкретном случае является по своему уникальной и стандартных рецептов для процесса производства ПО нет и вряд ли когда-либо будет. Эта область деятельности человека все еще очень молода и в достаточной степени зависит от человеческого фактора. Однако, автор статьи надеется, что приведенный обзор методологий и краткий анализ их применимости поможет вам разобраться в существе вопроса и принять правильные решения. Надо лишь помнить, что «Относительно небольшое увеличение веса используемой методологии ведет к относительно большому увеличению стоимости проекта» .