Methodologies are the core of management theory software development. To the existing classification depending on the life cycle model used in it (cascade and evolutionary) added a more general classification into predictive and adaptive methodologies.

Predictive (predicative) methodologies focus on detailed planning for the future. Scheduled tasks are known and resources for the duration of the project. The team has difficulty responding to possible changes. The plan is optimized based on the scope of work and existing requirements. Changing requirements may result in a significant change in the plan, as well as the design of the project.

Adaptive (flexible) methodologies are aimed at overcoming expected incompleteness of requirements and their constant change. When requirements change, the development team also changes. Command, involved in adaptive development, can hardly predict the future of the project. There is an exact plan only for the near future. More remote plans exist only as declarations of project objectives, expected costs and results. Among adaptive methodologies: (Scrum, Crystal, Extreme Programming, Adaptive Software Development, DSDM, Feature Driven Development, Lean software development). Consider the most basic and popular methodologies.

Rational Unified Process

One of the most famous processes using iterative development model – RUP. It was created in the second half of the 1990s years at Rational Software. The term RUP stands for methodology and product from IBM (formerly Rational) for development process management. The RUP methodology describes abstract overall process by which an organization or the project team must create a specialized process, tailored to her needs. Main characteristics:

• requirements development, to describe requirements in RUP use cases are used. Full a set of use cases for the system along with logical relationships between them is called the use case model use. Each use case is a description scenarios of user interaction with the system, completely performing a specific user task. According to RUP all functional requirements must be submitted in the form of use cases.
• iterative development, the RUP project consists of sequence of iterations with the recommended lasting from 2 to 6 weeks. Before the start of the next iteration defines a set of use cases that will be implemented by the end.

Architecture

RUP can be said to be architecture oriented methodology. It is believed that the implementation and testing of the architecture systems should start at the earliest stages of the project. RUP uses the concept of executable architecture – the foundations of an application that allows you to implement architecturally significant use cases. The fundamentals of the executable architecture should be implemented as early as possible.

This allows you to evaluate the adequacy of the adopted architectural solutions and make the necessary adjustments at the beginning of the project. Thus, for the first several iterations, it is necessary to choose cases that require the implementation of most of the architectural components.

RUP encourages the use of visual aids for analysis and design. As a rule, notation is used and, accordingly, UML modeling tools (such as Rational Rose). Model subject area is documented in the form of a class diagram, a model use cases – using a use case diagram, the interaction of the system components with each other is described sequence diagram, etc.

Project life cycle

The life cycle of a RUP project consists of four phases. The sequence of these phases is fixed, but the number of iterations required to complete each phase is determined individually for each specific project. RUP phases cannot be identify with the phases of the waterfall model – their purpose and content is fundamentally different.

1. Inception.

The start stage usually consists of one iteration. During this stage is necessary:

• define the vision and boundaries of the project;
• create a business case;
• identify most of the use cases and describe in detail several key use cases;
• find at least one possible architectural solution;
• evaluate the budget, schedule and risks of the project.

If, after the completion of the first iteration, stakeholders come to the conclusion about the feasibility of the project, the project moves to the next stage. Otherwise, the project may be canceled or carried out another iteration of the stage “beginning”.

• Elaboration.

As a result of this stage, based on the requirements and The risk of the project creates the basis of the system architecture. Design may take up to two or three iterations or be completely omitted (if the project uses the architecture of an existing systems unchanged). The objectives of this phase are:

• a detailed description of most of the use cases;
• creation of a tested (with the help of architecturally significant use cases) of the underlying architecture;
• reduction of the main risks and clarification of the budget and schedule project.

Unlike the waterfall model, the main result of this stage is not a set of documents with specifications, but the current system with 20-30% of implemented use cases.

• Construction.

In this stage (lasting from two to four iterations) final product development. At the time of its execution, a the main part of the source code of the system and intermediate ones are released demo prototypes.

• Transition.

The goals of the “implementation” stage are to conduct beta testing and user training, fix the detected defects, deployment of the system on the job site, with necessary – data migration. In addition, at this stage the tasks necessary for marketing and sales are carried out.

The “implementation” stage takes from one to three iterations. After her completion, an analysis of the results of the entire project is carried out: what can be changed to improve efficiency in future projects.

The working process

In terms of RUP, project team members create called artifacts (work products), performing tasks (tasks) within certain roles. Artifacts are specifications models, source code, etc. Tasks are divided into nine process areas called disciplines. The RUP defines six engineering and three support disciplines. They include:

• Business Modeling – research and description of existing business processes of the customer, as well as looking for possible improvements.
• Requirements Management – definition of project boundaries, development of functional design of the future system and its coordination with the customer.
• Analysis and Design – system architecture design based on functional requirements and its development throughout project.
• Implementation – development, unit testing and integration of system components.
• Testing (Test) – search and tracking of defects in system, checking the correctness of the implementation of requirements.
• Deployment – creation of a distribution kit, system installation, user training.
• Configuration and change management (Configuration and Change Management) – version control of the source code and documentation, the change request process (Change requests).
• Project Management – creation of project team, phase and iteration planning, management budget and risk.
• Environment (Environment) – creating infrastructure for project execution, including organization and configuration development process.

During the life cycle of the project, the distribution of efforts of the project teams between disciplines are constantly changing. Like how As a rule, at the beginning of the project, most of the effort is spent on analysis and design, and closer to completion – for implementation and testing systems. However, in the general case, tasks from all nine disciplines are executed in parallel.

To fully implement RUP, an organization must spend significant funds for employee training. At the same time, an attempt to manage on their own is likely to be doomed to failure – you need to look for a process engineer with relevant experience or involve consultants.