The problems that software engineers often have to solve are extremely complex. Understanding the nature of the problems can be very difficult, especially if the system is new.
Consequently, it is difficult to define exactly what the system should do. The descriptions of the services and restrictions are the requirements for the system, and the process of discovering, analyzing, documenting, and verifying these services and restrictions is called requirements engineering. Many of the problems of software engineering stem from the imprecision in the specification of requirements. It is natural for a systems developer to give interpretations of an ambiguous requirement in order to simplify its implementation. However, it is often not what the customer wants. New requirements have to be stipulated and changes must be made to the system. Of course, this delays delivery of this and increases costs.
User requirements for a system describe functional and non-functional requirements in such a way that they are understandable by system users who do not possess detailed technical knowledge. They only specify the external behavior of the system and avoid, as much as possible, the design features of the system. Therefore, user requirements should not be defined using an implementation model. They should be written using natural language, simple diagrams and representations.
When user requirements include too much information, they restrict the system developer's freedom to provide innovative solutions to user problems and make the requirements difficult to understand. User requirements should simply focus on the main resources to be provided.
The software process is a set of activities and associated results that lead to the creation of a software product. This may consist of software development from scratch, although new software is increasingly being developed by expanding and modifying existing systems. One reason why there is a limited focus on the automation process is the vast diversity of software processes. There is no ideal process and different organizations have developed completely different approaches to developing software. Processes have evolved to exploit the capabilities of the people in an organization, as well as the specific characteristics of the systems that are being developed. Therefore, even within the same organization, there can be many different processes for developing software.
The Unified Development Process (RUP) methodology outlines very specific guidelines for the development of software projects, defined in a highly collaborative, evolutionary and flexible approach to assimilate changes in software requirements in a dynamic business environment. Likewise, it clearly defines the milestones where formal project reviews are necessary, which include approval by the client. The diagram below shows the life cycle of a RUP-based software project:
Its evolutionary approach comprises an iterative and incremental development. The iterative nature is present in the activities located on the left side of the diagram (requirements, analysis, design, etc.); while incremental development is made by prototyping over time, developed throughout the life cycle, once for each prototype. During the Elaboration Phase a prototype is developed with the architecture that involves the use cases of greater technical risk. In turn, software is also produced at the end of each iteration in the Construction Phase, in the same way as in the Elaboration Phase, it can be used for testing purposes or demonstrative software for the client. Every time an iteration ends it marks a milestone where customer review is necessary,where the fulfillment of the requirements, the progress of the project, the analysis of the real and planned costs are analyzed. In the case of the last iteration corresponding to each phase of the project, the approval document must be created by the client, in which the client proposes his agreement with the developments achieved by the project, thus accepting the financial and technical sense of the software. that develops.
In the initial development stage (Concepción) the foundations of the project are created. The scope, the initial plan, the business vision with the goals and the justification of the project are defined, these artifacts are refined throughout the development of the project. Initial requirements are captured through use cases.
During this stage you start to think about the initial architecture of the system, from the business point of view and from the technical point of view. This process involves creating a conceptual model and a deployment model, both at a high level in this phase.
A high-level project plan is defined and then refined into a more detailed plan in subsequent iterations. The high-level plan handles core dependencies and overall strategy, while the more refined plans (corresponding to more detailed iterations) handle the tactics appropriate to the situations at hand in each iteration. Long-term actions such as operations, support and continuous improvement must be taken into account in project planning.
This conception phase ends ensuring the existence of a defined scope, development plan, risk analysis where customers agree with the above and having a viable strategy for the construction of the data warehouse.
There are some common mistakes that are made at this stage, you should avoid:
- Think that it is a phase of determining the requirements in a traditional way. Think that you need to have perfect models and plans. Try to create a complete data model at the beginning of the project.
Generated Artifacts:
- Project Plan Vision Use Cases Concept Diagram Deployment Diagram Customer approval document
The reasons why organizations use RUP for the development of software projects are:
- RUP controls scope risk: RUP recognizes as a fact that requirements change in project development and defines a flexible approach to control these requirements. Trying to define the requirements fully at the start of the project is a very risky decision. RUP looks beyond the data: one reason why software projects fail is to not provide enough business value. By identifying and focusing on business value through use cases, RUP gains a view of requirements, a preferable approach to a data-centric approach. RUP controls technical risk early: many software projects fail because of the confidence that They provide detailed models created early. If the data model is very detailed,It captures "the unique truth" and they have spent months working on it. The problem is that any architecture works well on paper. Until the architecture is tested with code, you cannot be sure of its correct operation. RUP controls the risk. Financial: The iterative and incremental development that early manages the critical components of a project ensures that the highest value of functionality is guaranteed first, maximizing the return on investment all the time. RUP allows agility in a disciplined way: software is difficult, flexibility is needed but at the same time maintaining a level of control to make development effective.Until the architecture is tested with code, you cannot be sure of its correct functioning. RUP controls financial risk: the iterative and incremental development that early manages the critical components of a project ensures that the highest value of functionality is guaranteed first maximizing return on investment all the time. RUP enables agility in a disciplined way: software projects are difficult, flexibility is needed but at the same time maintaining a level of control to make development effective.Until the architecture is tested with code, you cannot be sure of its correct functioning. RUP controls financial risk: the iterative and incremental development that early manages the critical components of a project ensures that the highest value of functionality is guaranteed first maximizing return on investment all the time. RUP enables agility in a disciplined way: software projects are difficult, flexibility is needed but at the same time maintaining a level of control to make development effective.Maximizing ROI all the time. RUP enables agility in a disciplined way: software projects are difficult, flexibility is needed but at the same time maintaining a level of control to make development effective.Maximizing ROI all the time. RUP enables agility in a disciplined way: software projects are difficult, flexibility is needed but at the same time maintaining a level of control to make development effective.
Changes in requirements demand an evolutionary and flexible high collaboration approach. The Unified Development Process (RUP) defines such an approach.
Bibliography
Ian Sommerville, " Software Engineering ", 6th Edition. Pearson Education, 2002.
I. Archer Pupo, “Phases of the Unified Development Process”.
