Unified Process– this is a generalized framework of the process of creating software, which can be specialized for a wide range of software systems. The unified process uses a unified modeling language to develop a model of a software system.

start attacking the main risks, conduct it continuously, otherwise the risks will attack you.

ensure that customer requirements are met: document the requirements in a way that the customer can understand, and strictly adhere to these requirements during design and implementation

concentrate on the program at hand: running software passing tests better than comprehensive documentation

adapt to changes from the very beginning of the project: modern applications are complex enough that we can get specific requirements at the very beginning of development. Therefore, it is necessary to design the software architecture in such a way that it is susceptible to change.

lay the foundation of an executable architecture as early as possible. Executable architecture - key use cases. The key VI is the functionality of the system, without which the software does not make sense. Key. VIs make up 7-10% of all options

build a system from components. Component-based applications are built faster, are more flexible in terms of changes, and are relatively low cost.

work as 1 team

make quality a way of life, not an afterthought

6 Life cycle of a unified process. The goals of each stage.

The unified process is repeated cyclically. This sequence of iterations of the Unified Process represents the life cycle of the system. Each cycle ends with the delivery of a product release to customers.

Each cycle consists of four phases - requirements analysis and planning, design, construction and implementation. Each phase, as discussed below, is further subdivided into iterations.

During analysis and planning phases requirements good idea turns into a concept for a finished product and a business plan for the development of this product is created. In particular, at this phase the following questions should be answered:

What should the system do first for its primary users?

What should the system architecture look like?

What is the plan and how much will it cost to develop the product?

At this stage, a trial version of the architecture is created. It is usually an outline containing the most important subsystems. During this phase, the most important risks are identified and prioritized, the design phase is planned in detail, and the overall project is roughly estimated.

During design phases most use cases are described in detail and the system architecture is developed.

At the end of the design phase, the project manager is engaged in planning activities and calculating the resources needed to complete the project. The key question at this point will be: are the use cases, architecture, and design sufficiently mature, and are the risks under control enough to warrant a contractual commitment to complete the development work?

During construction phases a product is being created - muscles (completed programs) are added to the skeleton (architecture). During this phase, the basic level of architecture grows into a complete mature system. Concepts are developed into a product ready to be handed over to users. During the phase, the amount of required resources increases. At the end of this phase, the product includes all the use cases that management and the customer agreed to include in the current release. True, they may contain errors. Most defects will be discovered and corrected during the implementation phase. The key end-of-phase question is: Does the product satisfy user requirements to the point that some customers can be pre-delivered?

Implementation phase covers the period during which the product exists as a beta release or beta version. A small number of qualified users working with the beta release of the product report defects and shortcomings. The developers then fix any bugs they find and incorporate some of the suggested improvements into a major release that is ready for wide distribution. The implementation phase includes activities such as production of copies, training of customer employees, organizing hotline support and correcting defects discovered after delivery.

Rational Unified Process (RUP)- development methodology software, created by Rational Software.

Principles: Early identification and continuous (until the end of the project) elimination of major risks. Concentration on meeting customer requirements for the executable program (analysis and construction of a model of precedents (use cases)). Expect changes in requirements, design decisions and implementation during the development process. Component architecture implemented and tested early in the project. Continuous quality assurance at all stages of project (product) development.

Working on a project in a close-knit team, in which architects play a key role.

RUP uses iterative development model. At the end of each iteration (ideally lasting 2 to 6 weeks), the project team should achieve the goals planned for this iteration, create or refine design artifacts, and obtain an intermediate but functional version of the final product.

The complete product development life cycle consists of four phases, each of which includes one or more iterations: the initial phase, the phase of clarification, design and implementation.

Extreme Programming (XP)

Extreme Programming(Extreme Programming, XP) - one of the flexible software development methodologies

12 basic techniques extreme programming (according to the first edition of the book Extreme programming explained) can be combined into four groups:

Short cycle feedback: (Test Driven Development, The Planning Game, The Customer Is Always There, Pair Programming

Continuous rather than batch process: Continuous integration, Refactoring, Frequent small releases

Understanding shared by all: Simplicity, System Metaphor, Collective Ownership of Code or Selected Design Patterns, Coding Standard

Social security of a programmer: 40 hour work week

Pair programming involves all the code being created by pairs of programmers working on the same computer. Collective ownership means that each team member is responsible for all source code. The "customer" in XP is not the one who pays the bills, but the one who actually uses the system.

Documentation Standards

Standards ensure compatibility between projects. Standards improve understanding among engineers. Standards should be perceived by engineers as something useful to them, not as a set of obstacles. Clear and measurable goals that require a disciplined and documented approach are usually a good motivator for developers

SVVP- The plan determines how and in what sequence the stages of the project should be tested. Verification is the process of verifying that an application is built correctly. Validation verifies that the required product has been assembled.

SQAP- Software Quality Control Plan

SCMP- Management plan software project

SRS- Software Requirements Specification

SDD- Software design documentation

STD- Software Testing Documentation

Consistency and integrity of documentation.

Document management requires significant organizational skills. Writing good and flexible documentation is similar to writing good and flexible code.

Document management means maintaining it completeness And consistency and also includes configuration management.

Completeness – availability of a set of documentation covering the development and maintenance process.

Consistency means that the set of documents does not contain internal contradictions. The problem is that when this set is large, it is quite difficult to avoid the appearance of mutually exclusive statements in it.

Configuration support – it is the coordination of different versions and parts of documentation and program code.

RUP is an example of the so-called "difficult" process, described in detail and suggesting support for the actual development of the software source code with a large number of auxiliary actions. Examples of such activities are developing plans, technical assignments, numerous design models, design documentation, etc. The main goal of this process is to separate successful software development and maintenance practices from specific people who know how to apply them. Numerous supporting actions give hope to make it possible successful solution tasks of constructing and supporting complex systems with the help of existing workers, who are not necessarily super-professionals.

To achieve this, a hierarchical step-by-step detailed description of the actions taken in a given situation is carried out so that an ordinary worker can be taught to act in a similar way. During the course of a project, many intermediate documents are created that allow developers to sequentially break down the tasks they face into simpler ones. These same documents serve to verify the correctness of decisions made at each step, as well as track the overall progress of work and clarify estimates of the resources needed to achieve the desired results.

Extreme Programming, on the contrary, represents the so-called "live" (agile) development methods, also called "light" processes. They emphasize using good developers rather than good development processes. Living methods avoid committing to clear blueprints to allow for greater flexibility on a project-by-project basis, and they also discourage the development of additional documents that do not directly contribute to a finished, working program.

Rational Unified Process

RUP is quite complex, detailed iterative life cycle model BY .

Historically, RUP is a development of the development process model adopted by Ericsson in the 70s and 80s of the 20th century. This model was created by Ivar Jacobson, who subsequently, in 1987, founded his own company Objectory AB specifically for the development technological process developing software as a separate product that could be transferred to other organizations. After Objectory was merged into Rational in 1995, Jacobson's developments were integrated with the work of Royce (Walker Royce, son of the author of the "classical" cascade model), Kruchten (Philippe Kruchten) and Booch (Grady Booch), as well as with the parallel development universal modeling language (Unified Modeling Language, UML).

RUP is based on three key ideas:

The entire progress of work is guided by the final goals of the project, expressed in the form use cases- scenarios of interaction of the resulting software system with users or other systems, during which the users receive results and services that are meaningful to them. Development begins with the identification of use cases and at each step is controlled by the degree of closeness to their implementation.

• The main decision made during the project is architecture the resulting software system. The architecture establishes the set of components from which the software will be built, the responsibilities of each component (i.e., the subtasks it solves within the framework of the overall tasks of the system), clearly defines the interfaces through which they can interact, as well as how the components interact with each other.

  Architecture is both the basis for obtaining quality software and the basis for planning work and project estimates in terms of the time and resources required to achieve certain results. It comes in the form of a set graphic models in UML language.

• The basis of the development process is planned And guided iterations, the scope of which (the functionality implemented within the iteration and the set of components) is determined on the basis of the architecture.

Unified Process(UP) is a generalized frame a process that can be specialized for a wide range of software systems, different application areas, skill levels and project sizes.

Unified Process component oriented. This means that the created software system 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 architecturally oriented;

● is iterative and incremental .

Unified Process Lifecycle

The UP life cycle is broken down into cycles, each of which culminates in the delivery of a product release. Each development cycle consists of four phases - requirements analysis and planning, design, construction, implementation. Each phase is divided into iterations.

UP includes eight workflows: five main- definition of requirements, analysis, design, implementation, testing and three auxiliary ones (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 what types of performers participate in the process. Then determined artifacts, which must be created during a given workflow by each type of worker.

18. XP is a process.

Extreme Programming(English: 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 techniques of extreme programming (according to the first edition of the book Extreme programming explained) can be combined into four groups:

1. Short feedback cycle (Fine scale feedback)

a. Test driven development

b. Planning game

c. The customer is always nearby (Whole team, Onsite customer)

d. Pair programming

2. Continuous rather than batch process

a. Continuous Integration

b. Refactoring (Design Improvement, Refactor)

c. Frequent Small Releases

3. Understanding shared by all

a. Simplicity (Simple design)

b. Communication

c. Respect

d. Collective code ownership or selected design patterns (Collective patterns ownership)

e. Coding standard or Coding conventions

4. Programmer welfare:

a. 40-hour work week (Sustainable pace, Forty hour week)

In XP, the process is divided into very small steps compared to scheduled processes. This results in the first steps taking 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 the programmers cannot come up with new tests. The design is done by the same people who write the code. (only the last step - connecting 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, they 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 use-case based, but does not have many of its disadvantages. This process also uses the UML modeling language, but only the basic notation from UML is used - that's 20% of the language. The ICONIX process is based on four main use case-based software development steps:

● domain modeling;

● modeling of precedents;

● analysis of requirements suitability (checking that all functional requirements are met);

● construction of sequence diagrams.

The main stages 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. At the analysis stage, 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 complemented. 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 created. You can also create a deployment diagram and a component diagram. each stage culminates in a review milestone where the generated diagrams need to be discussed with colleagues.

20. SCRUM is a process.

Scrum is a set of principles on which the development process is built, allowing for strictly fixed short periods of time ( sprints from 2 to 4 weeks) provide the end user with working software with new features that have the highest priority. Software capabilities for implementation in the next sprint are determined at the beginning of the sprint at the planning stage and cannot change throughout its entire duration. At the same time, the strictly fixed short duration of the sprint gives the development process predictability and flexibility.

Main acting roles in Scrum: ScrumMaster- the one who leads Scrum rallies and ensures that all principles are observed Scrum(the role does not imply anything other than the correct conduct of the Scrum-ah, the project manager rather refers 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. (with the ideal team size being 7±2 people). The team is the only fully involved participant in the development, and is responsible for the result as a single whole. No one other than 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 delivered in each sprint come from a stage called product backlog(documentation of work requests) having the highest priority in terms of the level of work requirements that must be completed. Requests for work ( backlog items), determined throughout sprint planning council (sprint planning meeting), are moved to the sprint stage. During this meeting, the Product Owner communicates the tasks that need to be completed. The Team then determines how much of what they want to accomplish to complete the required parts during the next sprint. During a sprint, the team completes a certain fixed list of tasks (the so-called. sprint backlog). During this period, no one has the right to change the list of job requirements, which should be understood as freezing requirements ( requirements) during a sprint.

Artifacts

Product backlog is a document containing a list of functionality requirements, ordered by importance. A product backlog is a list of what needs to be delivered. The items in this list are called "stories" ( user story) or backlog elements ( backlog items). The product backlog is open for editing by all participants in the Scrum process.

Introduction

Rational Unified Process (RUP) is one of the spiral software development methodologies. The methodology is supported by Rational Software, and the product is updated approximately twice a year. As a modeling language in common base knowledge, the Unified Modeling Language (UML) is used.

Iterative software development in RUP involves dividing a project into several small projects that are carried out sequentially, and each development iteration is clearly defined by a set of goals that must be achieved at the end of the iteration. The final iteration assumes that the set of iteration goals must exactly match the set of goals specified by the product customer, that is, all requirements must be met.

RUP is quite well formalized, and the greatest attention is paid to the initial stages of project development - analysis and modeling. Thus, this methodology is aimed at reducing commercial risks (risk mitigating) by detecting errors in the early stages of development. Technical risks are assessed and prioritized early in the development cycle, and then revised over time and as the project evolves through subsequent iterations. New goals appear depending on the priorities of these risks. Version releases are distributed in such a way that the highest priority risks are addressed first.

The process involves the evolution of models; an iteration of the development cycle uniquely corresponds to a specific version of the software model. Each iteration (workflow) contains elements of software life cycle management: analysis and design (modelling), implementation, integration, testing, implementation. In this sense, RUP is an implementation of the spiral model, although it is often depicted as a table graph. Below we present the main components of the process.

For successful process Development requires three components (Fig. 1): a process, a notation, and a set of utilities. A process describes what we do, in what order, and in what way; notation is a means of communication; a set of utilities helps automate and manage the process.

Rice. 1. Triangle of success

RUP contains all three components. First, let's look at the notation functions that do the following:

Carries out “gluing” the process into a single whole;

Is a language-based means of making decisions that are not obvious from the source code;

Provides semantics to represent important strategic and tactical decisions;

Offers a form sufficient to reflect and then make decisions and means of automating the process in order to manipulate formalized data.

In fact, the notation covers software development, from analysis to product implementation. Notation in the case of RUP–UML is a formal language means of describing a process (UML will be discussed below). Next, we will consider the structure of the process, and also provide a set of utilities used in the process of managing project development according to RUP.

RUP structure

UP provides a structured approach to iterative software development, dividing the process into four milestones over time: Inception, Elaboration, Construction, and Transition. Unfortunately, there is no established terminology in the Russian language, so in the future we will use English terms, accompanied by their translation into Russian. In Fig. Figure 2 is a widely used depiction of RUP phases. The goals of each of these phases are:

Inception understanding what we are creating. Phase of collecting information and analyzing requirements, defining the image of the project as a whole;

Elaboration understanding how we create it. Requirements analysis and system design phase, planning required activities and resources, specification of functions and design features;

Construction creation of a beta version of the product. The main phase of development and coding, building the product as an ascending sequence of iterations (code versions);

Transition creation of the final version of the product. Product introduction phase, delivery of the product to a specific user.

Rice. 2. RUP phases

These are the phases of managing product evolution - life cycle iterations. RUP involves approaching the final goal, but, unlike the classic ISO standard (waterfall methodology), where transition is the final phase, each phase can be repeated several times, reflecting changes in the customer's requirements for the product.

The RUP methodology is based on nine main workflows, which are elements of the software life cycle iteration:

Business modeling (business analysis) - involves analyzing the requirements at a given iteration of the life cycle, determining the desired system parameters and user needs;

Requirements formalization of the system image. Involves collecting and managing requirements, translating requirements into functional specifications. Here begins the analysis of precedents and the construction of use cases (user stories) formal mapping of user requirements in UML. The result is management level documents;

Analysis and design (analysis and modeling) - involves the translation of collected requirements into a formalized software model. The result is a description of the system at the implementation phase ( technical project) are documents at the level of system developers. The formalization language is Unified Modeling Language (UML), which will be discussed below. In the process of iterative development, the product of this particular flow - the project model - will evolve. All changes in RUP are tied directly to the models, and automation tools and a fairly flexible modeling language allow you to manage this process more or less painlessly in terms of time and resources. This refers to the fact that the result of development is not a model, but executable code, so the customer usually does not really like to pay for modeling, since models are not the product he needs);

Implementation (implementation, coding) - involves actually writing the code. Code elements in RUP are already created during the analysis and design phase, since the UML implementation tool - Rational Rose - allows you to create code elements in several programming languages. Methodology - object-oriented programming;

Test involves testing the product at a given iteration. It is worth specially noting that regression testing (return testing, testing of “non-deterioration” of the product) in this case should contain all the current tests from the previous iteration and acceptance tests from the previous transition phase;

Deployment (implementation) involves installing the product at the customer's site, training personnel, launching the system plus acceptance tests, preparing standards for packaging and distribution of the product, transferring materials to the sales department (actions are optional depending on the specifics of the product).

The above elements are not new in terms of the software development life cycle, since they occur in almost any methodology - perhaps with the exception of XP (where they are nevertheless presented in a very original form). A feature of the RUP implementation is the temporal emphasis, namely, at which iterations certain threads will dominate, as well as the presence of a universal language and a set of utilities that allows one to describe the development process. As we see in Fig. 2, at the initial stages of product evolution, the main attention is paid to the formalization of the project (analysis, modeling), which is aimed at reducing commercial risks and reducing the cost of design errors. When the picture is more or less clear, the actual development, testing and, finally, implementation of the product begins.

Preliminary interna these are actually documents issued by the technical council for enterprise managers. The main goal of the initial stages is to conclude a contract or letter of intent. Further iterations are the actual start of the work of the development team, which has the time and resources to build formal models. UML in this case has tools that allow you to map the model onto code elements. For example, a tree of objects is displayed directly, variations depend on the power of implementation of the programming language chosen by the developers, as well as on the coincidence of the views of G. Butch and the developers of this language on the object model. The same applies to methods.

Now let's look at the elements related to product support - core supporting workflows:

Configuration management (configuration and change management) is a powerful layer of administrative actions aimed at managing product versions, which involves control of source code (model, executable modules, tests, documentation), product version control, corporate standards for code development and documentation, tracking changes and errors (bug tracking); closely related to testing and customer support;

Management (project management) - involves a set of administrative actions for project management in accordance with the RUP ideology, project management tools are used (see below for a list of Rational products);

Environment involves the creation and maintenance analysis tools, design, development, testing (both software and hardware).

Iterative development;

Requirements management;

Use of modular architectures;

Visual modeling;

Quality checking;

Track changes.

The practices are not directly part of the RUP process, but are highly recommended. Some practices directly follow from the RUP ideology. Thus, iterative development is built into the RUP structure, since this process is one of the implementations of the “spiral”. Requirements management in RUP appears at the earliest stages of analysis. In theory, modular architecture allows code to be reused, making the system more flexible. Due to the fact that UML is an object language, it is possible to ignore modularity, but... it is somewhat difficult. Visual modeling allows you to effectively deal with the increasing complexity of systems. In addition, models are means of communication between developers, but for this, developers must speak UML, which requires some training. Visual modeling is often carried out using the Rational Rose tool, which allows you to obtain a set of very useful documents for managers, system administrators, developers, testers, and generate code elements. This tool is not the only implementation of UML - both commercial alternatives (for example, Microsoft Visio) and free ones are available. It should be noted that the UML dialects implemented in modeling tools are not always the same: the Rational dialect has some major differences, described both in the documentation and in UML books.

Products that support RUP

The following are the most well-known products that support the Rational Unified Process:

Rational Rose CASE visual modeling tool information systems, which has the ability to generate code elements. A special edition of the product Rational Rose RealTime allows you to get an executable module as output;

Rational Requisite Pro requirements management tool that allows you to create, structure, prioritize, track, and control requirements changes that arise at any stage of the development of application components;

Rational ClearQuest a product for managing changes and tracking defects in a project (bug tracking), tightly integrated with testing and requirements management tools and providing a single environment for linking all errors and documents with each other;

Rational SoDA product for automatically generating project documentation, allowing you to set a corporate standard for internal documents. It is also possible to bring the documentation to existing standards (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, - testing and debugging tools:

Rational Purify is a very powerful run-time bug-finding tool for application and component developers programming in C/C++,

Rational Visual Quantify performance measurement tool for application and component developers programming in C/C++, Visual Basic, and Java; helps identify and eliminate bottlenecks in software performance,

Rational Visual PureCoverage - automatically identifies areas of code that are not being tested;

Rational ClearCase is a product for software configuration management (Rational's Software Configuration Management, SCM), which allows version control of all project documents. With its help, you can support several versions of projects simultaneously, quickly switching between them. Rational Requisite Pro supports updates and tracks changes in requirements for the development team;

SQA TeamTest test automation tool;

Rational TestManager test management system that brings together all test-related tools, artifacts, scripts and data;

Rational Robot tool for creating, modifying and automatically running tests;

SiteLoad, SiteCheck tools for testing Web sites for performance and the presence of broken links;

Rational PerformanceStudio - measures and predicts system performance characteristics.

Artifacts and roles

An integral part of RUP are artifacts, precedents, and roles. Artifacts are some of the products of a project that are generated or used in the project while working on the final product. Use cases are sequences of actions performed by the system to obtain an observable result. In fact, any result of the work of an individual or group is an artifact, be it an analysis document, a model element, a code file, a test script, a description of a bug, etc. Certain specialists are responsible for the creation of one or another type of artifact. Thus, RUP clearly defines the responsibilities of each member of the development team at one stage or another, that is, when and who should create this or that artifact. The entire process of developing a software system is considered in RUP as a process of creating artifacts - from the initial analysis documents to executable modules, user manuals, etc. Below is a set of artifacts (models, documents, etc.) for each of the streams.

Business modeling

Business process model determination of business requirements for the system being developed;

Enterprise structure model - an artifact for developing a functional model of the system;

Models of documents, business entities, models of scenarios of business functions, models of states of business entities - for designing a user interface, database system; represent a description of the static and dynamic states of the system from various points of view;

Business Rule Models Artifact is used to model rules in software.

Document artifacts used by RequisitePro, SoDA, word processors, Microsoft Project:

Assessment of the customer’s organization, business structure;

Dictionary of subject area terms;

A set of business rules;

Commercial offer;

Business function specifications;

Work plan at the business modeling stage;

Change requests.

Requirements

Artifact models used by Rational Rose:

System function model;

System function scenario model;

User interface model;

Model of system user scenarios;

Model of output forms;

Model of system rules.

Requirements management plan;

Dictionary of system terms;

Specification for software system;

Specification for system functions;

System rules;

Stakeholder inquiries;

Work plan at the stage of determining system requirements;

Change requests.

Analysis and design

Artifact models used by Rational Rose:

Logical data model;

Physical data model;

Model of system component specifications;

Scenarios of interaction between classes that implement system components.

Document artifacts used by RequisitePro, SoDA, word processors, MS Project:

Software architecture;

Specifications of software components;

Work plan at the analysis and design stage;

Change requests.

Implementation

Artifact models used by Rational Rose:

Component application model.

Artifacts-code used by Rational Rose, programming tools, word processors:

Code generation elements sourced from Rational Rose;

The actual application code;

Documentation.

Document artifacts used by RequisitePro, SoDA, word processors, MS Project:

Application build plan;

Work plan at the implementation stage.

Test

Artifact models used by Rational Rose:

Test case model;

Functional model of the test program;

Test program component specification model;

Scenarios for the interaction of classes that implement the interaction of test program components.

Description of test cases;

Test plan;

Work plan for the testing phase;

Change requests.

Testing implementation Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Deployment

Artifact models used by Rational Rose:

Placement model description of the placement of components at processing nodes.

Document artifacts used by SoDA, word processors, MS Project:

Educational materials;

Installation documents;

Description of system versions;

Implementation plan.

The next article in this series will be devoted to the Unified Modeling Language (UML).