1.Rational Unified Process (RUP) is a software development process for object-oriented models.

It is
also known as the Unified Process Model. It is created by Rational corporation and is designed and
documented using UML (Unified Modeling Language). This process is included in IBM Rational
Method Composer (RMC) product. IBM (International Business Machine Corporation) allows us to
customize, design, and personalize the unified process. RUP is proposed by Ivar Jacobson, Grady
Bootch, and James Rambaugh. Some characteristics of RUP include use-case driven, Iterative
(repetition of the process), and Incremental (increase in value) by nature, delivered online using web
technology, can be customized or tailored in modular and electronic form, etc. RUP reduces
unexpected development costs and prevents wastage of resources.
Phases of RUP: There is total of five phases of the life cycle of RUP:
1. Inception –
 Communication and planning are the main ones.
 Identifies the scope of the project using a use-case model allowing managers to estimate
costs and time required.
 Customers’ requirements are identified and then it becomes easy to make a plan for the
project.
 The project plan, Project goal, risks, use-case model, and Project description, are made.
 The project is checked against the milestone criteria and if it couldn’t pass these criteria
then the project can be either canceled or redesigned.
2. Elaboration –
 Planning and modeling are the main ones.
 A detailed evaluation and development plan is carried out and diminishes the risks.
 Revise or redefine the use-case model (approx. 80%), business case, and risks.
 Again, checked against milestone criteria and if it couldn’t pass these criteria then again
project can be canceled or redesigned.
 Executable architecture baseline.
3. Construction –
 The project is developed and completed.
 System or source code is created and then testing is done.
 Coding takes place.
4. Transition –
 The final project is released to the public.
 Transit the project from development into production.
 Update project documentation.
 Beta testing is conducted.
 Defects are removed from the project based on feedback from the public.
5. Production –
 The final phase of the model.
 The project is maintained and updated accordingly.
Advantages:
1. It provides good documentation, it completes the process in itself.
2. It provides risk-management support.
3. It reuses the components, and hence total time duration is less.
4. Good online support is available in the form of tutorials and training.
Disadvantages:
1. Team of expert professional is required, as the process is complex.
2. Complex and not properly organized process.
3. More dependency on risk management..
2.Unified Modeling Language (UML)
It is a general purpose modelling language. The main aim of UML is to define a standard way
to visualize the way a system has been designed. It is quite similar to blueprints used in other fields
of engineering.
UML is not a programming language, it is rather a visual language. We use UML diagrams to portray
the behavior and structure of a system. UML helps software engineers, businessmen and system
architects with modelling, design and analysis. The Object Management Group (OMG) adopted
Unified Modelling Language as a standard in 1997. Its been managed by OMG ever since.
International Organization for Standardization (ISO) published UML as an approved standard in 2005.
UML has been revised over the years and is reviewed periodically.
Accordingly diagrams in UML are divided in three categories –
Structural Diagrams
Behavioural Diagrams
Interaction Diagrams

Structural UML Diagrams –

1.Class Diagram – The most widely use UML diagram is the class diagram. It is the building block of all
object oriented software systems. We use class diagrams to depict the static structure of a system by
showing system’s classes,their methods and attributes. Class diagrams also help us identify
relationship between different classes or objects.2.Object Diagram – An Object Diagram can be
referred to as a screenshot of the instances in a system and the relationship that exists between
them. Since object diagrams depict behaviour when objects have been instantiated, we are able to
study the behaviour of the system at a particular instant. An object diagram is similar to a class
diagram except it shows the instances of classes in the system.3.Component Diagram – Component
diagrams are used to represent how the physical components in a system have been organized. We
use them for modelling implementation details. Component Diagrams depict the structural
relationship between software system elements and help us in understanding if functional
requirements have been covered by planned development.4.Deployment Diagram – Deployment
Diagrams are used to represent system hardware and its software.It tells us what hardware
components exist and what software components run on them.We illustrate system architecture as
distribution of software artifacts over distributed targets. An artifact is the information that is
generated by system software. 5.Package Diagram – We use Package Diagrams to depict how
packages and their elements have been organized. A package diagram simply shows us the
dependencies between different packages and internal composition of packages. Packages help us to
organise UML diagrams into meaningful groups and make the diagram easy to understand.

Behavior Diagrams –

1.State Machine Diagrams – A state diagram is used to represent the condition of the system or part
of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior using
finite state transitions. State diagrams are also referred to as State machines and State-chart
Diagrams . These terms are often used interchangeably 2.Activity Diagrams – We use Activity
Diagrams to illustrate the flow of control in a system. We can also use an activity diagram to refer to
the steps involved in the execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity diagram. 3.Use Case
Diagrams – Use Case Diagrams are used to depict the functionality of a system or a part of a system.
They are widely used to illustrate the functional requirements of the system and its interaction with
external agents(actors). A use case is basically a diagram representing different scenarios where the
system can be used.

Interaction Diagram

1.Sequence Diagram – A sequence diagram simply depicts interaction between objects in a sequential
order i.e. the order in which these interactions take place.We can also use the terms event diagrams
or event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what
order the objects in a system function. 2.Collaboration Diagram- is used to show sequenced messages
exchanged between objects. A communication diagram focuses primarily on objects and their
relationships. We can represent similar information using Sequence diagrams,however,
communication diagrams represent objects and links in a free form. 3.Interaction Overview Diagram
– An Interaction Overview Diagram models a sequence of actions and helps us simplify complex
interactions into simpler occurrences. It is a mixture of activity and sequence diagrams.

3.SDLC Models

Waterfall Model

The waterfall is a universally accepted SDLC model. The waterfall model is a continuous software
development model in which development is seen as flowing steadily downwards (like a waterfall)
through the steps of requirements analysis, design, implementation, testing (validation), integration,
and maintenance. Linear ordering of activities has some significant consequences. First, to identify the
end of a phase and the beginning of the next, some certification techniques have to be employed at the
end of each step. Some verification and validation usually do this mean that will ensure that the output
of the stage is consistent with its input (which is the output of the previous step), and that the output of
the stage is consistent with the overall requirements of the system
Prototype Model

The prototyping model starts with the requirements gathering. The developer and the user meet and
define the purpose of the software, identify the needs, etc A 'quick design' is then created. This design
focuses on those aspects of the software that will be visible to the user. It then leads to the
development of a prototype. The customer then checks the prototype, and any modifications or changes
that are needed are made to the prototype. Looping takes place in this step, and better versions of the
prototype are created. These are continuously shown to the user so that any new changes can be
updated in the prototype. This process continue until the customer is satisfied with the system. Once a
user is satisfied, the prototype is converted to the actual system with all considerations for quality and
security.

RAD Model

RAD or Rapid Application Development process is an adoption of the waterfall model; it targets
developing software in a short period. The RAD model is based on the concept that a better system can
be developed in lesser time by using focus groups to gather system requirements.
Business Modeling ,Data Modeling ,Process Modeling ,Application Generation ,Testing and Turnover

Spiral Model

The spiral model is a risk-driven process model. This SDLC model helps the group to adopt elements of
one or more process models like a waterfall, incremental, waterfall, etc. Each cycle in the spiral begins
with the identification of objectives for that cycle, the different alternatives that are possible for
achieving the goals, and the constraints that exist. This is the first quadrant of the cycle (upper-left
quadrant).

The next step in the cycle is to evaluate these different alternatives based on the objectives and
constraints. The focus of evaluation in this step is based on the risk perception for the project.The next
step is to develop strategies that solve uncertainties and risks. This step may involve activities such as
benchmarking, simulation, and prototyping.
V-Model

V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC must
complete before the next phase starts. It follows a sequential design process same as the waterfall
model. Testing of the device is planned in parallel with a corresponding stage of development.

There are the various phases of Verification Phase of V-model:

Business requirement analysis: This is the first step where product requirements understood from the
customer's side. This phase contains detailed communication to understand customer's expectations
and exact requirements. System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements document. Architecture
Design: The baseline in selecting the architecture is that it should understand all which typically consists
of the list of modules, brief functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology detail, etc. Module Design: In the module design
phase, the system breaks down into small modules. The detailed design of the modules is specified,
which is known as Low-Level Design Coding Phase: After designing, the coding phase is started. Based
on the requirements, a suitable programming language is decided.

There are the various phases of Validation Phase of V-model:

Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase.
These UTPs are executed to eliminate errors at code level or unit level. Integration Testing: Integration
Test Plans are developed during the Architectural Design Phase. These tests verify that groups created
and tested independently can coexist and communicate among themselves. System Testing: System
Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans, System
Tests Plans are composed by the clients business team. Acceptance Testing: Acceptance testing is
related to the business requirement analysis part. It includes testing the software product in user
atmosphere.
4.Activity Diagram
In UML, the activity diagram is used to demonstrate the flow of control within the system rather than
the implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It put emphasis on
the condition of flow and the order in which it occurs. The flow can be sequential, branched, or
concurrent, and to deal with such kinds of flows, the activity diagram has come up with a fork, join, etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions

or operations that are applied to model the behavioral diagram.

Notation of an Activity diagram

Activity diagram constitutes following notations:

Initial State

It depicts the initial stage or beginning of the set of actions.

Final State:

It is the stage where all the control flows and object flows end.

Decision Box:

It makes sure that the control flow or object flow will follow only one path.

Action Box:

It represents the set of actions that are to be performed.

Action Flow

Action flows, also called edges and paths, illustrate the transitions from one
action state to another. They are usually drawn with an arrowed line

Activity diagram can be used for − Modeling work flow by using activities. Modeling business
requirements. High level understanding of the system's functionalities. Investigating business
requirements at a later stage

5.Use Case Diagram

Use Case diagram comes under behavioural modelling. It is the diagram from which designing of the
system starts. Designing of the system starts in inception phase itself and always it starts with use case
diagram. It is the primary form of system/software requirements for a new software program
underdeveloped. A key concept of use case modeling is that it helps us design a system from the end
user's perspective. It is an effective technique for communicating system behaviour in the user's terms
by specifying all externally visible system behaviour. The diagram is used to model the
system/subsystem of an application. A single use case diagram captures a particular functionality of a
system. Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements

the purposes of use case diagrams can be said to be as follows − Used to gather the requirements of a
system. Used to get an outside view of a system. Identify the external and internal factors influencing
the system. Show the interaction among the requirements are actors.

Use Case

A use case represents a user goal that can be achieved by accessing the system or software application.

Association

Actor and use case can be associated to indicate that the actor participates in that use case.

Actor
Actors are the entities that interact with a system. Although in most cases, actors are used to represent
the users of system, actors can actually be anything that needs to exchange information with the
system.

System

The scope of a system can be represented by a system (shape), or sometimes known as a system
boundary. The use cases of the system are placed inside the system shape, while the actor who interact
with the system are put outside the system.

Include

An include relationship specifies how the behavior for the inclusion use case is inserted into the
behavior defined for the base use case.

Extend

An extend relationship specifies how the behavior of the extension use case can be inserted into the
behavior defined for the base use case.