Ch 2 System Development Life

Cycle
 What is SDLC?

 System Analysis Specifications

 System Design Specifications

 System Coding

 System Implementation and Maintenance

 System Evaluation

 Water-fall model

 Spiral model
What is SDLC?
 The Systems development life cycle (SDLC) - is a
process of creating or altering information systems and
the models and methodologies that people use to
develop these systems.
 In software engineering, the SDLC concept underpins
many kinds of software development methodologies.
 These methodologies form the framework for planning
and controlling the creation of an information system:
the software development process.
 The SDLC is a process used by a systems analyst to
develop an information system.
 Any SDLC should result in a high quality system that
meets customer expectations, reaches completion
within time and cost estimates
What is SDLC?
 Computer systems are complex and often (especially
with the recent rise of service-oriented architecture)
link multiple traditional systems potentially supplied
by different software vendors.
 To manage this level of complexity, a number of SDLC
models or methodologies have been created
 Waterfall
 Spiral
 Agile software development
 rapid prototyping
 Incremental
 SDLC models can be described along spectrum of
agile to iterative to sequential
What is SDLC?
 SDLC Phases
Preliminary
Investigati
on

Maintenance Analysis

Implementatio
Design
n

Testing Coding
What is SDLC?
Following are the phases
1) Preliminary Investigation
 Request clarification
 Feasibility study – identify whether request is feasible
 Carry out by small group of people
 Typically have following types
 Economically
 Technically
 operationally
 Request approval
 Approved by management
 After that cost, priority, completion time, and
personnel requirements are estimated
What is SDLC?
 Determination of requirement (Analysis)
 Analyst works with employees and managers to
understand facts
 Find out facts about existing system, takes opinion
of experts.
 Analyze the information which is collected.
 Defines project goals into defined functions
and operation of the intended application.
 Analyzes end-user information needs.
 Design
 Describes desired features and operations in detail,
including screen layouts, business rules, process
diagrams, pseudo code and other documentation.
What is SDLC?
 Development
 The real code is written here.
 Testing
 checks for errors, bugs and interoperability
by using different methods.
 Deployment or Implementation: The final
stage of initial development, where the
software is put into production and runs actual
business.
 Maintenance: What happens during the rest of
the software's life: changes, correction,
additions, moves to a different computing
platform and more. This is often the longest of
the stages.
What is SDLC?
 Limitations
 Interaction with user is limited
 The analytical tools like flowcharts, programs
are focus more with physical aspects than
logical aspects
 It is difficult to change or maintain specification
 Complete software development is only viewed
at the end.
 Changes at the ends are very difficult to
incorporate, almost impossible.
System Analysis
Specifications
Requirements analysis is a software engineering task that bridges
the gap between system level requirements engineering and
software design.
 Requirements engineering activities result in the specification of
software’s operational characteristics like function, data, and
behavior, indicate software's interface with other system
elements, and establish constraints that software must meet.
 Requirements analysis allows the software engineer (sometimes
called analyst in this role) to refine the software allocation and
build models of the data, functional, and behavioral domains that
will be treated by software.
 Requirements analysis provides the software designer with a
representation of information, function, and behavior that can be
translated to data, architectural, interface, and component-level
designs.
 Finally, the requirements specification provides the developer and
the customer with the means to assess quality once software is
built.
System Analysis
Specifications
Software requirements analysis may be divided into
five areas of effort:
 Problem recognition,
 Evaluation and production,
 Modeling,
 Specification,
 Review
System Analysis
Specifications
Initially, the analyst studies the System Specification
and the Software Project Plan.
 It is important to understand software in a system
context and to review the software scope that was used
to generate planning estimates.
 Next, communication for analysis must be established
so that problem recognition is ensured.
 The goal is recognition of the basic problem elements as
perceived by the customer/users.
 Problem evaluation and solution synthesis is the next
major area of effort for analysis.
 The analyst must define all externally observable data
objects, evaluate the flow and content of information,
define and elaborate all software functions, understand
software behavior in the context of events that affect
the system, establish system
Requirements Anticipation
 Requirement – is a condition or a capability that must be
met or possessed by software system, to satisfy contract,
standards, specification or other formally imposed
documents.
 Anticipation means expectations towards the requirements
 Find out thorough requirements
 Requirements analysis is the process of understanding the
customer needs and expectations from a proposed system
or application and is a well-defined stage in the SDLC.
 This mainly focus on discovering, refining, modeling and
specifying the requirements.
 All the stakeholders play an active role in requirement
analysis.
Requirements Anticipation
 It is conducted with following objectives:
 Identify customers’ needs.
 Evaluation of system with reference to feasibility
study.
 To establish a basis for the creation of a software
design.
 To define a set of requirements that can be
validated once the software is build.
 Requirement analysis results in the specification of
software’s operational characteristics
 It indicate software’s interface with other system
elements
 Established constraints that software must meet.
Requirements Anticipation
 It allows the analyst to elaborate on basic requirements
established during earlier requirement engineering tasks
and build models that depict user scenarios, functional
activities, problem classes and their relationships, data flow,
class and functional behavior.
 Throughout analysis modeling, software designer focus on
what, not how.
 Some design invariably occurs as part of analysis, and some
analysis will be conducted during design.
 Analysis Rules of Thumbs
 The model should focus on requirements that are visible
within the problem or business domain.
 Each element of the analysis model should add to an
overall understanding of software requirements and
provides insights into the information domain.
Requirements Anticipation
 Delay consideration of infrastructure and other
non-functional model until design
 Minimize coupling throughout the system.
 Be certain that the analysis model provides
value to all stakeholders.
 Keep the model as simple as it can be.
Requirements Investigation
 Heart of System Analysis.
 Depends on Fact Finding Techniques and also
includes method for documenting & describing the
features of the system.
 Fact-finding Technique:
The Specific method that analyst used for collecting
data about requirements are called as fact-finding
techniques.
Types of Fact-Finding Technique
1. Sampling of Existing Documentation, forms, files
2. Research and site visits
3. Observation of the work Environment
4. Questionnaires
5. Interviews
6. Discovery Prototyping
7. Joint Requirement Planning
Types of Fact-Finding
Technique
1) Sampling of Existing system documentation, forms, files
 Study the Organization Chart
 Interoffice environment, customer complaints & Reports that
focus on Problem area.
 Accounting Records, performance & operating reports.
 IS project request past & future
 Company’s strategic Plan
 Objective of organization
 Policy manuals
 Standard Operating Procedure, job outline for day to day
operations
 Forms, Samples of Manuals& Computerized database,
reports & Screens.
Types of Fact-Finding Technique
 Various types of Flowcharts and Diagrams
 Project Dictionaries
 Design Documentation Related to Input, Output & Database
 Program Documentation
 Computer Operation Manuals & Training Manuals
2) Research & Site Visits
 Focus On Problem Domain
 Site visits(Other Organization/Departments)
 Saves time & cost in Development Process
 Computer Journals & Reference Books
 From Environment
 Intranet, Internet
Types of Fact-Finding Technique

3) Observation
 Most Effective data collection technique
 System analysts become observer
 Observe People & activities to learn about system
 Allow system Analyst to do work measurements
 the analyst himself visits the organization and
observes and understand the flow of documents,
working of the existing system, the users of the
system etc.
 Able to see exactly what is being done
 Inexpensive
Types of Fact-Finding Technique

4) Questionnaires
 Questionnaire is a special purpose document that allow system
analyst to collect information & opinion from Respondents.
 Allow analyst to collect facts from large number of peoples.
 This method can be adopted and used only by an skillful
analyst.
 The Questionnaire consists of series of questions framed
together in logical manner.
 The questions are simple, clear and to the point. This method
is very useful for attaining information from people who are
concerned with the usage of the system and who are living in
different countries. The questionnaire can be mailed or send to
people by post.
 This is the cheapest source of fact finding.
Types of Fact-Finding Technique

 Two Types of questionnaire:

1.Fixed Format
2.Free Format
1) Free Format Questionnaire
 System analyst gives freedom to user to answer
the questions.
 He provides space after each questions.
 User can share their thoughts, opinion, feelings,
experience as well as focus on problem area.
Types of Fact-Finding Technique

2) Fixed Format
 It contain questions that require selecting answers
from predefined set.
 Respondent cant give additional information.
 May be Multiple choice questions (Yes/No)
 May be Rating questions(Agree/Not Agree/No
opinion)
 May be Ranking Questions(Given several answers
which are ranked in order)
Types of Fact-Finding Technique

5) Interviews
 Interview is a fact-finding technique whereby the system analyst
collect information from individuals through fact to face
interaction.
 This method is used to collect the information from groups or
individuals.
 Analyst selects the people who are related with the system for
the interview.
 In this method the analyst sits face to face with the people and
records their responses.
 The interviewer must plan in advance the type of questions he/
she is going to ask and should be ready to answer any type of
question.
 He should also choose a suitable place and time which will be
comfortable for the respondent.
Types of Fact-Finding
Technique
 The information collected is quite accurate and reliable
as the interviewer can clear and cross check the doubts
there itself.
 This method also helps gap the areas of
misunderstandings and help to discuss about the future
problems.
 Structured and unstructured are the two sub categories
of Interview.
Types of Fact-Finding Technique

 Two Types of Interview

1) Structured Interview
2) Unstructured Interview
Types of Fact-Finding Technique

Structured interview is more formal interview where fixed

questions are
asked and specific information is collected
1) Structured Interview
 It covers Specific area
 Fixed types of questions
 Evaluation is simple
 Period is short
 Lot of study & preparation is required
 Time consuming
 Preparation cost is high
Types of Fact-Finding Technique

unstructured interview is more or less like a casual

conversation where in
depth areas topics are covered and other information
apart from the topic
may also be obtained.
2. Unstructured Interview:
 Covers specific area
 Different types of questions
 No time period
 Ask question linked with last questions
 Extra/Unnecessary information collected
 Lengthy process
 Cost of preparation is low
 Evaluation is difficult
Fundamental problems in
defining requirements

 The goal/means conflict

 The determination and description of functional
requirements.
 The representation of the user interfaces
 Structure or content of SRS
 SRS format or contents included in SRS
1. Introduction
1. Problem definition
2. Purpose of this document
3. Definition, acronyms and abbreviations
4. Purpose of the system
5. Scope of the system
6. References
7. Overview
2. General description
1. Product perspective
2. Functional requirements
Structure or content of SRS

3. Uses cases view

4. General constraints
5. Assumptions, dependencies, guidelines.
3. Specific requirements
I. External interface requirements
a) User interface
b) Hardware interface
c) Software interface
d) Communication interface
II. Detailed description of functional requirement
III. Performance requirements
IV. Design constraints
V. Quality attributes
System Design Specifications

 Once software requirements have been analyzed and

specified, software design is the first of three technical
activities—design, code generation, and test—that are
required to build and verify the software.
 Each activity transforms information in a manner that
ultimately results in validated computer software.
 Each of the elements of the analysis model provides
information that is necessary to create the four design
models required for a complete specification of design.
 The flow of information during software design
System Design
Specifications
System Design
Specifications

The data design transforms the information
domain model created during analysis into the
data structures that will be required to implement
the software.
 The data objects and relationships defined in the
entity relationship diagram and the detailed data
content depicted in the data dictionary provide
the basis for the data design activity.
 Part of data design may occur in conjunction with
the design of software architecture.
 The architectural design defines the
relationship between major structural elements of
the software, the “design patterns” that can be
used to achieve the requirements.
 System Design Specifications

 The architectural design representation—the

framework of a computer-based system—can be
derived from the system specification, the analysis
model, and the interaction of subsystems defined
within the analysis model.
 The interface design describes how the software
communicates within itself, with systems that
interoperate with it, and with humans who use it.
 An interface implies a flow of information (e.g., data
and/or control) and a specific type of behavior.
 Therefore, data and control flow diagrams provide
much of the information required for interface design
System Design
Specifications
 The component-level design transforms
structural elements of the software architecture
into a procedural description of software
components.
Design and Software
Quality
Throughout the design process, the quality of the evolving
design is assessed with a series of formal technical reviews
or design walkthroughs.
 Good Design must have following characteristics
 The design must implement all of the explicit requirements
contained in the analysis model, and it must accommodate all
of the implicit requirements desired by the customer.
 The design must be a readable, understandable guide for those
who generate code and for those who test and subsequently
support the software.
 The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from
an implementation perspective
System Design
Specifications
 Introduction
 Introduction of the System
 Purpose of the document
 Scope
 Design Overview
 Detail design description
 Requirement traceability matrix (RTM)
 Logical Architecture
 list of all the hardware components and provide a brief description.
 Include diagrams that shows their connectivity and even use
subsections for each subsystem where necessary.
 Under the application architecture, you should discuss the software
build.
 focus on the overall software design and organization.
 Includes list of the software modules, computer languages, and any
programming computer-aided software engineering tools.
System Design
Specifications
Physical Architecture
 Network architecture
 Data Model
 database management system
 Data Dictionary
 Detailed Design
 Integration between hardware and software design.
 Different diagrammatic designs
 Graphical User Interface
 GUI Design
 Input screens design
 Output screens designs
 Report designd
System Coding
 This phase coverts Design into code.
 Developers uses SRS, Analysis, Design to write the code.
 Input and output screen design is use to design the forms.
 Development team write the code in builds and the same
is forwarded to the testing team to the builds.
 Following approach is required while developing code
System Testing
 In parallel with development phase, testing team
tests the application.
 Uses different types of testing
 Unit, Integration, System and acceptance testing.
 Based on Test plan tester works
 Before tester starts testing he/she writes the test
cases by reading SRS.
 Use of STLC is must while testing.
System Implementation
and Maintenance
 After successfully completion of testing phase,
Deployment team deploy the software at clients
side
 After deployment client starts the use of software.
Introduction
 “Pay now or pay more later”
 Maintenance cost of total software budget –
increased from 35% to 60%.
 Maintainability – it is the ease with which
software can be
 Understood
 Corrected
 Adapted
 Enhanced
 Coding errors made in the last stage of
development are relatively easy to correct.
 Design errors done during the intermediary
stages are more expensive
 Requirement error introduced at the initial
stages of software system life are the most
expensive to correct.
Introduction

 Maintenance
 Software maintenance is the modification of
a software product after delivery to correct
faults, to improve performance or other
attributes, or to adapt the product to a
modified environment
Maintainability metrics
 Following are the maintainability metric
attribute
 Problem recognition time
 Administration delay time
 Maintenance tools collection time
 Problem analysis time
 Change specification time
 Active correction / modification time
 Local testing time
 Global testing time
 Maintenance review time
 Total recovery time
Problems in software maintenance

 Inadequate documentation of software

evaluation available.
 Generally the programs are “someone
else’s” programs and that “someone
else” is not available.
 Most software is not design for change.
 Absence of proper methodology when
software was generated.
 Maintenance jobs are viewed as
unwanted tasks.
Controlling factors for
maintainability
 Availability of qualified staff
 Understandable system structure
 Use of standard programming languages and
platforms
 Use of standard operating system
 Use of standard structure of documentation
 Availability of test cases for testing the
changes.
 Availability and use of built-in debugging
facilities.
 Availability of suitable hardware for
maintenance purpose.
Steps of maintenance in
structured method
 Following are the steps
1. Request for change
2. Evaluate design
3. Plan approach for effecting the changes
4. Change request queued / responsibility
assignment
5. Modify design
6. Recode
7. Review
8. Test and release.
Project resources
 Human resources
 Skilled staff
 Reusable software components
 Off-the-shelf components –
 existing software can be acquired from a third
party or has been develop internally for a past
project.
 COTS are the ready components are purchased
from a third party are ready for use on the
current project.
 Full experience components
 Part experience components
 New components
Project resources

 Environmental Resources
 Software tools
 Hardware
 Network resources
Types of Maintenance and
maintenance cost
 Following are the types of
maintenance
1. Corrective – which is required to correct
the bugs found in the software.
2. Adaptive – which is required to adapt to
the changed system requirements
3. Perfective – which is required to improve
the system, make it better.
4. Preventive – which is effected without
any specific requirements from the user
and which is done to prevent future
problems.
Types of Software Project Maintenance

1. Corrective maintenance:
 This refers to modifications initiated by
defects (design errors , logic errors, and
coding errors) in the software.
design errors :

occur when changes made to the software are

incorrect, incomplete, wrongly documented or
the change request is misunderstood
logic errors :

It result from invalid tests and conclusions,

incorrect implementation of design
specifications, faulty logic flow or incomplete
test data
coding errors

It caused by incorrect implementation of

detailed logic design & incorrect use of source
code logic
Types of Software Project Maintenance

2. Adaptive (Set in) maintenance:

 It includes modify the s/w to match the ever changing
environment.
 Changing environment in the context of change in business policy,

govt. policy, work pattern and S/W or H/W operating

platform
 which is required to adjust to the changed system requirements.
Types of Software Project Maintenance

3. Perfective maintenance:
 which is required to improve the system, make it better and more
better
 or restructuring the software to improve change ability.
 Perfective maintenance refer to enhancements : making the
product better, faster, smaller, better documented, with more
functions or report
Types of Software
Project Maintenance
 Preventive (Protective) maintenance:
 which is effected without any specific requirements from the user
and which is done to prevent future problems.
Types of S/w Project Maintenance
System Evaluation
 Actual use of software.
 Uses real data of the business.
Waterfall Model
 Waterfall model sometimes called classic life-cycle.
 It is introduced in 1970 by W. W. Royce
 it is oldest paradigm of software development of SE.
 A systematic sequential approach to software
development that begins with customer specification of
requirements and progresses through planning,
modeling, construction and deployment and sometimes
on-going support of the completed software.
 Phases in waterfall model
1) Requirements – project initiation and requirement
gathering
2) Design – analysis and design
3) Implementation - coding
4) Verification – testing
5) Deployment-delivery
6) Maintenance-support and feedback
Waterfall Model
Waterfall model
 Problems with the model
1) Real projects rarely follow the sequential flow
that the model proposes. Changes can cause
confusion as the project team proceeds.
2) It is often difficult for the customer to state all
requirements in details. This model requires at
the initial stages.
3) The customer must have a patience. A working
version not be available until late in the project
time span.
4) Some times leads into “blocking stage” and can
not exceeds until previous work completes.
Spiral model

 Spiral model originally proposed by Bohem in 1988.

 It is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
 It is risk driven process model.
 It is used to guide multi-stakeholder concurrent engineering of
software.
 Two features- 1) cyclic approach – for incrementally growing
software’s degree of definition and implementation while
decreasing its degree of risks.
2) set of anchor-point-milestones (a combination of work
products and conditions that are attained along the path of
spiral.) for ensuring stakeholder’s commitment for better
software.
 It divided in set of frameworks of activities.
Spiral model
Spiral model

 Unlike the other process models that end when

software is delivered, spiral model can be adapted
throughout life of software.
 First cycle represent “the concept development
project” which starts at the core and continues for
multiple iterations around the cycle.
 Next, “new product development project” starts.
 At the end spiral might be used to represent
“product enhancement project”.
 So used in large scale projects.
 Where customer better understand and react to
risks at each evolutionary level.
Spiral model

 Advantages of Spiral Model:

1. Good for large projects
2. Customer evaluation allows for any changes or
technology
3. Allow customer and developer to determine & react on
risk in each phase
4. Direct consideration of risk reduce the problems

 Disadvantages or Drawback of Spiral Model:

1. In contract situation it may be difficult to convince
customer that the evolutionary approach is controllable.
2. Need proper risk verification.
3. It not identifying problems properly occurs in
development.
Spiral model (win-win)

 Basic spiral model focus on involvement of customer in

a negotiation process.
 ‘Win’ condition negotiated among the stakeholder s.
 It means stakeholders should have increase the
interaction.
 Sometimes customer fails to provide detail requirements.
 It needs to have negotiation between developer and
customer to balance the functionality and performance
with cost and time to market considerations.
 Clients gets the product and developer ‘win’ by working
to realistic and achievable budget and deadlines.
 For this objective the model defines the negotiation
activities at beginning of each pass around the spiral.
Spiral model (win-win)

 Following are the activities

1. Identify the stakeholders
2. Determine stakeholders ‘win’ condition
3. Then determine the ‘win-win’ condition
(stakeholder and software project team)
4. Elaborate on product and process
5. Evaluate the alternatives
6. Elaborate the definition of product and process
7. Plan the next cycle, this can include plan to
terminate project if it is too risky or infeasible.
Spiral model (win-win)

 Advantages
1. Faster software production through
involvement of the relevant stakeholders
2. Cheaper software via rework and
maintenance reduction.