Software development life cycle

1. LECTURE 2
SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)
COURSE INSTRUCTOR: Akram Ali Omar
Email: akram.ali.omar@gmail.com
Mobile: +255778695626
The State University Of Zanzibar 1
CS 1211: Information Systems Analysis and Design

2. 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.
• It consists of a series of phases, each with its own set of activities and
deliverables.
• Understanding SDLC is crucial for software developers, project
managers, and other stakeholders involved in the software
development process
2

3. Phases of SDLC
3
Each phase has its own set of objectives and deliverables that must be completed before
moving on to the next phase.

4. Phases of SDLC
• Project planning – initiate, identify the scope, determine project goals and
objectives, 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 , improve, fix defects, make enhancements,
and provide support to the users.
4

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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
• It consists of a series of phases, each of which has a corresponding testing
phase
• Testing of the product is planned in parallel with a corresponding phase of
development in V-model
14

15. V- model
15

16. 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. 16

17. 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
17

18. 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 – defects are found at early stage.
• Avoids the downward flow of the defects - defects and issues can be
identified and resolved before they can flow down to subsequent phases
• Works well for small projects where requirements are easily understood
18

19. 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.
19

20. 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.
20

21. 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
21

22. Prototyping model
22

23. 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.
23

24. 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.
24

25. 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
25

26. Iterative & 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

27. Iterative & Incremental model
27

28. Advantages of Iterative & 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.

29. Disadvantages of Iterative & 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.

30. When to use the Iterative & 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

31. 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
31

32. Agile development model
32

33. 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
33

34. 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.
34

35. Choosing the right Software development life
cycle model
• Understanding the different SDLC models is important for software
developers, project managers, and other stakeholders involved in the
software development process.
• Each model has its own strengths and weaknesses, and the right model
should be chosen based on the specific requirements of the project.
• Using an appropriate SDLC model can help to ensure that the software
development process is efficient, effective, and produces high-quality
software.
35

36. 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
• 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
36

37. 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.
37

38. 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? 38

39. Some Recommended criteria
39
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

40. Software Development Approaches to SDLC
• Two common approaches in software development
1. Traditional Approach(structured approach)
2. object-oriented (OO) approach
40

41. Traditional Approach(structured approach)
• It involves breaking down a large software project into smaller, more manageable
modules.
– This is done by starting with a high-level view of the project and gradually decomposing it
into smaller and more detailed components
• 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
41

42. Traditional Approach(structured approach)
• The structured approach looks at a system from a top-down view
• The top-down approach to software development involves the following steps:
– Define the problem: define the problem that the software is intended to solve.
– Create a high-level design: high-level design should include the major components and the
interactions between them. This design should provide a general overview of the software
system.
– Divide the problem into smaller modules: The high-level design is then broken down into
smaller modules. This involves identifying the major sub-components of the software system
and breaking them down into smaller, more manageable pieces
– Design the smaller modules: Each smaller module is then designed in detail. This involves
defining the inputs and outputs of the module, as well as the processing that will take place
within the module 42

43. Traditional Approach(structured approach)
– Implement the modules: The modules are then implemented using a programming
language. The modules can be developed independently and then integrated into the
larger system.
– Integrate the modules: Once the modules are implemented, they are integrated into the
larger software system. This involves testing the modules together to ensure that they
work together as expected.
– Test and debug: The final step in the top-down approach is to test and debug the entire
software system. This involves identifying and fixing any defects that are found during
the testing process.
43
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)

44. Traditional Approach(structured approach)
• 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)
44

45. Structured approach to SDLC (Waterfall Model)
• The waterfall model is a specific type of structured approach that consists
of a linear sequence of phases, where each phase must be completed before
moving on to the next.
• There are several other models to represent this process.
45

46. The Object-Oriented Approach
• Object-oriented approach is a programming paradigm that focuses on
modeling real-world objects as software objects.
• In the object-oriented approach, a software system is designed by
identifying the objects that make up the system and defining their
interactions.
• The model consists of a set of objects and their relationships, and
describes how the objects interact with each other to accomplish the
system's goals.
• The model provides a way to visualize the system and understand its
behavior, making it easier to design, implement, and maintain the
software. 46

47. The Object-Oriented Approach
• The object-oriented methodology views a system as a bottom-up
approach to systems development. It may also be applied to top-
down approach.
• In a bottom-up approach, the system is built by first creating small,
independent modules or components and then combining them to
form a larger system. This approach is sometimes referred to as a
"building block" approach, where each module is a building block
that can be reused and combined to create more complex systems.
47

48. Object-Oriented Analysis and Design
• 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.
48

49. 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
49

50. END!
50