Rational Unified Process (RUP) is one of the best software development methodologies created by Rational Software. Based on the experience of many successful software projects, the Unified Process allows you to create complex software systems based on industrial development methods. One of the main pillars that RUP relies on is the process of creating models using the Unified Modeling Language (UML). This article is about the use of UML diagrams in the workflow of developing software systems using the Rational Software methodology.
It's no secret that software development is a complex process that, on the one hand, has much in common with creativity, and on the other hand, although it is a highly profitable, but also a high-cost business. Fierce competition in the market forces developers to search for more efficient ways of working. Ways to build software systems even faster, at lower cost, and with better quality. The complexity of programs is constantly increasing. Until recently, software products could be created in the foreseeable future by individuals or, for example, in the IT department of an automated enterprise.
Now, singles who create programs “on their knees” are left with the area of small utilities and various extension modules for “heavy” software products. The future belongs to the industrial approach to software development. In 1913, Henry Ford launched the first automobile conveyor, and in the 90s a similar conveyor began to be used in the field of IT technologies. Team development requires a completely different approach and a different methodology, which sooner or later had to be created.
The Rational Software Corporation (http://www.rational.com) has released a structured knowledge base called the Rational Unified Process (RUP), which is a comprehensive set of guidelines for building virtually any software product. Incorporating the experience of the best developments, RUP tells in detail when, who and what should be done in the project, in order to get a software system on time, with certain functionality and within the allocated budget.
A unified process can be thought of as the sum of the various activities of a development company required to translate customer requirements into a software system. A system that would give a “meaningful result” to users and would do exactly what they expect from the system. Therefore, the process is driven by use cases (Use Case) of the system, or in other words, precedents.
To meet the customer's requirements on time, the Unified Process is divided into phases, which consist of iterations, so the process is also called iterative and incremental. Each iteration goes through a cycle of major work and brings developers to the final goal: the creation of a software system. During iterations, intermediate artifacts are created that are required for the successful completion of the project and a variant of the software system that implements a certain set of functions that increases from iteration to iteration. The phases and main workflows of the process are shown in fig. 1, the approximate labor costs of works by phases are also given there.
rice. 1 RUP phases and workflows
It should be noted that in Fig. 1 shows only the main activities of the Unified Process. For example, activity management activities are not shown here so as not to clutter up the diagram.
All software development is considered in RUP as a process of creating artifacts. Any result of the project, be it source code, object modules, documents transferred to the user, models, are subclasses of all project artifacts. Each member of the project team creates their own artifacts and is responsible for them. The programmer creates the program, the manager creates the project plan, and the analyst creates the system models. RUP allows you to determine when, to whom and what artifact needs to be created, modified or used.
One of the most interesting classes of project artifacts are models, which allow developers to define, visualize, construct, and document artifacts of software systems. Each model is a self-contained view of the system being developed and is intended to both outline problems and offer solutions. The self-sufficiency of models means that an analyst or developer can get all the information he needs from a particular model without resorting to other sources.
Models allow you to consider the future system, its objects and their interaction even before investing significant funds in development, allow you to see it through the eyes of future users from the outside and developers from the inside even before the first line of source code is created. Most models are represented by UML diagrams, you can read more about UML, for example, in.
The Unified Modeling Language (Unified Modeling Language) appeared in the late 80's and early 90's, mainly due to the efforts of the "three friends" Gradi Buch, Jim Rumbaugh and Ivar Jacobson. The OMG has now adopted this language as the standard modeling language, which provides developers with a clear notation that allows them to display models in a common and understandable graphical element for every member of the project.
However, we should not forget that the modeling language gives only a notation - a tool for describing and modeling the system, and a unified process determines the methodology for using this tool, as well as other methodology support tools from Rational. UML can be used without a specific methodology because it is process agnostic, and whichever process is used, you can use diagrams to document the decisions made during development and show the models that are created.
A software system is created to solve specific user problems, and not for programmers to try out new technologies and get experience from a project manager. By and large, it doesn't matter to the user whether you use an object-oriented approach, UML, RUP, or create a system using the XP (extreme programming) method in the development process. The application of certain methods, technologies, the creation of an optimal internal structure of the project remains on the conscience of the developers, who make decisions based on previous experience and their own preferences. However, the user will not forgive you for ignoring his requirements. If a software system has been developed at least ten times using cutting-edge methods and technologies, if the user does not get what is called a “meaningful result” from it, your software project will fail miserably.
It follows that mindless use of the UML, simply because it is fashionable, not only will not lead to development success, but can also cause dissatisfaction among employees who need to study a lot of additional literature and project managers when it turns out that the labor costs on the project increase, but the returns are not increasing. You need to be clear about what you want to get from the implementation of this technology and follow this goal. The use of UML saves development resources, because it allows you to get an idea of \u200b\u200bthe system faster than when creating layouts and prototypes, spending incomparably less resources on this.
Diagrams make it easier for project members to communicate with each other, and, most importantly, involve end users of the system in the process. Modeling helps to reduce project risks, since it is always easier for programmers to do what is clear and understandable than to go to an indeterminate result. Creating diagrams is similar to creating a project in construction - you can do without it, for example, when building a barn in a summer cottage, however, the larger the building (in our case, the software product), the more difficult it is to do this and the final result is uncertain.
I once gave a seminar on RUP at a software company that has been quite successful in the market for ten years, but does not use modeling at all in its workflow, but is based on prototypes. About twenty young and experienced programmers gathered in the hall, who carefully listened to everything that I told them about RUP and UML. And then one of them, looking at a board dotted with examples of diagrams, remarked: “This is all interesting and probably well suited for other projects,” he said, “but we have been working for quite some time without all this, since we still did without UML, we probably just don’t need it.”
This question made me think that the change in business processes that must inevitably occur in a software development company when implementing RUP and UML can be as difficult as implementing an information system in an industrial enterprise. Any implementation is breaking stereotypes. Since the qualifications of employees in a software development company are quite high, it is more difficult for such people to give up their views than for "mere mortals", and the difficulties and rejection that arise can be compared with the transition from procedural to object-oriented thinking.
1. Definition of requirements
A unified process is a process driven by use cases that reflect user interaction scenarios. In fact, this is the user's view of the software system from the outside. Thus, one of the most important stages of development, according to RUP, will be the stage of determining the requirements, which consists in collecting all the possible wishes for the operation of the system that users and analysts can only come up with. Later, this data will have to be systematized and structured, but at this stage, during interviews with users and studying documents, analysts must collect as many requirements for the future system as possible, which is not as simple as it seems at first glance. Users often do not imagine what they should get in the end. To facilitate this process, analysts use use case diagrams (Fig. 2)
Figure 2. Example of a Use Case Diagram
The diagram is a reflection of the actors (actants) that interact with the system, and the reaction of software objects to their actions. Actants can be both users and external agents who need to transmit or receive information. The use case icon reflects the system's response to an external stimulus and shows what should be done for the actant.
To detail a specific use case, an Activity Diagram is used, an example of which is given in Figure 3.
rice. 3 Activity chart example
The simplicity of the use case diagram allows analysts to easily communicate with customers during the requirements definition process, to identify constraints placed on the system and on the fulfillment of individual requirements, such as system response time, which later fall into the non-functional requirements section.
Also, a use case diagram can be used to create test scripts, since all interaction between users and the system is already defined.
In order to correctly define the requirements, developers must understand the context (part of the subject area) in which the future system will work. For this, a domain model and a business model are created, which are different approaches to the same issue. Often one thing is created: a domain model or a business model.
The differences between these models is that the domain model describes the important concepts with which the system will work and their relationships with each other. Whereas the business model describes the business processes (existing or future) that the system should support. Therefore, in addition to defining the business objects involved in the process, this model defines the workers, their responsibilities and the actions that they must perform.
To create a domain model, a regular class diagram is used (Fig. 6), but it is clearly not enough to create a business model. In this case, a use case diagram is applied using additional icons that reflect the essence of business processes - these are business actant, business use case, business entity and business control. This model is much closer to the next model created during development, the analysis model.
2.Analysis
After defining the requirements and the context in which the system will work, it is time to analyze the received data. During the analysis, an analytical model is created that leads developers to the architecture of the future system. An analytical model is a view of the system from the inside, as opposed to a use case model, which shows how the system will look from the outside.
This model allows you to understand how the system should be designed, what classes should be in it, and how they should interact with each other. Its main purpose is to determine the direction of implementation of the functionality identified at the requirements gathering stage and to sketch the system architecture.
Unlike the design model created later, the analysis model is more of a conceptual model and only brings developers closer to implementation classes. This model should not have the potential inconsistencies that a use case model might have.
To display the analysis model using UML, a class diagram with stereotypes (behavior patterns) “boundary class”, “entity”, “management” is used, and collaboration diagrams are used for detailing (Collaboration) (Fig. 4). The stereotype “boundary class” represents a class that interacts with external actors, “entity” represents classes that are data stores, and “management” represents classes that manage requests to entities.
Figure 4. Collaboration Diagram Example
The numbering of messages shows their order, but the purpose of the diagram is not to consider the order of message exchange, but to visually show the relationship of classes to each other.
If we focus on the order of interaction, then its other representation will be the sequence diagram (Sequence), shown in Figure 5. This diagram allows you to look at the exchange of messages over time, visually display the sequence of the process. When using a model building tool like Rational Rose, these two types of diagrams can be generated automatically from each other (more on Rational Rose can be found, for example, in).
Rice. 5 Example sequence diagram
Deciding which of the two diagrams to create first is up to the preferences of the individual developer. Since these diagrams are a reflection of the same process, both of them allow you to reflect the interaction between objects.
3.Design
The next step in the process of creating a system will be design, during which a design model is created based on the models created earlier. This model reflects the physical implementation of the system and describes the product being created at the level of classes and components. Unlike the analysis model, the design model has a pronounced dependence on the implementation conditions, the programming languages and components used. For the most accurate understanding of the system architecture, this model should be as formalized as possible and kept up to date throughout the entire system development life cycle.
To create a design model, a whole set of UML diagrams is used: class diagrams (Fig. 5), cooperation diagrams, interaction diagrams, activity diagrams.
Fig 6. Class diagram example
Additionally, this workflow can create a deployment model that is implemented based on a deployment diagram ( Deployment Diagram ). This is the simplest type of diagram designed to model the distribution of devices in a network. Only two versions of the processor and device icons are used for display, along with the links between them.
4. Implementation
The main task of the implementation process is to create a system in the form of components - source codes of programs, scripts, binary files, executable modules, etc. At this stage, an implementation model is created that describes how the elements of the design model are implemented, which classes will be included in specific components. This model describes the way of organizing these components in accordance with the mechanisms of structuring and splitting into modules adopted in the chosen programming environment and is represented by a component diagram (Fig. 7).
rice. 7 Component diagram example
5.Testing
During testing, the results of the implementation are verified. For this process, a testing model is created, which consists of test cases, testing procedures, test components, but does not have a display on the UML diagram, so we will not dwell on it.
6.Conclusion
Only the main processes of the Rational methodology have been considered here. The RUP is quite extensive, and contains recommendations for managing various software projects, from software development by a group of developers to several people, to distributed software projects that bring together thousands of people on different continents. However, despite their huge difference, the methods of applying the models created using the UML will be the same. The UML diagrams created at various stages of development are inseparable from the rest of the software project artifacts and are often the link between separate RUP processes.
The decision to use specific diagrams depends on the development process set in the company, which, although it is called unified, is not something frozen. Rational not only offers to improve and develop it, but also provides special tools for making changes to the RUP database.
But in any case, the use of UML along with a unified process will allow you to get a predictable result, meet the allotted budget, increase the return on project participants and the quality of the software product being created.
Krachten. F. Introduction Rational Unified Process . Ed. 2 e. - M .: Williams Publishing House, 2002. - 240 p.: ill.
Jacobson A., Butch G., Rambo J. Unified software development process - St. Petersburg: Peter, 2002. - 496 p.: ill.
Fowler M., Scott K. UML in brief. Application of the standard object modeling language: Per. from English. - M.: Mir, 1999. - 191 p., ill.
Beck. E. Extreme programming. - St. Petersburg: Peter, 2002. - 224 p.: ill.
TrofimovS. CASE-technologies: Practical work in Rational Rose.
Ed. 2nd - M .: Binom-Press, 2002 - 288 p.
The Unified Process (UP) is a generalized frame a process that can be specialized for a wide range of software systems, applications, skill levels, and project sizes.
Unified Process component oriented. This means that the software system being created is built on the basis of software components, connected by well-defined interfaces.
The specific aspects of UP lie in its three characteristics:
● driven by use cases;
● is architecture-oriented;
● is iterative and incremental .
Unified process lifecycle
The UP life cycle is divided into cycles, each of which ends with the delivery of a product release. Each development cycle consists of four phases - requirements analysis and planning, design, build, implementation. Each phase is divided into iterations.
UP includes eight workflows: five major- requirements definition, analysis, design, implementation, testing and three auxiliary (to support the main ones) - configuration and change management of requirements, project management, environment management.
To define a workflow structure, you first need to determine which types of performers participate in the process. Then artifacts, which must be created during this workflow by each worker type.
18. XP is a process.
Extreme Programming(Eng. Extreme Programming, XP) is one of the flexible software development methodologies. The authors of the methodology are Kent Beck, Ward Cunningham, Martin Fowler and others.
The twelve basic Extreme Programming techniques (according to the first edition of Extreme programming explained) can be grouped into four groups:
1. Short feedback loop (Fine scale feedback)
a. Development through testing (Test driven development)
b. Planning game
c. The customer is always there (Whole team, Onsite customer)
d. Pair programming
2. Continuous, not batch process
a. Continuous Integration
b. Refactoring (Design Improvement, Refactor)
c. Frequent Small Releases
3. Understanding shared by all
a. Simplicity
b. Communication
c. Respect
d. Collective code ownership or selected design patterns (Collective patterns ownership)
e. Coding standard or Coding conventions
4. Social security of the programmer (Programmer welfare):
a. 40-hour work week (Sustainable pace, Forty hour week)
In XP, the process is divided into very small steps compared to the planned processes. This leads to the fact that the first steps may take days or weeks instead of months or even years for each step in the waterfall model. First, automated tests are written to describe the development goals. Then comes coding, which ends at the moment when all the tests pass, and programmers cannot come up with new tests. Design is done by the same people who write the code. (only the last step - the connection of design and code is common to all agile processes). An unfinished, but functioning system is shown to a narrow circle of users (most often these are the developers themselves). At this point, start writing tests for the next most important part of the system.
19. ICONIX is a process.
ICONIX was developed by Doug Rosenberg at ICONIX Software.The ICONIX process is based on use cases, but does not have many of its drawbacks. This process also uses the UML modeling language, but uses only the basic notation from UML - that's 20% of the language. The ICONIX process is based on four main phases of software development based on use cases:
● domain modeling;
● case modeling;
● requirement suitability analysis (verification that all functional requirements have been met);
● construction of sequence diagrams.
The main steps of the process are as follows:
● Requirements analysis
● Preliminary design
● Design
● Implementation
The process is based on building a minimum number of models that reflect the future system. During the analysis phase, use case models, a user interface model, and a domain entity model are created. During the preliminary design phase, a Robustness Diagram is created. The precedent model and the domain entity model are also supplemented. During the detailed design phase, a sequence diagram (SequenceDiagram) is created and a class diagram is created. During the implementation phase, the source code is generated. It is also possible to create a deployment diagram and a component diagram. each stage culminates in a review milestone when the generated diagrams need to be discussed with peers.
20. SCRUM is a process.
Scrum is a set of principles on which the development process is based, which allows, in rigidly fixed short periods of time ( sprints 2 to 4 weeks) to provide the end user with working software with new features for which the highest priority is determined. Software capabilities for implementation in the next sprint are determined at the beginning of the sprint at the planning stage and cannot be changed throughout its entire duration. At the same time, a strictly fixed short sprint duration gives the development process predictability and flexibility.
Main acting roles in Scrum: ScrumMaster- one who leads Scrum rallies and ensures that all the principles of Scrum(the role does not imply anything other than the correct conduct of the Scrum-a, the project manager is more related to Product Owner and should not be ScrumMaster);Product Owner (Product Owner) - a person who represents the interests of end users and other parties interested in the product; and cross-functional Team (Scrum Team), consisting of both developers and testers, architects, analysts, etc. (while the team size is ideally 7 ± 2 people). The team is the only fully involved participant in the development, and is responsible for the result as a whole. No one except the team can interfere with the development process during the sprint.
During each sprint, functional growth of the software is created. The set of features that are implemented in each sprint come from a milestone called product backlog(documentation of work requests) that has the highest priority in terms of the level of work requirements to be completed. Work Requests ( backlog items) determined during sprint planning tips (sprint planning meeting) are moved to the sprint stage. During this meeting, the Product Owner informs about the tasks to be completed. The Team then determines how much of what they want to accomplish in order to complete the required parts during the next sprint. During the sprint, the team performs a certain fixed list of tasks (so-called. sprint backlog). During this period, no one has the right to change the list of job requirements, which should be understood as a requirement freeze ( requirements) during the sprint.
Artifacts
product backlog is a document containing a list of functionality requirements that are ordered by importance. The product backlog is a list of what needs to be done. The elements of this list are called "stories" ( user story) or backlog elements ( backlog items). The product backlog is open for editing to all participants in the Scrum process.
05.10.17 1.6KRational Unified Process is a universal methodology for the distribution of tasks and responsibilities in software development. Its goal is to create high-quality software that meets the needs and demands of users. The RUP methodology was developed by the Rational Software Corporation, which was bought by IBM in 2003.
The incredible success of the RUP approach has helped many companies understand the importance of having a well-defined and documented development process.
The RUP methodology is designed for large development projects, so many managers believe that it is not suitable for small tasks that do not require a large amount of resources. But there are plenty of examples where small projects have benefited greatly from implementing RUP.
For example, RUP is used in TAP University's online learning management system. The company has set itself the goal of expanding the scope of traditional offline learning and improving its services for corporate, private users and students.
Although it was a small project, the implementation of the RUP methodology showed excellent results. She helped to build a set of principles necessary for organizing TAP University service use cases, helped to see the directions for moving to the third, most important phase of RUP - building.
What is the Rational Unified Process (RUP)?
Work on the process– The RUP development team works closely with customers, partners and groups of companies, constantly updating the methodology.
RUP optimizes teamwork- provides the development team with free access to the knowledge base with instructions for using the software. This helps you deal with critical issues faster. Thanks to this, the team easily finds a common language in the process of working on a project.
RUP is focused on creating and maintaining models- instead of writing a large amount of paper documentation, when using the RUP methodology, models are created - semantic representations of the software developed by the team.
RUP is an instruction for using the Unified Modeling Language (UML)- UML allows the team to easily communicate their requirements for the project, its architecture and implementation plan.
RUP is a configurable process, it suits both small development teams and large organizations.
Six Fundamental Principles of RUP
RUP is based on six main principles:
- Iterative development model– elimination of risks at each stage of the project allows you to better understand the problem and make the necessary changes until an acceptable solution is found;
- Requirements Management– RUP describes the process of organizing and tracking functional requirements, documentation and selection of optimal solutions ( both in the development process and in business);
- Component architecture- the architecture of the system is divided into components that can be used both in current and future projects;
- Visual software modeling - RUP development methodology shows how to create a visual model of the software in order to understand the structure and behavior of the architecture and its components;
- Software quality check- in the software development process, the quality of all team actions is controlled;
- Change control Tracking changes allows you to build a continuous development process. A favorable environment is created in which the team will be protected from changes in the work process.
RUP structure
This approach describes who does what, how and when. RUP can be represented as four main elements:
Employees - "Who"
The element " worker"Determines the behavior and responsibility of all team members focused on a common goal - the creation of artificial objects (artifacts). In RUP, a worker is more of a role that defines how individuals should do their job. The worker not only performs certain actions, but also owns a set of artifacts.
Actions - "How"
An action is a unit of work that a worker can perform. Every action has a clearly defined purpose. Each action is assigned to a specific worker. Actions may include creating or updating artifacts such as a model, class, or blueprint.
Artifacts (artificial objects) - "What"
In the RUP methodology, objects or information produced and modified in the process of working on the final result. Artifacts serve as both inputs to workers' actions and the results of those actions.
Workflow - "When"
A workflow is a sequence of actions leading to a visible result. In UML terms, you can think of a workflow as a sequence diagram, collaboration diagram, or activity diagram:
RUP lifecycle
RUP lifecycle It is divided into four main phases, in each of which work is carried out on a new generation of the product: the project initiation phase, refinement, construction and implementation.
- Project start phase
In this phase, the team defines the structure and main idea of the project. The team decides whether or not to pursue the project at all based on its estimated cost, the resources needed, and the goal to be achieved.
- Clarification
The purpose of this phase is to analyze the requirements for the system and its architecture, develop a project plan and eliminate the highest risk elements. This is the most important phase of all, as it marks the transition from low to high risk. Within this phase, the team decides whether to proceed to the build phase ( development and coding) or not.
- Building
In this phase of the RUP methodology, the team starts developing all the components and functions of the software and integrates them into the final product. It is a manufacturing process where the team focuses on managing resources to optimize costs, time and product quality.
- Implementation
The phase when the product is ready and delivered to the customers. But after users receive the product, new difficulties may arise. The team will need to fix bugs, catch bugs, and complete features that were not implemented within the initial deadline.
At the end of each phase, there is a milestone completion mark ( Project Milestone) is the moment when your team evaluates whether the set goals have been achieved. At the same time, the team makes important decisions that affect the course of the next phase.
Rational Unified Process(RUP) is a software development technology framework developed and marketed by Rational Software. It incorporates the world's best practices in software development and provides a disciplinary approach to assigning and managing tasks and responsibilities in a software development organization. By applying this process, software development teams can create high-quality software that meets the needs of their end users, and do so within a predictable schedule and budget.
RUP guides software professionals to effectively apply today's best practices such as iterative development, application architectural centric approach, use cases, risk reduction at all stages of the process and continuous program verification.
At the heart of the Rational Unified Process are several fundamental principles gathered from many successful projects:
· Start attacking major risks early and keep attacking or they will attack you.
· Ensure customer requirements are met.
· Concentrate on the executable program.
· Adapt to changes from the very beginning of the project.
· Lay down the executable architecture early.
· Build a system from components.
· Work together as a team.
· Make quality a way of life, not an afterthought.
RUP uses iterative approach Each iteration does a bit of requirements work, analysis, design, implementation, and testing. Each iteration builds on the results of previous iterations and produces an executable program that is one step closer to the final product.
RUP provides structured approach to iterative development, dividing the project into four phases: Start, Design, Build and Implement. Each phase is accompanied by a so-called milestone - a milestone in the process, in which the achievement of the goals of the next phase is checked, and a decision is made on the transition (or not transition) to the next phase. Each of the four phases of RUP thus has a milestone and a well-defined set of goals. These goals are used to determine what tasks to perform and what artifacts to create. Each phase focuses strictly on what is needed to achieve the phase's business objectives.
All elements of the process roles, tasks, artifacts and related concepts, guides and templates grouped into logical containers called disciplines(Disciplines). There are only nine disciplines in the standard RUP product. These include: business modeling, requirements management, project management, change management, and environment.
Each process workflow: requirements gathering, analysis, design, implementation, and testing defines a set of associated artifacts and activities. Recall that an artifact is a document, report, executable element, and so on. Artifact can be produced, processed or consumed.
There are dependencies between thread artifacts. For example, the Use Case model, generated during the collection of requirements, to be specified analysis model from the design process, implemented implementation model from the implementation process and checked test model from the testing process.Model- the most important type of artifact. Nine models are provided, together they cover all solutions for visualization, specification, design and documentation of software systems:
· business model. Specifies the abstraction of the organization for which the system is being created;
· domain model. Fixes the context environment of the system;
· Model Use Case. Defines the functional requirements for the system.
· analysis model. Interprets system requirements in terms of the design model;
· design model. Defines the vocabulary of the subject area of the problem and its solution;
· placement model. Specifies the hardware topology in which the system runs;
· implementation model. Defines the parts that are used to assemble and implement the physical system;
· test model. Defines test cases for checking the system;
· process model. Defines concurrency in the system and synchronization mechanisms.
Technical artifacts divided into four main sets:
a set of requirements. Describes What the system must do;
· design set.
Describes How the system must be designed;a set of implementations. Describes the assembly of the developed software components;
accommodation set. Provides all information about the supplied configuration.
Requirements set may include a Use Case model, a non-functional requirements model, a scope model, an analysis model, and other forms of expressing user needs.
Design set may include a design model, a test model, and other forms of system entity expression.
Set of implementations groups all data about the software elements that make up the system (program code, configuration files, data files, software components, system assembly information).
Placement set groups all the information about packing, shipping, installing and starting the system.
Each technological process is accompanied risk. When developing a software product, an unsatisfactory result (NU) can be: over budget, low reliability, incorrect functioning, etc. The impact of risk is calculated by the expression
Risk Index = Probability (NU) * Loss (NU).
risk management includes six steps:
1. Risk identification - identification of elements of risk in the project.
2. Risk analysis - an assessment of the probability and magnitude of loss for each element of risk.
3. Risk ranking - ordering risk elements according to the degree of their influence.
4. Risk management planning - preparation for dealing with each element of risk.
5. Risk resolution - elimination or resolution of risk elements.
6. Risk monitoring - tracking the dynamics of risk elements, taking corrective actions.
The first three steps refer to the risk assessment stage, the last three steps to the risk control stage.
There are three categories of risk sources: project risk, technical risk and commercial risk. After identifying risk elements, their impact on the software project should be quantified, and questions about possible losses should be resolved. These issues are addressed in the risk analysis step. And, finally, a management plan for each element of risk, that is, a set of functions for managing each element of risk, is integrated into the overall plan of the software project.
Unified Process Rational's development (Rational Unified Process, RUP) is the sum of the various activities required to transform user requirements into a software system, . Its abstract and expanded representation is shown in Fig. 7.2.
The main concepts of RUP are artifact (artifact) and precedent (precedent). Artifacts- these are some of the products of the project, generated or used in it when working on the final software product. precedents or use cases(use cases) ‑ it is a sequence of actions performed by a software system to obtain an observable result.
The whole process of developing a software system is considered in RUP as artifact creation process. Moreover, what falls into the hands of the end user, be it a software module or software documentation, is one of the subclasses of all project artifacts.
Each member of the project team creates their own artifacts and is responsible for them. The programmer develops the program, the manager develops the project plan, and the analyst develops the system models. RUP allows you to determine when, to whom and what artifact needs to be created.
(A)
Rice. 7.2. Unified software development process ( A- abstract representation, b- a detailed view of the main RUP processes)
However, RUP is more than a single process; it is a generalized process framework that can be specialized for a wide range of software systems, different application areas, skill levels, and project sizes. RUP - component-oriented. This means that the software system being created is built on the basis of software components linked by well-defined interfaces.
To develop graphical representations (models) of a software system, RUP uses Unified Modeling Language(UML) . In fact, UML is an integral part of RUP - they were developed jointly.
However, the really specific aspects of the RUP process lie in three phrases - use case driven, architecture-oriented, iterative and incremental. This is what makes the Unified Process unique.
The complete representation of a software system in RUP includes nine models that collectively cover all critical decisions regarding the visualization, specification, construction, and documentation of a software system (Figure 7.3):
1. business process model, which formalizes the abstraction of the organization (with all use cases of the managing PS and their relationships with users);
2. precedent model- formalizes the functional requirements for the system;
3. domain model or business model A that describes the context of the system.
4. analysis model, which has two goals - to refine the details of use cases and to create a primary distribution of system behavior over a set of objects that provide different behaviors;
5. process model(optional) - formalizes the mechanisms of parallelism and synchronization in the system;
6. design model, which defines: ( A) is the static structure of the system, such as subsystems, classes, and interfaces, and ( b) - use cases implemented as cooperations between subsystems, classes and interfaces;
7. implementation model, which includes the components (represented by the source code) and the layout of classes by components;
8. deployment model, which defines physical computers - network nodes and the layout of components for these nodes;
9. testing model, which describes test cases for validating use cases;
Rice. 7.3. RUP models (in the form of appropriate UML diagrams)
and their connections
All these models are connected. Together they completely describe the software system. Elements of one model have forward and backward routing dependencies, organized using links to other models (see Figure 7.3). For example, a use case (in a use case model) can be traced back to a corresponding use case implementation (in a design model) and a test case (in a test model). Tracing makes it easier to understand and make changes. UML diagrams created during the RUP development process give a complete picture of the software product).
The main emphasis in RUP is not on the preparation of documents as such, but on modeling the system being developed. Models help to outline both the problem and ways to solve it, and they are created using the UML language, which has long become the de facto standard for describing complex systems and allows developers to define, visualize, design and document artifacts of software systems of any complexity.