1. Size of software delivered is measured independently of Language, technology, and tools.
2. Functional Points F.P are directly estimated from requirements, before design and coding
3. We get an estimate of SW size even before major design or coding happens (early phases)
4. Any change in requirements can be easily reflected in the Functional Points FP count.
5. Useful even for those users without technical expertise.
6. F.P. is biased on the external structure of the software to develop.

The project can be late due to different factors. Some of the main reasons for late project are as follows:

Project scheduling is key to a projects success!

The topic that we are going to cover:

1. What is a Rational Unified Process (RUP)?
2. Phases of the RUP methodology and its sub-tasks.
3. How does the RUP methodology work?
4. Advantages and Disadvantages of RUP methodology

Software Engineering is an organized approach to the design, development, operation, and maintenance of the software system. The objectives of Software Engineering are Maintainability, Correctness, Reusability, Testability, Reliability, Portability, and Adaptability.

GA

As a software engineer, establishing a good and efficient system needs more practice and more effort into it. Always keep in mind that until and unless, there is no proper process in the system, there is always a risk of project failure, and there will always temporary solutions. So the first job of the software engineer is to make a good system. To make a good and efficient system, software development methodology should be chosen based on the client’s requirement and the Client’s nature. There are different kinds of software development methodologies.

Among this list of methodologies, RUP is one of the most popular and effective methodologies for software development.

1. Inception: It is the initial phase of the developing process. Essentially, in this phase, your team determines the structure and the basic idea of the project. Also, the team will decide the purpose of the project, success criteria, estimated cost, risk assessment, scheduled time, and resources required to complete it, etc. It is just like an evaluation of the project.

The conclusions of the inception phase are:

• It provides a general vision project initiative document with multiple parameters.
• We get the project scope with the initial project model.
• An initial business suite with financial analysis.
• A project plan with different phases with a business model.
• Requirement understanding.
• Actual expenditures versus planned expenditures.

The major tasks involved in the Inception are as follows:

1. Scheduling Resources
2. Cost and Time Estimation
3. Planning
4. Risk Management
5. Prototypes Development

2. Elaboration: This is the second phase of the development process. The project’s architecture and required resources are further evaluated. This phase aims to analyze the requirements and the architecture of the system, develop the project plan, and eliminate the highest risk elements of the project. It’s undoubtedly the most critical of all stages as it signifies the transition from low-risk to high-risk. It’s also the point when your team has to decide whether to start construction (development and coding) or not.

The conclusions of the Elaboration phase are:

• It provides a full model of the project with functional and non-functional requirements.
• It provides a full Software Architecture Description.
• It provides the stability of the project, like the vision of the product & architecture of the product stable or not?
• Similarly, the project plan be approved or not?
• Is the actual resource cost versus planned resource cost acceptable or not?

The major tasks involved in the Elaboration are as follows:

1. Analysis of the problem domain
2. Use Case Diagram Development
3. System Architecture Development

3. Construction: This is the third phase of the development process. At this stage, your team is finally ready to develop all components and features and integrate them into the product. It’s a manufacturing process where your team focuses on managing resources to optimize costs, schedules, and quality. The software is designed, written, and tested successfully.

The conclusions of the Construction phase are:

• The software product is integrated into different modules.
• It provides a user manual.
• Is the product release stable or not?
• Does it meet client requirements or not?
• Is the actual resource cost versus planned resource cost acceptable or not?

The major tasks involved in the Construction are as follows:

1. System Build
2. System Operational Manual
3. User Manual
4. Test Cases

4. Transition: This is the last phase of the development process. The transition phase is the moment when the product is finally finished, released, and delivered to customers. However, once the product is given to the user, several issues can arise. This requires the team to handle all the bug fixes and correct problems or to finish some features that were postponed. It is the process of deployment.

The conclusions of the Transition phase are:

• It is one type of beta testing to validate the product as per user expectations.
• It allows the end-user to be satisfied or not.
• All types of training manuals for the user.

The major tasks involved in the Transition Phase are as follow:

1. Training
2. Beta Testing
3. Analysis of User Review
4. Supporting & maintaining product

The benefits of RUP:

• It allows you to deal with changing requirements regardless of whether they are coming from the customer or from the project itself
• It emphasizes the need for accurate documentation.
• It forces integration to happen throughout the software development, more specifically in the construction phase.
• It allows us to deal with changing requirements within the development life cycle of the project as per the client or customer needs i.e. it welcomes change.
• It supports incremental build of the software product.
• It provides proper documentation of the software product.
• It helps to use the resources efficiently.
• It helps to identify issues early in the process life cycle.
• It improves process control and risk management.
• It enhances team productivity. It allows you to deal with changing requirements regardless of whether they are coming from the customer or from the project itself.
• It emphasizes the need for accurate documentation.
• It forces integration to happen throughout the software development, more specifically in the construction phase.
• It helps reduce unexpected development costs.

The disadvantages of RUP:

• It mostly relies on the ability of experts and professionals to assign the activities to individuals who should then produce pre-planned results in the form of artifacts.
• The integration in the development process can also have an adverse impact on some more fundamental activities during the stages of testing
• Although RUP has delivered excellent results, especially in software development, it is a rather complex method which makes its implementation challenging, particularly for smaller businesses, teams, or projects.
• It is a complex model to implement as it has multiple stages of the workflow.
• It is challenging for organizations to implement which has, a small team size or projects.
• It should be highly result-oriented for individuals or teams.
• It emphasizes the integration of modules throughout the development process of software, so this creates trouble during the testing phase.

The Activity Diagram is another important diagram in UML to describe the dynamic aspects of the system. The Activity Diagram is a flowchart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. The control flow is drawn from one operation to another. This flow can be sequential, branched, or concurrent. Activity diagrams deal with all types of flow control by using different elements such as fork, join, etc.

It does not show any message flow from one activity to another. The Activity Diagram is sometimes considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows different flows such as parallel, branched, concurrent, and single.
The purpose of an activity diagram can be described as
Draw the activity flow of a system.
Describe the sequence from one activity to another.
Describe the parallel, branched, and concurrent flow of the system.

How to Draw an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities performed by the system. Activity diagrams are not exactly flowcharts as they have some additional capabilities. These additional capabilities include branching, parallel flow, swim lane, etc.

Before drawing an activity diagram, we must have a clear understanding of the elements used in the activity diagram. The main element of an activity diagram is the activity itself. An activity is a function performed by the system. After identifying the activities, we need to understand how they are associated with constraints and conditions.
Before drawing an activity diagram, we should identify the following elements
Activities
Association
Conditions
Constraints

Once the above-mentioned parameters are identified, we need to make a mental layout of the entire flow. This mental layout is then transformed into an activity diagram.

Following is an example of an activity diagram for the order management system. In the diagram, four activities are identified which are associated with conditions. One important point should be clearly understood an activity diagram cannot be exactly matched with the code. The activity diagram is made to understand the flow of activities and is mainly used by business users
The following diagram is drawn with the four main activities
Send order by the customer
Receipt of the order
Confirm the order
Dispatch the order
After receiving the order request, condition checks are performed to check if it is a normal or special order. After the type of order is identified, dispatch activity is performed and that is marked as the termination of the process.

Where to Use Activity Diagrams?

The basic usage of the activity diagram is similar to the other four UML diagrams. The specific usage is to model the control flow from one activity to another. This control flow does not include messages.

The Activity Diagram is suitable for modeling the activity flow of the system. An application can have multiple systems. The Activity Diagram also captures these systems and describes the flow from one system to another. This specific usage is not available in other diagrams. These systems can be databases, external queues, or any other system.

We will now look into the practical applications of the activity diagram. From the above discussion, it is clear that an activity diagram is drawn from a very high level. So it gives a high-level view of a system. This high-level view is mainly for business users or any other person who is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. The diagram has more impact on business understanding rather than on implementation details.
Activity diagram can be used for
Modeling workflow by using activities.
Modeling business requirements.
High-level understanding of the system’s functionalities.
Investigating business requirements at a later stage.

1. Check if there are any non-functional requirements in Use Cases.
2. Check the use case names properly whether it’s an active verb and a noun phrase or not.
3. Check whether all the use cases are inside the system box or not.
4. Check whether the use cases are in logical order or not.
5. Check if there is any overlap and can be fixed by repositioning the use cases or actors.

GA

1. Check whether the use case diagram contains at least one included relationship or not.
2. Check whether there is a line between the actors and the Included Use Cases.
3. Check Whether the include relationship arrow is pointed to Included Use Case or not and if the arrow is labeled with include or not.
4. Check whether the use case diagram contains at least one extended relationship or not.
5. Check whether there is a line between the actors and the Extended Use Cases.
6. Check whether extend relationship arrow is pointed to Base Use Case or not and is arrow labeled with extend or not.
7. Check whether more than one base use case extends or includes the same extended or included use case carefully.
8. Check whether the use case diagram contains any generalizations or not.
9. Check whether the arrow is a solid line with an arrow pointing towards parents actor or parents use case or not. Also, confirm that it doesn’t exist label in the arrow.
10. If possible, show at least one extension point in the use case diagram.   

Ga

9. Make sure to represent all actors with a human stick image even for the machine, and external devices, and also contains at least more than one actor in the use case diagram.
10. Check whether primary actors are shown on the left side or not. Similarly, secondary actors are on the right side or not. 
11. Check if is there any automatic job doing use cases in the system.
12. Make sure there is only one rectangle box representing a system where all the use cases are included inside the box and actors are outside of the box.
13. Check whether you have written the system name inside the box at the top or not.