BULE HORA UNIVERSITY

COLLAGE OF INFORMATICS

DEPARTMENT OF COMPUTER SIENCE

Individual assignment for the course software engineering

PREPARED BY: NUHAMIN MIHRETU

ID: RU5046/13

SUBMITTED TO: [Link] H.

SUBMISSION DATE:
 1. List and explain software development models with their diagrams

There are various Software development models or methodologies. Some of them are
discussed as follows:

1. Waterfall model
2. V model
3. Incremental model
4. RAD model
5. Agile model
6. Iterative model
7. Spiral model
8. Prototype model

1.1 Waterfall model

The waterfall model gets its name from the fact that the first diagrams of this process illustrated
it as a series of terraces over which a stream flowed, cascading down from one level to another.
The point of this portrayal was that water always flows downhill — it can‘t reverse itself.
Similarly, the defining characteristic of the waterfall model is the irreversible forward progress
from phase to phase.

Waterfall model is One of the earliest software development models. In ‗Waterfall Model‘
testing starts only after the development is completed. Because of which there are many defects
and failures which are reported at the end. So, the cost of fixing these issues is high. Hence, these
days people are preferring ‗Agile Model‘. In ‗Agile Model‘ after every sprint there is a demo-
able feature to the customer. Hence customer can see the features whether they are satisfying
their need or not.

Advantages of waterfall model

 This model is simple and easy to understand and use.

 It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 In this model phases are processed and completed one at a time. Phases do not overlap.
 Waterfall model works well for smaller projects where requirements are clearly defined
and very well understood.

Disadvantages of waterfall model

 Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing.

When to use the waterfall model

 This model is used only when the requirements are very well known, clear and
fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.
1.2 V model

The V-model is another linear model with each stage having a corresponding testing activity.
Such workflow organization implies exceptional quality control, but at the same time, it makes
the V-model one of the most expensive and time-consuming models. Moreover, even though
mistakes in requirements specifications, code and architecture errors can be detected early,
changes during development are still expensive and difficult to implement. As in the Waterfall
case, all requirements are gathered at the start and cannot be changed.

Advantages of V-model:

 Simple and easy to use.

 Testing activities like planning, test designing happens well before coding. This saves a
lot of time. Hence higher chance of success over the waterfall model.
 Proactive defect tracking – that is defects are found at early stage.
 Avoids the downward flow of the defects.
 Works well for small projects where requirements are easily understood.

Disadvantages of V-model
  Very rigid and least flexible.
 Software is developed during the implementation phase, so no early prototypes of the
software are produced.
 If any changes happen in midway, then the test documents along with requirement
documents has to be updated.

When to use the V-model?

 The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
 The V-Shaped model should be chosen when technical requisites such as technical
resources and technical experts are available at-hand.
 When developed system failures are acceptable.

1.3 Incremental model

In incremental model the whole requirement is divided into various builds. Multiple
development cycles take place here, making the life cycle a ―multi-waterfall‖ cycle. Cycles are
divided up into smaller, more easily managed modules You basically have a methodology where
you are cycling through the four phases of requirements, design, coding, and testing to form one
increment. Each of those increments will then act as a part of each other, adding functions and
features until you finally get the product that you need. This makes it more tedious than most
other software development models, but it also provides more control.

Advantages of Incremental model:

 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during it‘d
iteration.

Disadvantages of Incremental model:

 Needs good planning and design.

 Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
 Total cost is higher than waterfall.

When to use the Incremental model:

 This model can be used when the requirements of the complete system are clearly defined
and understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.
1.4 Iterative model

An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which can
then be reviewed in order to identify further requirements. This process is then repeated,
producing a new version of the software for each cycle of the model.

Advantages of Iterative model:

 In iterative model we can only create a high-level design of the application before we
actually begin to build the product and define the design solution for the entire product.
Later on we can design and built a skeleton version of that, and then evolved the design
based on what had been built.
 In iterative model we are building and improving the product step by step. Hence we can
track the defects at early stages. This avoids the downward flow of the defects.
 In iterative model we can get the reliable user feedback. When presenting sketches and
blueprints of the product to users for their feedback, we are effectively asking them to
imagine how the product will work.
 In iterative model less time is spent on documenting and more time is given for
designing.

Disadvantages of Iterative model:

 Each phase of an iteration is rigid with no overlaps

  Costly system architecture or design issues may arise because not all requirements are
gathered up front for the entire lifecycle

When to use iterative model:

 Requirements of the complete system are clearly defined and understood.

 When the project is big.
 Major requirements must be defined; however, some details can evolve with tim e.

1.5 RAD Model

RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype without
any specific planning. In RAD model, there is less attention paid to the planning and more
priority is given to the development tasks. It targets at developing software in a short span of
time.

Advantages of the RAD model:

  Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

 Depends on strong team and individual performances for identifying business

requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.

When to use RAD model:

 RAD should be used when there is a need to create a system that can be modularized in
2-3 months of time.
 It should be used if there‘s high availability of designers for modeling and the budget is
high enough to afford their cost along with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).
1.6 Agile model

The most widely used software development model in the industry due to the fact that it is an
incredibly dynamic and flexible project management process. Regardless of how many people
are working on the project, it is easy for collaboration to be conducted simply because of how
easy it is to adapt to the changes brought about by the market or the customers. The agile
approach to software development aims to provide functioning software systems in a short
amount of time.

Agile methodology is a practice which promotes continues interaction of development and

testing during the SDLC process of any project. In the Agile method, the entire project is divided
into small incremental builds. All of these builds are provided in iterations, and each iteration
lasts from one to three weeks.

Advantages of Agile model:

 Customer satisfaction by rapid, continuous delivery of useful software.

 People and interactions are emphasized rather than process and tools. Customers,
developers and testers constantly interact with each other.
 Working software is delivered frequently (weeks rather than months).
 Face-to-face conversation is the best form of communication.
  Close, daily cooperation between business people and developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages of Agile model:

 In case of some software deliverables, especially the large ones, it is difficult to assess the
effort required at the beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not clear what
final outcome that they want.
 Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined
with experienced resources.

When to use Agile model:

 When new changes are needed to be implemented. The freedom agile gives to change is
very important. New changes can be implemented at very little cost because of the
frequency of new increments that are produced.
 To implement a new feature the developers need to lose only the work of a few days, or
even only hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required to get started
with the project. Agile assumes that the end users‘ needs are ever changing in a dynamic
business and IT world. Changes can be discussed and features can be newly effected or
removed based on feedback. This effectively gives the customer the finished system they
want or need.
 Both system developers and stakeholders alike, find they also get more freedom of time
and options than if the software was developed in a more rigid sequential way. Having
options gives them the ability to leave important decisions until more or better data or
even entire hosting programs are available; meaning the project can continue to move
forward without fear of reaching a sudden standstill.
1.7 Spiral model

The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements is
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. This is the
model where intensive customer involvement appears. They can be involved in the exploration
and review stages of each cycle. At the development stage, the customer‘s amendments are not
acceptable.

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.

 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

Disadvantages of Spiral model:

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
  Project‘s success is highly dependent on the risk analysis phase.
 Doesn‘t work well for smaller projects.

When to use Spiral model:

 When costs and risk evaluation is important

 For medium to high-risk projects
 Long-term project commitment unwise because of potential changes to economic
priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)

1.8 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. When creating a software or
application, it‘s typical to use a prototype model to offer an earlier and functioning version that
can be used as a presentation or sample of the project.
Prototyping is a great way to receive input on requirements, functionality, and operability, so that
the final development of the product may go along more quickly and efficiently.
Advantages of the prototyping model:
 Customers get a say in the product early on, increasing customer satisfaction.
 Missing functionality and errors are detected easily.
 Prototypes can be reused in future, more complicated projects.
 It emphasizes team communication and flexible design practices.
 Users have a better understanding of how the product works.
 Quicker customer feedback provides a better idea of customer needs.

Disadvantages of the prototyping model:

The main disadvantage of this methodology is that it is more costly in terms of time and money
when compared to alternative development methods, such as the spiral or Waterfall model. Since
in most cases the prototype is discarded, some companies may not see the value in taking this
approach.

When to use prototyping model:

The Prototyping Model should be used when the requirements of the product are not clearly
understood or are unstable. It can also be used if requirements are changing quickly.

2. List and explain UML with its diagram

The current UML standards call for 14 different types of diagrams: class, activity, object, use
case, sequence, package, state, component, communication, composite structure, interaction
overview, timing, and deployment.

These diagrams are organized into two distinct groups: structural diagrams and behavioral or
interaction diagrams.
Structural UML diagrams
 Class diagram
 Package diagram
 Object diagram
 Component diagram
 Composite structure diagram
 Deployment diagram
 Profile Diagram
Behavioral UML diagrams
 Activity diagram
  Sequence diagram
 Use case diagram
 State diagram
 Communication diagram
 Interaction overview diagram
 Timing diagram

2.1 Class Diagram

Class diagrams are the most common diagrams used in UML. Class diagram consists of classes,
interfaces, associations, and collaboration. Class diagrams basically represent the object-oriented
view of a system, which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. Hence, it is generally used for
development purpose. This is the most widely used diagram at the time of system construction.
Class diagram example:
2.2 Package Diagram

Package diagrams are a subset of class diagrams, but developers sometimes treat them as a
separate technique. Package diagrams organize elements of a system into related groups to
minimize dependencies between packages.
Package diagram example:
2.3 Object Diagram
An object diagram is a graph of instances, including objects and data values. A static object
diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system
at a point in time. The difference is that a class diagram represents an abstract model consisting
of classes and their relationships. However, an object diagram represents an instance at a
particular moment, which is concrete in nature. The use of object diagrams is fairly limited,
namely to show examples of data structure.
2.4 Component Diagram
Component diagrams represent a set of components and their relationships. These components
consist of classes, interfaces, or collaborations. Component diagrams represent the
implementation view of a system.
During the design phase, software artifacts (classes, interfaces, etc.) of a system are arranged in
different groups depending upon their relationship. Now, these groups are known as components.
Finally, it can be said component diagrams are used to visualize the implementation.

2.5 Deployment Diagram

The Deployment Diagram helps to model the physical aspect of an Object-Oriented software
system. It is a structure diagram which shows architecture of the system as deployment
(distribution) of software artifacts to deployment targets. Artifacts represent concrete elements
in the physical world that are the result of a development process. It models the run-time
configuration in a static view and visualizes the distribution of artifacts in an application. In
most cases, it involves modeling the hardware configurations together with the software
component lived on.
2.6 Composite Structure

A composite structure diagram is similar to a class diagram and is a kind of component

diagram mainly used in modeling a system at micro point-of-view, but it depicts individual
parts instead of whole classes. It is a type of static structure diagram that shows the internal
structure of a class and the collaborations that this structure makes possible.
This diagram can include internal parts, ports through which the parts interact with each other
or through which instances of the class interact with the parts and with the outside world, and
connectors between parts or ports. A composite structure is a set of interconnected elements
that collaborate at runtime to achieve some purpose. Each element has some defined role in the
collaboration.
2.7 Activity diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. It describes the flow of control of the target
system, such as the exploring complex business rules and operations, describing the use case
also the business process. In the Unified Modeling Language, activity diagrams are intended to
model both computational and organizational processes
2.8 Profile Diagram

Profile diagram is a new diagram type introduced in UML 2. This is a diagram type that is very
rarely used in any specification. For more profile diagram templates, visit our diagram
community.
2.9 Use Case Diagram
As the most known diagram type of the behavioral UML types, Use case diagrams give a
graphic overview of the actors involved in a system, different functions needed by those actors
and how these different functions interact.

It‘s a great starting point for any project discussion because you can easily identify the main
actors involved and the main processes of the system. You can create use case diagrams using
our tool and/or get started instantly using our use case templates.

Use Case Diagram Relationships Explained with examples

2.10 Sequence Diagram
Sequence diagrams in UML show how objects interact with each other and the order those
interactions occur. It‘s important to note that they show the interactions for a particular
scenario. The processes are represented vertically and interactions are shown as arrows. This
article explains the purpose and the basics of Sequence diagrams. Also, check out this
complete Sequence Diagram Tutorial to learn more about sequence diagrams.

You can also instantly start drawing using our sequence diagram templates.
2.11 Communication Diagram
In UML 1 they were called collaboration diagrams. Communication diagrams are similar to
sequence diagrams, but the focus is on messages passed between objects. The same
information can be represented using a sequence diagram and different objects.

Example of communication diagram.

2.12 Interaction Overview Diagram

Interaction overview diagrams are very similar to activity diagrams. While activity diagrams
show a sequence of processes, Interaction overview diagrams show a sequence of interaction
diagrams.
They are a collection of interaction diagrams and the order they happen. As mentioned before,
there are seven types of interaction diagrams, so any one of them can be a node in an
interaction overview diagram.
2.13 Timing Diagram
Timing diagrams are very similar to sequence diagrams. They represent the behavior of objects
in a given time frame. If it‘s only one object, the diagram is straightforward. But, if there is
more than one object is involved, a Timing diagram is used to show interactions between
objects during that time frame.

2.14 State Machine Diagram

State machine diagrams are similar to activity diagrams, although notations and usage change a
bit. They are sometimes known as state diagrams or state chart diagrams as well. These are
very useful to describe the behavior of objects that act differently according to the state they
are in at the moment. The State machine diagram below shows the basic states and actions.