4 sdlc and stlc

1

System Analysis and Design

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

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.

2

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.

3

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

2. Development

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

4



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

5



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.

6



7

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)

8

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.

9

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.

10

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

11

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.

12

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

13

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.

14

V-Model (SDLC & STLC)


15

Testing Through Life Cycle


1. Requirement AnalysisTesting

2. Design Testing

3. Unit Testing

4. Integration Testing

5. System Testing

6. User Acceptance Testing

16

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

17

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

18

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.

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

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.

Bad Example Good Example Requirement #1: The system must be user friendly.

How to measure user friendliness?

Requirement #1: The UI should be menu driven and

provide dialog boxes, help screens, radio buttons,

dropdown boxes etc.

Bad Example Good Example

Requirement #1: Navigation from one screen to another

should be very quickly.

How long is very quickly?

Requirement #1: Navigation from one screen to

another should be <= 2 seconds

19



4. Complete: The requirement is fully stated in one place with no missing information.

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

documented.

Bad Example Good Example Requirement #1: The system must generate batch end

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?

Requirement #1: The system must generate a batch

end report when a batch is aborted.

Requirement #2: The system must generate a

discrepancy report when a batch is aborted or

completed.

Bad Example Good Example Requirement #1: If the system failure occurs in Prod,

an error notification should be sent.

To whom and what format?

Requirement #1: If the system failure occurs in

Prod, an email error notification should be sent to

[email protected]

(Email notification format/screen should be provided)

20



Feasible:

Feasibility means that a requirement can be accomplished within the cost and schedule, can be met

using existing technology.

etc.

Bad Example Good Example Requirement #1: The replacement control system shall be installed

with no disruption to production.

This is an unrealistic expectation.

Requirement #1: The replacement control system shall be

installed causing no more than 2 days of production disruption.

21

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.

22

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

23

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

24

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

25

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

26

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.

27

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.

28

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

29

Testing Life Cycle – V&V Process Model


HLD/LLD for each

application involved

Interface design

Application

Integration

Integrated

Solution

Release

Project Planning

Master Test Strategy

Test Planning

Strategy for

individual

applications, Test

case design

Performance

Testing

Acceptance Tests

Incremental

Integration Testing

System Testing

(Application level

Testing)

Solution Mapping/

Development/

Customization

Business

requirements and

Solution

Architecture

30

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


31

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


32

QA Deliverables


1. Master Test Plan

2. Effort estimation document

3. Test Team Capacity Planning, Utilization, and assignment allocations document

4. Test Team Training Check List (Tool Training, Application Training etc.) document

5. Test Metrics

6. Traceability Matrix (If QA team responsible for it.)

7. Integration Test Plan (If QA team performs this testing.)

8. Functional Test Plan

9. Performance Test Plan

10. Test plan tracking sheet.

11. Test scenarios, test cases/scripts

12. Regression test bed

13. Test Data creation/Usage/Maintenance strategy document

14. Test Environment Setup details

15. Test Execution/Completion Status reports

16. Defect Reports

17. Automation feasibility study report (if applicable)

18. Functional automation model, framework and approach document

19. Performance automation model, framework and approach document

20. Test Closure Report

21. QA Sign-off

Etc.

33

SDLC Deliverables


4 sdlc and stlc

Education

Transcript of 4 sdlc and stlc