4 sdlc and stlc

System Analysis and Design
The Systems Analysis and Design (SAD) is the process of developing Information Systems (IS –
Acquiring and installing system environment; creating and testing databases, creating test case
procedures, creating test data, coding, code refining, perform test readiness review and procurement
activities ) that effectively use hardware, software, data, processes, and people to support the
company’s business objectives.

System
A set of detailed methods, procedures, and routines established or formulated to carry out a specific
activity , perform a duty, or solve a problem.

Analysis
The process of identifying problems, resources, opportunities, requirements and constraints
Design
The business of finding a way to meet the functional requirements within the specified constraints
using the available technology.

1

Anyone who has never made a mistake has never tried anything new.

What is Software Development Life Cycle (SDLC)?
Software Development Life Cycle (sometimes referred to as the System
Development Life Cycle) is a process of creating or altering information
systems, and the models and methodologies that people use to develop.

It adheres to different phases or stages of a project from inception through
completion and delivery of the final product and maintenance too.
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, Incremental, Agile etc. The oldest of these, and the best known, is
the waterfall model: a sequence of stages in which the output of each stage
becomes the input for the next.

2


Software Development Life Cycle
It has 3 identifiable phases. SDLC phases serve as a programmatic guide to
project activity and provide a flexible but consistent way to conduct
projects to a depth matching the scope of the project.

1.
2.
3.

Definition
Development
Maintenance

Definition phase focuses on WHAT






What information is to be processed?
What functions and performances are desired?
What interfaces are to be established?
What design constraints exists?
What validation criteria is required to define a success system?

3


Development phase focuses on HOW





How the database should be designed?
How the software architecture to be defined?
How the design will be translated into code?
How testing will be performed?

There are 3 specific steps in development phase are
1. Design
2. Coding
3. Testing (ignored due to lack of time, due time to market, additional
cost involved, lack of testing requirement understanding etc.)

4


Maintainability is defined as the ease with which software can be
understood, corrected, adapted and enhanced.
Maintenance Phase focuses on CHANGE





Error correction.
Adoption required as the software environment evolves.
Enhancements brought about by changing customer requirements.
Reengineering carried out for performance improvements.

5



6


Software Development Life Cycle - Phases
Phase 1. Initiation (Identifies a need or an opportunity)
Phase 2. System concept development (Prepares systems boundary document,
perform cost benefit analysis, Risk management plan and feasibility study)
Phase 3. Planning (Develop project management plan and other planning docs)
Phase 4. Requirement Analysis (Analyses user needs and develops user
requirements. Create detailed functional requirements document (FRD))
Phase 5. Design (Transforms user requirements into complete/detailed system
design. It focuses on HOW)
Phase 6. Development (Converts design into a complete information system)
Phase 7. Integration and Test (Demonstrate that developed system conforms to
requirements in FRD. Produce test analysis reports)
Phase 8. Implementation (Implementation preparation, Implementation of the
system into production environment, and resolution of problems identified in
the integration and test phases)
Phase 9. Operation and Maintenance (Describe tasks to operate and the system
developed)
Phase 10. Disposition (Describe end to end activities)
7


SDLC Phases











Initiation:
Request for proposal
Proposal
Negotiation
Letter of Intent
Contract
User Requirement Specification
Software Requirement specification  Software Requirement Specification
is a means of translating the ideas in the minds of the clients(the inputs) into a
set of formal document (the output) of the requirement phase. The role of it
use to bridge the communication gap between the client and the developer.
Preliminary analysis: The objective of this phase is to conduct a
preliminary analysis, propose alternative solutions, describe costs and
benefits and submit a preliminary plan with recommendations.

8


SDLC Phases
 Conduct the preliminary analysis: In this step, you need to find out the organization's
objectives and the nature and scope of the problem under study.
Then you need to see how the problem being studied fits in with them.
 Propose alternative solutions: Alternate proposals may come from interviewing employees,
clients , suppliers, and/or consultants. You can also study what competitors are doing. With this
data, you will have three choices: leave the system as is, improve it, or develop a new system.
 Describe the costs and benefits
 Systems analysis and requirements definition: Defines project goals into defined functions
and operation of the intended application. Analyzes end-user information needs. This step
involves breaking down the system in different pieces to analyze the situation, analyzing project
goals, breaking down what needs to be created and attempting to engage users so that definite
requirements can be defined.
In the requirement phase we gather as much information as possible about the detail and
specifications of the desired soft ware from the client.

9


SDLC Phases
 Systems design: Describes desired features and operations in detail,
including screen layouts, business rules, process diagrams, pseudo code and
other documentation. The output of this stage will describe the new system as
a collection of modules or subsystems. The design stage takes as its initial
input the requirements identified in the approved requirements document
HLD and LLD phases put together called Design phase .
 High Level Design (Macro Level): High level design documents contain the
items listed below
1. List of modules and a brief description of each
2. Brief functionality of each module
3. Interface relationship among modules
4. Dependencies between modules
5. Database tables identified with key elements
6. Overall architecture diagrams along with technology details
7. Business team provide sign-off for this design only
10


SDLC Phases
 Low Level Design (Micro Level): Low level design documents contain the items
listed below.
1. Detailed functional logic of the module, in pseudo code
2. Database tables, with all elements, including their type and size
3. All interface details
4. All dependency issues
5. Error message listing
6. Complete input and output format of a module
7. Business team will not provide sign-off for this design.

 Development: The real code is written here.
 Integration and testing: Brings all the pieces together into a special testing
environment, then checks for errors, bugs and interoperability.
Test Environment is an environment utilized to simulate normal business transactions,
processes, and activities during functional testing of software.
 Acceptance, installation, deployment: 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.
11


V Model
 If you are working in large project, where the systems are complex, its easy to miss
out key details in the requirements phase itself. In such cases , an entirely wrong
product will be delivered to the client. You will have to start a fresh with the project.
 Or if you manage to note the requirements correctly but make serious mistakes in
design and architecture of you software you will have to redesign the entire software to
correct the error.
 Assessments of thousands of projects have shown that defects introduced during
requirements & design make up close to half of the total number of defects.
 Also, the costs of fixing a defect increases across the development life cycle. The
earlier in life cycle a defect is detected, the cheaper it is to fix it.
 To address this concern , the V model of testing was developed where for every phase ,
in the Development life cycle there is a corresponding Testing phase.
 In the V model diagram provided below, the left side of the model is Software
Development Life Cycle (SDLC) and the right side of the model is Software Test Life
Cycle (STLC). The entire figure looks like a V, hence the name V - model
12


V Model


The V model is an industry standard framework that shows clearly the software development life cycle in
relation to testing. It also highlights the fact that the testing is just as important as the software development
itself.



In V-Model testing begins as early as possible in the project life cycle. There are a variety of testing activities
that need to be performed before end of the coding phase. These activities should be performed in parallel to
the development activities so that testers can produce a set of test deliverables.



The V-Model illustrates that testing activities (verification and validation) can be integrated into each phase of
the project life cycle.

 Verification (are we building the product right?): The process of determining whether or not the projects of a
given phase of the software development cycle meet the implementation steps and can be traced to the
incoming objectives established during the previous phase. The techniques for verification are testing and
inspection. All Quality Control activities through out the life cycle that ensures that all deliverables from
different phases meet their specification.
 Validation (are we building the right product?): The process of evaluation software at the end of the software
development process to ensure compliance with software requirements. It is a process of controlling that data
inserted into an application satisfies pre-determined formats or complies with stated length and character
requirements and other defined input criteria. The techniques for validation are testing and inspection. The
testing phase of the life cycle ensures that the end product meet the user needs
 Normally, testing of any Large Systems will be in TWO parts. The functional verification and validation against
the Requirement Spec and Performance evaluation against the indicated requirements.
 Testing activity is involved right from the beginning of the project.


13

V-Model (SDLC & STLC)

14


Testing Through Life Cycle
1.
2.
3.
4.
5.
6.

Requirement AnalysisTesting
Design Testing
Unit Testing
Integration Testing
System Testing
User Acceptance Testing

15


1. Requirement AnalysisTesting
The objective of Requirement Analysis Testing is to
ensure software quality by eradicating errors as early as
possible in the development process, as the errors
noticed at the end of the software life cycle are more
costly compared to that of early ones, and there by
validating each of the Outputs.
The objective can be achieved by three basic issues:
1. Correctness
2. Completeness
3. Consistency

16


Types of Requirements
In short, software requirements are typically broken down into two major categories:

Functional requirements

Non-functional requirements
Functional requirements describe the behavior and capabilities of a software system, and the information the
system will manage. Functional requirements are typically described in a series of "the system will" or "the system
shall" statements.
Non-functional requirements are all the other requirements that don't describe the behavior of the system.
Example #1: Look and Feel requirement might state that "The system shall use the corporate colors and logo“
Example #2: A Performance requirement might state that "The system shall handle a simulated user load of 1,000
users"

Non-functional software requirements are then broken down into several sub-categories, like this:
 Reliability
 Data
 Performance
 Look and Feel
 Operational (or Operability)
 Security
 Compatibility
 Maintainability
 Transferability

17


What constitutes “good” requirements?
1. Verifiable: The implementation of the requirement can be determined through one of four possible methods:
inspection, demonstration, test or analysis.
Bad Example
Requirement #1: The system must be user friendly.
How to measure user friendliness?

Good Example
Requirement #1: The UI should be menu driven and
provide dialog boxes, help screens, radio buttons,
dropdown boxes etc.

2. Clear & Concise: The requirements give your team a useful, easy to read and easy to change understanding of
what must be done. Great requirements exist to do three things:
I)
Identify the problems that need to be solved.
II) Explain why those problems are worth solving.
III) Define when those problems are solved
Bad Example
Good Example
Requirement #1: Navigation from one screen to another Requirement #1: Navigation from one screen to
should be very quickly.
another should be <= 2 seconds
How long is very quickly?

3. Unambiguous : The requirement is concisely stated without recourse to technical jargon, acronyms (unless
defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not
subjective opinions. It is subject to one and only one interpretation. Unnecessary narrative or non-relevant facts,
vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and
compound statements are avoided.
18


4. Complete: The requirement is fully stated in one place with no missing information.
Bad Example
Good Example
Requirement #1: If the system failure occurs in Prod, Requirement #1: If the system failure occurs in
an error notification should be sent.
Prod, an email error notification should be sent to
To whom and what format?
Prod_Support@XX.com
(Email notification format/screen should be
provided)

5. Consistent: The requirement does not contradict any other requirement and is fully consistent with all
authoritative external documentation.
Consistent Requirements are requirements that
 Are not in conflict with any of your strategic objectives, vision, or corporate goals.
 Avoid logical inconsistencies
 Utilize consistent structure, terms, and grammar
6. Traceable: The requirement meets all or part of a business need as stated by stakeholders and authoritatively
Bad Example
Good Example
documented.
Requirement #1: The system must generate batch end Requirement #1: The system must generate a batch
report and discrepancy report when a batch is aborted.
How is this uniquely identified? If the requirement is
changed later so that it does not require a discrepancy
report, how will you trace it back to so you can delete
it?

end report when a batch is aborted.
Requirement #2: The system must generate a
discrepancy report when a batch is aborted or
completed.

19


Feasible:
Feasibility means that a requirement can be accomplished within the cost and schedule, can be met
using existing technology.
Bad Example
Good Example
Requirement #1: The replacement control system shall be installed Requirement #1: The replacement control system shall be
with no disruption to production.
installed causing no more than 2 days of production disruption.
This is an unrealistic expectation.

etc.

20


Changes in Requirements
Requirements generally change with time. Once defined and approved, requirements should fall
under change control process. For many projects, requirements are altered before the system is
complete. This is partly due to the complexity of computer software and the fact that users don't
know what they want before they see it.

What is Change control?
Change control is a formal process used to ensure that changes to a product or system are
introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary
changes will be introduced to a system without forethought, introducing faults into the system or
undoing changes made by other users of software. The goals of a change control procedure usually
include minimal disruption to services, reduction in back-out activities, and cost-effective utilization
of resources involved in implementing change.

21


Requirements Analysis
 Difficulties in conducting requirements analysis:





Analyst not prepared
Customer has no time/interest
Incorrect customer personnel involved
Insufficient time allotted in project schedule

 Testing related activities during Requirement phase





Creation and finalization of testing templates
Creation of Test Strategy (Master Test Plan)
Capturing Acceptance criteria and preparation of Acceptance Test Plan
Capturing Performance criteria of the software requirements

22


2. Design Testing
The objective of the design phase testing is to generate a complete specifications for implementing a
system using a set of tools and languages.







Design objective is fulfilled by five issues
Consistency
Completeness
Correctness
Feasibility
Tractability

23


2. Design Testing





Testing activities in System Testing phase
System test is done for validating the product with respect to client requirements
Testing can be in multiple rounds
Defect found during system test should be logged into Defect Tracking System for the purpose of
tracking.
 Test logs and defects are captured and maintained.
 Review of all the test documents

24


3. Unit Testing
It is the most ‘micro’ scale of testing and focus on to test particular functions or code modules.
This testing performed by programmers not by testers, as it requires detailed knowledge of the internal
program design and code.
The main objective of unit testing is to ensure that the individual units of a system work correctly
in isolation, before they are eventually integrated
 Unit testing objective is fulfilled by four issues





Completeness
Correctness
Early Testing
Debugging

25


4. Integration Testing
Integration testing of combined parts of an application to determine if they function together correctly.
Here parts of the application can be code modules, individual applications, client and server applications
on a network
The main objective of integration testing is minimizing the errors which include internal
and external Interface errors.
 Testing activities in Integration Testing Phase
 This testing is conducted in parallel with integration of various applications (or components)
 Testing the product with its external and internal interfaces without using drivers and stubs.
 Incremental approach while integrating the interfaces.

26


5. System Testing
 Software once validated for meeting functional requirements must be verified for proper interface
with other system elements like hardware, databases and people.


System testing verifies that all these system elements mesh properly and the software achieves
overall function/performance.

 We carry out functionality testing, performance testing and other black box testing to requirement as
part of system testing.
 Testing activities in System Testing phase.
 System test is done for validating the product with respect to client requirements.
 Testing can be in multiple rounds.
 Defect found during system test should be logged into Defect Tracking System for the purpose of
tracking.
 Test logs and defects are captured and maintained.
 Review of all the test documents.

27


Testing Life Cycle – V&V Process Model
Definition: V&V – a system engineering discipline employing a rigorous methodology for evaluating and
assessing the correctness and quality of software throughout the software life cycle.
Verify a developers process is technically sound.
V&V usually focuses on ensuring the requirements are being met, the overall project is focused on the
correct objectives, and risk is being managed.
 Benefits of V&V





Early detection leads to a better solution rather than quick fixes.
Validating the solution is solving the “right problem” against software requirements.
Objective evidence of software and system compliance to quality standards.
Support process improvements with an objective feedback on the quality of development process and
products.

Finally, You must note that there are numerous development life cycle models. Development model
selected for a project, depends on the aims and goals of that project

28


Testing Life Cycle – V&V Process Model

Business
requirements and
Solution
Architecture

Acceptance Tests
Master Test Strategy

Project Planning

HLD/LLD for each
application involved
Interface design

Test Planning

Strategy for
individual
applications, Test
case design

Solution Mapping/
Development/
Customization

Release

Integrated
Solution

Application
Integration

Performance
Testing

Incremental
Integration Testing

System Testing
(Application level
Testing)

29


QA and the SDLC (In terms of Test Management tool – Quality Center (QC))

30


Testing Process and the SDLC (In terms of Test Management tool – Quality Center (QC))

31


QA Deliverables
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.

Master Test Plan
Effort estimation document
Test Team Capacity Planning, Utilization, and assignment allocations document
Test Team Training Check List (Tool Training, Application Training etc.) document
Test Metrics
Traceability Matrix (If QA team responsible for it.)
Integration Test Plan (If QA team performs this testing.)
Functional Test Plan
Performance Test Plan
Test plan tracking sheet.
Test scenarios, test cases/scripts
Regression test bed
Test Data creation/Usage/Maintenance strategy document
Test Environment Setup details
Test Execution/Completion Status reports
Defect Reports
Automation feasibility study report (if applicable)
Functional automation model, framework and approach document
Performance automation model, framework and approach document
Test Closure Report
QA Sign-off

Etc.

32


SDLC Deliverables

33


4 sdlc and stlc

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 4 sdlc and stlc

Similar to 4 sdlc and stlc (20)

Recently uploaded

Recently uploaded (20)

4 sdlc and stlc