LECTURE 2
SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)
DINF 0122 & DCS 0122 :SYSTEM ANALYSIS AND
DESIGN
COURSE INSTRUCTOR: Akram Ali Omar
Email: akram.ali.omar@gmail.com
Mobile: +255778695626
The State University Of Zanzibar
1
What is the System Development Cycle?
• Structured step-by-step approach for developing information
systems
• It describe the process of planning, building, using, and updating
an information system.
• Provides overall framework for managing systems development
process
2
Phases of SDLC
3
Phases of SDLC
• Project planning – initiate, ensure feasibility, plan schedule, obtain
approval for project
• Analysis – understand business needs and processing requirements
• Design – define solution system based on requirements and analysis
decisions
• Implementation – construct, test, train users, and install new system
• Support – keep system running and improve
4
SDLC Models
• The followings are most common SDLC Models:
–
–
–
–
–
–
–
–
Waterfall Model
Iterative Model
Spiral Model
V – model
Prototyping Models
Agile Model
Big Bang Model
Rapid Application Development
5
Waterfall Model
• All the phases of SDLC will function one after another in linear manner
– Each phase must be completed fully before the next phase can begin
• In this model software testing starts only after the development is complete.
• In waterfall model phases do not overlap
6
Waterfall Model
• Requirement Gathering and analysis
 All possible requirements of the system to be developed are captured in
this phase and documented in a requirement specification document
• System Design
 The requirement specifications from first phase are studied in this phase
and the system design is prepared.
 This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture
7
Waterfall Model
• Implementation
 With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase.
 Each unit is developed and tested for its functionality, which is referred to
as Unit Testing
• Integration and Testing
 All the units developed in the implementation phase are integrated into a
system after testing of each unit.
 Finally after integration the entire system is tested for any faults and
failures.
8
Waterfall Model
• Maintenance
 There are some issues which come up in the client environment.
 To fix those issues, patches are released.
 Also to enhance the product some better versions are released
9
When to use Waterfall Model?
• Some situations where the use of Waterfall model is most appropriate are
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 The project is short.
10
Advantages of waterfall model
• Easy to explain to the user
• Stages and activities are well defined
• Helps to plan and schedule the project
• Verification at each stage ensures early detection of errors /
misunderstanding
11
Disadvantages of waterfall model
• 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. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Customers can not use anything until the entire system is complete
12
Project Output in a Waterfall Model
• Requirement document
• Project plan
• System design document
• Detailed design document
• Test plan and test report
• Final code
• Software manuals (user manual, installation manual etc.)
• Review reports
13
Prototyping model
• Prototyping model is one of the risk reduction models
• It involves building a small version of the intended system called
prototype
• Instead of freezing the requirements before a design or coding can proceed,
small version (called prototype) of the intended system is developed based
on the currently known requirements
• The client can get an “actual feel” of the system, since the interactions with
prototype can enable the client to better understand the requirements of the
desired system
14
Prototyping model
15
Advantages of Prototype model
• Users are actively involved in the development
• The users get a better understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
• Requirements validation, Quick implementation of incomplete but
functional application.
16
Disadvantages of Prototype model
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the
full system was designed
• Incomplete or inadequate problem analysis.
17
When to use Prototype model
• When the desired system needs to have a lot of interaction with the end
users.
• Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model
18
V- model
• V- model means Verification and Validation model
• Just like the waterfall model, the V-Shaped life cycle is a sequential path of
execution of processes
• Testing of the product is planned in parallel with a corresponding phase of
development in V-model
19
V- model
20
V- model phases
• BRS and SRS
 Before development is started, a system test plan is created
• The high-level design (HLD)
 focuses on system architecture and design
 An integration test plan is created in this phase as well in order to test the
pieces of the software systems ability to work together.
• The low-level design (LLD)
 Actual software components are designed
 It defines the actual logic for each and every component of the system.
 Class diagram with all the methods and relation between classes comes
under LLD.
 Component tests are created in this phase as well.
21
V- model phases
• Coding
 This is at the bottom of the V-Shape model.
 Module design is converted into code by developers.
 Unit Testing is performed by the developers on the code written by them
•
This is at the bottom of the V-Shape model. Module design is converted
into code by developers.
•
Unit Testing is performed by the developers on the code written by them
22
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
23
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.
24
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 sample technical resources are
available with needed technical expertise.
Note:
High confidence of customer is required for choosing the V-Shaped model
approach. Since, no prototypes are produced, there is a very high risk
involved in meeting customer expectations.
25
Incremental model
•
•
•
•
•
•
•
•
The whole requirement is divided into various builds
Multiple development (“multi-waterfall”) cycles take place here
Cycles are divided up into smaller, more easily managed modules
Each module passes through the requirements, design, implementation and
testing phases
A working version of software is produced during the first module
Each subsequent release of the module adds function to the previous
release.
The process continues till the complete system is achieved.
For example
26
Incremental model
27
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’s 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
Spiral model
•
Is similar to the incremental model
•
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)
Spiral model
Spiral model
•
Planning Phase
 Requirements are gathered during the planning phase
•
Risk Analysis
 Process is undertaken to identify risk and alternate solutions
 A prototype is produced at the end of the risk analysis phase.
 If any risk is found during the risk analysis then alternate solutions are
suggested and implemented.
• Engineering Phase
 software is developed, along with testing at the end of the phase
• Evaluation phase
 The customer evaluates the output of the project to date before the project
continues to the next spiral
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
•
Significant changes are expected (research and exploration)
Agile development model
• Is also a type of Incremental model
• Breaks tasks into small increments with minimal planning
• Iterations are short time frames that typically last from one to four weeks
• Each iteration involves planning, requirements analysis, design, coding, unit
testing, and acceptance testing
• At the end of the iteration a working product is demonstrated to
stakeholders
37
Agile development model
38
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.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed
39
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.
40
Iterative model
• Does not attempt to start with a full specification of requirements.
• Development begins by specifying and implementing just part of the
software
• The new version is 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.
• Example of iterative model:
41
Diagram of Iterative model
42
Advantages of Iterative model
• Generating working software quickly and early during the software
life cycle
• More flexible – less cost to change scope and requirement
• Easier to test and debugging during smaller iteration
• Easier to manage risk because risky pieces are identified and
handled during its iteration
43
Disadvantages of Iterative model
• Each phase of an iteration is rigid and do not overlap each other
• System architecture my not be optimal because not all requirements
are gathered up front for the entire software life cycle
44
Choosing the right Software development life
cycle model
• Selecting the right SDLC is a process in itself that organization can
implement internally or consult for
45
Choosing the right Software development life
cycle model
• Selecting the right SDLC is a process in itself that organization can
implement internally or consult for
• There are some steps to get the right selection.
 STEP 1: Learn the about SDLC Models - already covered
 STEP 2: Assess the needs of Stakeholders
 STEP 3: Define the criteria
 STEP 4: Decide
46
STEP 2: Assess the needs of Stakeholders
• We must study the business domain, stakeholders concerns and
requirements, business priorities, our technical capability and ability, and
technology constraints to be able to choose the right SDLC against their
selection criteria.
47
STEP 3: Define the criteria
• Some of the selection criteria or arguments that you may use to select an
SDLC are:
 Is the SDLC suitable for the size of our team and their skills?
 Is the SDLC suitable for the selected technology we use for
implementing the solution?
 Is the SDLC suitable for client and stakeholders concerns and priorities?
 Is the SDLC suitable for the geographical situation (distributed team)?
 Is the SDLC suitable for the size and complexity of our software?
 Is the SDLC suitable for the type of projects we do?
 Is the SDLC suitable for our software engineering capability?
48
Some Recommended criteria
Factors
Waterfall V-Shaped Prototyping
Spiral
Iterative &
Incremental Agile
Unclear User Requirement
Poor
Poor
Good
Excellent
Good
Excellent
Unfamiliar Technology
Poor
Poor
Excellent
Excellent
Good
Poor
Complex System
Good
Good
Excellent
Excellent
Good
Poor
Reliable system
Good
Good
Poor
Excellent
Good
Good
Short Time Schedule
Poor
Poor
Good
Poor
Excellent
Excellent
Strong Project Management
Excellent
Excellent
Excellent
Excellent
Excellent
Excellent
Cost limitation
Poor
Poor
Poor
Poor
Excellent
Excellent
Visibility of Stakeholders
Good
Good
Excellent
Excellent
Good
Excellent
Skills limitation
Good
Good
Poor
Poor
Good
Poor
Documentation
Excellent
Excellent
Good
Good
Excellent
Poor
Component reusability
Excellent
Excellent
Poor
Poor
Excellent
Poor
49
Software Development Approaches to SDLC
• Two common approaches in software development
1. Traditional Approach(structured approach)
2. object-oriented (OO) approach
50
Traditional Approach(structured approach)
• It adopts a formal step-by-step approach to the SDLC phases and activities
• The activities of one phase must be completed before moving to the next
phase
• At the completion of each activity or phase, a document is produced that
must be approved by the stakeholders before moving to the next activity or
phase.
• This is necessary as teams of developers with varying skills and
responsibilities
51
Traditional Approach(structured approach)
• The structured approach looks at a system from a top-down view
• The center of the structured approach is the process model, which depicts
the business processes of a system, and the primary model that presents the
processes is the data-flow diagram (DFD)
52
Structured approach to SDLC (Waterfall Model)
• The activities of the software development process represented in
the waterfall model.
• There are several other models to represent this process.
53
The Object-Oriented Approach
• It is a new way of thinking about problems using models based on
real world concepts
• The object-oriented methodology views a system as a bottom-up
approach to systems development.
• The basic construct is object which combines both data structure
and behavior in a single entity
54
The Object-Oriented Approach
• Analysis model is built to abstract essential aspects of application domain
which contains objects found in application, their properties and behavior.
• Then design model is made to describe and optimize the implementation.
• Finally the design model is implemented in a programming language,
database or hardware.
• Graphical notation is used for expressing object-oriented models.
55
Concept of object in a real world
• Before asking ‘what is an object in computer programming?’ ask ‘what
is an object in a real world?’
• In a real world
 Object is any thing
 Object examples
car
mango
cat
cup
 Objects are separate from one another
 They have their own existence and identity
56
desk
Concept of object in a real world
• Objects might contain other objects
• Objects have properties that describe them called attributes
• For examples colors, size, name, age, etc.
• State of one object is independent of another
• Object have behavior and it is specific to the type of object. For
examples
 A cat can walk
 A car can start
57
 A dog can eat. Etc.
Concept of object in a computer
programming
• The same three things (identity, attribute, and behavior) describe the object
in computer programming
• In a real world we describe object for things that can be seen and touch
• But in a computer programming we also have real world objects like house,
cat, car.etc.
• But also have abstract objects for things that can not be seen and touch like
bank account, meeting, course, etc
• Abstract
objects also have identity, attribute, and behavior
58
What is a class
• The entire point in object oriented design is not about objects, it is
about class
• We use classes to create objects
• Class describes what an object will be
• Class is not an object, it is a blue print or the definition of object
• In object oriented we create a class first, then we use a class to create
an object
59
What is a class
• For example if you want to build a house you create blue print first
• This blue print describe everything about how the house will be but it is
not the house
• Then use that blue print to build the house
60
What is a class
• Then use that blue print to build the house
• We can use the same blue print to build many houses
• This means we can define the class once and then create a thousand
objects using the same class
61
Creating class
• Name(type): what is it?
 Employee, BankAccount, Event, Document, Student
• Attributes(properties): what describe it?
 Width, Color, RegistrationNumber, Length, Etc
• Behavior(operations): What can it do
 Play, open search. Walk, save, create, etc.
62
Object - Orientation
• The term object-oriented (OO) means that we organize software as a
collection of discrete objects that incorporate both data structure and
behavior.
• Includes the following concepts:
 Abstraction
 Polymorphism
 Encapsulation
 Inheritance
63
Abstraction
• Abstraction means we focus on essential quality of something rather than
one specific example
• For example: if we say table we didn’t specify whether it is a wooden table
or class table or three legs table, we just say the idea or abstraction of a table
• In a previous example of bank account class we didn’t create beank account
class for each objects, we just create one bank account class
64
Encapsulation
• Enclosing attributes and behaviors of the class together as a single unit
• Not only enclosing the content together but also to protect those content
• It involve restricting direct access of details(attributes) of a class, this is
referred to as data hiding
65
Inheritance
• Inheritance involves code reuse
• When you create a new class, instead of writing from scratch we can
base on existing class
Supperclass
(parent class)
Subclass
(child class)
Customer inherit from person
66
Polymorphism
• Polymorphism means many forms
67
Structured vs. OO Methodology
Structured
Methodology
Object Oriented
(Unified Process)
Use of development
activities (Planning,
Analysis..)
Each activity covers a whole
phase
All activities run in each
phase, several times
(iterations)
Names of development
phases
Planning,
Analysis, Design,
Implementation,
Installation/Testing
Inception, Elaboration,
Construction,
Transition
Appropriate to use
When system goals certain,
static IT
When system goals less
certain, dynamic IT
Modeling technique
Data Flow Diagrams,
Entity-Relationship Diagrams
Diagrams defined by Unified
Modeling Language (Use
Cases, Class Diagrams…)
Relation to reality
Predictive
Adaptive
68
END!
69