SDLC and SE Concepts

Introduction to SDLC and SE Concepts

Deloitte Consulting LLP

New hire orientation program

- 2 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Timelines

Start time End time Session

9:00 AM 10:45 AM Introduction and getting started

10:45 AM 11:00 AM Tea break

11:00 AM 1:00 PM System development life cycle

1:00 PM 2:00 PM Lunch break

2:00 PM 3:45 PM Requirement engineering

3:45 PM 4:00 PM Tea break

4:00 PM 5:00 PM Testing techniques

5:00 PM 6:00 PM Configuration management

Introduction to SDLC and SE

Concepts

Introduction and getting started


Date : 6th July 2009

- 4 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Software is the collection of.– Computer programs

– Procedures

– Rules

– Data

– Associated documentation

Software

- 5 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

A set of activities performed to achieve a given purpose. Any specific combination of machines, tools, methods, materials, and/or people employed to attain specific qualities in a product or service.

For organization to improve its business, following are three critical dimensions:

A definition of process

Process is one of three quality leverage pointsPeople

Process Technology

Inputs Outputs

- 6 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Establishment and use of sound engineering principles in order to obtain economically a software that is reliable and works efficiently on real machines (Bauer 69).

Application of science and mathematics by which capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation (Boehm 81).

A systematic approach to the development, operation, maintenance, and retirement of a software (IEEE 87).

Application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of a software(IEEE93).

Software engineering

- 7 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

High-quality product

At low cost

Goals of software engineering

- 8 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Waterfall model

Prototyping model

Iterative enhancement model

Spiral model

Software development models

- 9 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Sequential

Enforces complete requirements specification

Cannot proceed to the next phase till the current phase is over

Does not model the reality

Earliest availability of the working model — Midway through the project

Waterfall model

- 10 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Do not wait for requirements Freeze. Build a prototype to understand requirements.

Prototype thrown away after requirements are understood.

Effective method to demonstrate the feasibility of a new concept.

Danger of mistaking the prototype as the real software.

Prototyping model

- 11 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Software developed and delivered in increments.

Each increment adds some functionality.

At each step, enhancements based on client’s feedback analysis and design are carried out.

Iterative model

- 12 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Risk driven

Iterative steps– Planning

– Risk analysis

– Development

– Customer evaluation

Provides early indication of risks

Requires high management skills

Spiral model

- 13 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Part of a teamProgramming-in-the-largeDesign approaches

– OO, modules, etc.– Top-down/bottom-up

Translates requirements into specifications

Familiarity in multiple application areas

Converses with usersSees “big picture”Can model applicationGood communication and

interpersonal skills

Individual with good skillsProgramming-in-the-smallKnowledge on

– Data structures– Algorithms

Fluent in several programming languages

May lack formal trainingMinimal exposure to CS

Programmer versus software engineer

- 14 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Coping with legacy systems, coping with increasing diversity, and coping with demands for reduced delivery times

Legacy systems– Old, valuable systems must be maintained and updated

Heterogeneity– Systems are distributed and include a mix of hardware and software

Delivery– There is increasing pressure for faster delivery of software

What are the key challenges facing software engineering?

Q and A


SDLC – Jargon made easy



Agenda

What is SDLC?

SDLC phases

SDLC models

SDLC key success factors

References

Summary

Q and A

- 18 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

An acronym for system development life cycle.

A set of stages/phases that all information systems go through in their lifecycle.

A conceptual model used in system development.

What is SDLC?

- 19 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The generic phases of SDLC are:

Analysis

Design

Build/test

Deployment

Maintenance

SDLC phases

- 20 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

SDLC phases (cont.)

ScopeBusiness

Requirements

Requirement

Specification

Product

Selection

Architecture

Master Test

Strategy

Proof of

Concept

DesignSpecification

Design Test

Cases

Deployment

Build

Execute Test

Build/test DeploymentAnalysis Design Maintenance

Maintenance

- 21 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The analysis phase involves:

Study the client’s current business processes and information systems.

Evaluate issues/problem areas that need to be addressed by the new system.

Gather/determine and structure the requirements.

Prepare requirements specification document (RSD).

Review the RSD.

Get sign-off from the authorized client personnel.

Analysis phase


- 22 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The design phase involves:

Designing the physical construction, hardware, operating systems, networking, communications, and security specifications.

Preparing the functional design document that focuses mainly on the business processes/aspects of the system.

Preparing the technical design document that is based on the functional design and provides detailed technical specifications that should be followed during the construction phase.

Prepare unit test plans/scripts (UTPS).

Review the functional design and technical design documents.

Get sign-off from the authorized client personnel.

Design phase


- 23 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The build activities involve:

Installation of hardware, operating system, etc.

Develop code based on the technical design.

Perform unit testing of the code using the UTPS.

Closure of unit testing findings.

The testing activities involve:

Prepare the system test plan/scripts for testing the new system.

Complete system testing and integration testing.

Close the findings from system testing and integration testing.

Complete user acceptance testing.

Close the findings from user acceptance testing.

Get sign-off on the system from authorized client personnel.

Build/test phase


- 24 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The deployment phase involves:

Ensure the required hardware, software, network, etc., are setup.

Train the users on using the new system.

Deploy the newly developed system.

Release the new system to client users for use.

Monitor the performance of new system.

Help the users to increase their comfort level in using the new system.

Deployment phase


- 25 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The maintenance phase involves:

Prepare and review the maintenance plan.

Get sign-off on the system from authorized client personnel.

Document the issues reported by users on the new system.

Design, build, test, and deploy the code changes for resolving these issues.

Make changes to accommodate changes in operating system, peripheral devices, etc.

Make changes to accommodate customer’s functional or performance enhancement requirements.

Maintenance phase


- 26 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The more popular SDLC models are:

The linear sequential model.

The prototyping model.

The rapid application development (RAD) model.

The following few slides explain each of these models.

SDLC models

- 27 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The linear sequential model

Is also called the “waterfall model” or the “classic life cycle model”.

Is a sequential approach to system development.

Progresses from one phase to another.

Has analysis, design, build/test, and deployment as the phases.

Is the oldest and most widely used model.

Linear sequential model

Build/test DeploymentAnalysis Design

- 28 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Strengths

Oldest, widely used, and proven model.

More predictable and controllable project schedule.

Each phase proceeds in strict order and ensures all activities in previous phase are completed before moving to next phase.

High probability of delivering the system on time.

Weaknesses

Does not allow for revision or iteration. Not always feasible in real-time projects.

Sometimes is difficult for customers to clearly state all requirements.

Demands more patience from customers.

Adds a lot of waiting time for team members as they have to wait for the dependent tasks to be completed.

Linear sequential model (cont.)

- 29 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Prototyping model

Customer test-drives prototype

Build/revise prototype

Listen to customer

- 30 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The prototyping model is adopted when

The customer has a generic set of objectives.

Detailed requirements are not identified.

Build a pilot system to give an idea to the customer.

Pilot system will further lead to detailed development life cycle.

Prototyping model (cont.)

- 31 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Strengths

Serves as an effective mechanism for identifying requirements.

Iteration is possible and hence gives more flexibility.

Changing customer needs can be more effectively managed and hence provides better customer experience.

Adds comfort level to the client as the progress of the product is visible and they get a good idea of the final product.

Weaknesses

The initial prototype is not close to the final system. So, it may result in lot of rework.

Less/no focus on quality and hence may create more issues in the final system.

Prototyping model (cont.)

- 32 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

RAD model

New systemNew

systemTeam 2

Team 3

Team 1

Modelling (business, data, and process)

Applicationgeneration

Testing and turnover

- 33 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The RAD model:

Is a linear sequential model that emphasizes extremely short development cycle.

Is a “high-speed” adaptation of waterfall model.

Achieves rapid development by using component-based approach.

Each component/function is addressed by a separate team and all components are quickly integrated to form a whole system.

Has modeling, application generation, and testing and turnover as the phases.

Demands well-understood requirements and highly scalable scope.

RAD model (cont.)

- 34 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Strengths

Extremely short development lifecycles.

Embraces Object Oriented (OO) programming which inherently fosters reusable software components.

Encourages use of readily available tools in the market to reduce the lifecycles.

Results in highly maintainable and scalable system.

Lesser time spent on testing and review activities.

Weaknesses

Very high resource requirements.

Demands full-time availability and high commitment from customers.

Not suitable for projects where the system cannot be properly modularized.

RAD model (cont.)

- 35 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Planning and scheduling

Document reviews

Following development standards

Code reviews and walk-through

Configuration management (version control)

Issue tracking

Testing and defect prevention

Change management process

SDLC key success factors

- 36 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Deloitte KX Portal – https://kx.deloitteresources.com/default.aspx

Deloitte Learning Center – https://www.deloittenet.com/dtlearning/default.asp

Books– ‘Software Engineering – A Practitioner’s Approach’ by Roger Pressman

– ‘Software Engineering Productivity Handbook’ by J. Kayes

– ‘Encyclopedia of Software Engineering’ by J. J. Marchiniak

Other Useful Links– http://www.lifecyclestep.com/0.0.0LifecycleStepHomepage.htm

– http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm

– http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/

– http://www.business-esolutions.com/islm.htm

– http://searchvb.techtarget.com/sDefinition

– http://searchsmallbizit.techtarget.com/sDefinition/0,,sid44_gci214246,00.html

– http://www.cs.wm.edu/~coppit/csci780-fall2003/presentations/15-spiral-model.pdf

– http://searchvb.techtarget.com/sDefinition/0,,sid8_gci755347,00.html

– http://www.sei.cmu.edu/

References

https://kx.deloitteresources.com/default.aspx

https://www.deloittenet.com/dtlearning/default.asp

http://www.lifecyclestep.com/0.0.0LifecycleStepHomepage.htm

http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm

http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall

http://www.business-esolutions.com/islm.htm

http://searchvb.techtarget.com/sDefinition

http://searchsmallbizit.techtarget.com/sDefinition/0,,sid44_gci214246,00.html

http://www.cs.wm.edu/~coppit/csci780-fall2003/presentations/15-spiral-model.pdf

http://searchvb.techtarget.com/sDefinition/0,,sid8_gci755347,00.html

http://www.sei.cmu.edu/

- 37 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Define SDLC

SDLC phases

SDLC models

Key success factors

References

Summary

Q and A




Requirement engineering process

Topics

Requirement engineering

Why requirement engineering?

Types of requirement

Users of requirement

Requirement Measure

Guidelines for writing requirement document

Requirement management flow

- 41 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed

The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process

Phases of requirements in project life cycle– Obtain an understanding of requirements

– Obtain commitment to requirements

– Manage requirements changes

– Maintain bidirectional traceability of requirements

– Identify inconsistencies between project work and requirements

Requirement engineering

- 42 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

User’s perception of requirement

Why requirement engineering

- 43 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Designer’s perception of requirement


- 44 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Developer’s perception of requirement


- 45 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

User requirements– Statements in natural language, plus diagrams of the services the system

provides and its operational constraints. Written for customers

System requirements– A structured document setting out detailed descriptions of the system

services. Written as a contract between client and contractor

Software specification– A detailed software description, which can serve as a basis for a design or

implementation. Written for developers

Types of requirements — 1

- 46 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Types of requirements — 1 (cont.)

Client managers System end users Client engineers Contractor managers System architects

System end users Client engineers System architects Software developers

Client engineers (perhaps) System architects Software developers

User requirements

Software design specification

System requirements

- 47 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Functional requirements– Statements of services the system should provide, how the system should

react to particular inputs, and how the system should behave in particular situations

Nonfunctional requirements– constraints on the services or functions offered by the system, such as timing

constraints, constraints on the development process, standards, etc.

Domain requirements– Requirements that come from the application domain of the system and that

reflect characteristics of that domain

Types of requirements — 2

- 48 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Different users of requirement document

Specify the requirements and read them to check that they meet their needs.

They specify changes to the requirementsSystem customers

Managers

System engineers

System test engineers

System maintenance engineers

Use the requirements document to plan a bid for the system and to plan the

system development process

Use the requirement to understand what system is to be developed

Use the requirement to develop validation tests for the system

Use the requirements to help understand the system and the relationships

between its parts

- 49 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Requirements measures

Property Measure

Speed Processed transactions/second

User/even response time

Screen refresh time

Size Kilo bytes

Number of RAM chips

Ease of use Training time

Number of help frames

Reliability Meantime to failure

Probability of unavailability

Rate of failure occurrence

Availability

Robustness Time to restart after failure

Percentage of events causing failure

Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems

- 50 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Invent a standard format and use it for all requirements

Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements

Use text highlighting to identify key parts of the requirement

Avoid the use of computer jargon

Specify external system behavior

Specify implementation constraints

Easy to change

Serve as reference tool for maintenance

Record forethought about the life cycle of the system i.e. predict changes

Characterize responses to unexpected events

Guidelines for writing requirements

- 51 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Requirements document structure.– Introduction

– Glossary

– User requirements definition

– System architecture

– System requirements specification

– System models

– System evolution

– Appendices

– Index

Guidelines for writing requirements (cont.)

- 52 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

RM process — Functional spec (FS) preparation

Alternative solutions (for decision making)

Create FS

For changes, refer to change control procedure

Review requirements

Input — Business requirement

Review FSSign off FSOutput — Baseline functional specs

- 53 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

RM process — Technical spec (TS) preparation


Create TS and test cases


Initial object review/requirements understanding

Input Functional spec Tech spec

review checklist

Review TS andtest cases

Sign off TS and test cases

Output Baseline

technical spec Baseline test

cases

- 54 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Requirements management


Maintain configuration status report


Requirements allocation and understanding

Input — Requirement document (FS/TS)

Prepare communication log/issue log

Receive response

Output — Reviewed FS/TS

Receive clarifications

Revised FS/TS

- 55 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Software requirements

Software requirements in a nutshell

Business requirements

Vision and scope

User requirements

User casesFunctional requirements

Software requirements specification

System requirements

Constraints

Quality attributes

Other nonfunctional requirements

- 56 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

User requirements should be written in natural language, tables and diagrams

System requirements are intended to communicate the functions that the system should provide

System requirements may be written in structured natural language, or in a formal language

A software requirements document is an agreed statement of the system requirements

Requirements set out what the system should do and define constraints on its operation and implementation

Functional requirements set out services the system should provideNonfunctional requirements constrain the system being developed or

the development processUser requirements are high-level statements of what the system

should do

Key points

Q and A




Software testing techniques

- 59 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Dijkstra “Testing can show the presence of bugs, but not their absence!”

Independent testing is a necessary, but not sufficient condition for trustworthiness.

Good testing is hard and occupies 20% of the schedule.

Poor testing can dominate 40% of the schedule.

Test to assure confidence in operation; not to find bugs.

Software testing

- 60 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Various types of tests

Test phases

Un

it Te

st

Pa

cka

ge

d V

alid

atio

n/

Str

ing

Te

st

Sys

tem

Te

st

Inte

gra

tion

Te

st

Pe

rfo

rma

nce

Te

st

Op

era

tion

al T

est

Use

r Acc

ep

tan

ce T

est

De

plo

yme

nt T

est

Re

gre

ssio

n T

est

Sh

ake

ou

t Te

st

Err

or

Sce

na

rio T

est

Ad

-ho

c Te

st

Developmenttest phases Seven formal test phases

Supplementary test phases

- 61 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Testing phases

Requirements specification

System specification

System design Detailed design

Acceptance testSystem

integration test Subsystem

integration test

Acceptance test plan

System integration test

plan

Subsystem integration test

plan

Module and unit code and tess

Service

- 62 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Coverage based — All statements must be executed at least once

Fault based — Detect faults, artificially seed, and determine whether tests get at least X% of the faults

Error based — Focus on typical errors, such as boundary values (off by 1) or max elements in list

Black box — Function, specification based, test cases derived from specification

White box — Structure, program based, testing considering internal logical structure of the software

Stress based — No load, impulse, uniform, linear growth, exponential growth by 2’s

Testing approaches

- 63 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Error — Human action producing incorrect result

Fault is a manifestation of an error in the code

Failure — A system anomaly, executing a fault induces a failure

Validation “The process of evaluating a system or component during or at the end of development process to determine whether it satisfies specified requirements”

Certification “The process of assuring that the solution solves the problem

Testing approaches (cont.)

- 64 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Test process

Input Subset of input

Subset of input Execute

Expected output

Actual output Testresults

Execute

Program or doc

Prototype or model

Test strategy

Compare

- 65 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Testing provokes failure behavior — A good strategy for fault detection, but does not inspire confidence

User wants failure free behavior — High reliability

Automatic recovery minimizes user doubts

Test team results can demoralize end users, so report only those impacting them

A project with no problems is in deep trouble

Fault detection versus confidence building

- 66 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Review or inspection to check that all aspects of the system have been described– Scenarios with prospective users resulting in functional tests

Common errors in a specification:– Missing information

– Wrong information

– Extra information

Testing requirements

- 67 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Features — Requirements relate to observable system/product features

Source — Source for each requirement

Dependency — Relation of requirements to each other

Subsystem — Requirements by subsystem

Interface requirements relation to internal and external interfaces

Traceability tables

- 68 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Traceability table: Pressman

S01 S02 S03

R01 X

R02 X X

R03… XReq

uire

men

t

Subsystem

- 69 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Test design document specifies for each software feature the details of the test approach and lists the associated tests.

Test case document lists inputs, expected outputs, and execution conditions.

Test procedure document lists the sequence of action in the testing process.

Test report states what happened for each test case. Sometimes, these are required as part of the contract for the system delivery.

In small projects many of these can be combined.

Test documentation

- 70 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Reading — Peer reviews (best and worst technique)

Walk-through and inspections

Correctness proofs

Stepwise abstraction from code to specification

Human static testing

- 71 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Sometimes referred to as Fagan inspections

Basically a team of about four folks examines code, statement by statement– Code is read before meeting

– Meeting is run by a moderator

– Two inspectors or readers paraphrase code

– Author is silent observer

– Code analyzed using checklist of faults: wrongful use of data, declaration, computation, relational expressions, control flow, and interfaces

Results in problems identified that author corrects and moderator re-inspects

Constructive attitude essential; do not use for programmer’s performance reviews

Inspections

- 72 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Guided reading of code using test data to run a “simulation”

Generally less formal

Learning situation for new developers

Parnas advocates a review with specialized roles where the roles define questions asked - proven to be very effective reviews

Nondirective listening

Walk- through

- 73 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Inspections can be 20 times more efficient than testing.

Code reading detects twice as many defects/hour as testing.

80% of development errors were found by inspections.

Inspections resulted in a 10 times reduction in cost of finding errors.

The value of inspections/walk-through (Humphrey 1989)

- 74 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Top-down and Bottom-up (Humphrey 1989)

Bottom-up Top-down

Major features Allows early testing

Modules can be integrated in various clusters as desired

Major emphasis is on module functionality and performance

The control program is tested first

Modules are integrated one at a time

Major emphasis is on interface testing

Advantages No test stubs are needed

It is easier to adjust staffing needs

Errors in critical modules are found early

No test drivers are needed

The control program, plus a few modules forms a basic early prototype

Interface errors are discovered early

Modular features aid debugging

Disadvantages Test drivers and harness are needed

Many modules must be integrated before a working program is available

Interface errors are discovered late

Test stubs are needed

The extended early phases dictate a slow staff buildup

Errors in critical modules at low levels are found late

- 75 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Testing GUIs

Testing with client/server architectures

Testing documentation and help facilities

Testing real-time systems

Acceptance test

Conformance test

Some specialized tests

- 76 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Before you reuse software look below the surface.

Lack of functionality

No support

Hidden costs

Poor documentation

Poor performance

Vendor instability

Lessons learned

- 77 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Customer interests

Features

Price

Schedule

Reliability

Response time

ThroughputInst

alla

tio

n

Before After

- 78 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Why bad things happen to good systems

Customer buys off-the-shelf

System works with 40%-60% flow- through

Developers complies

with enhancements

Customer refuses critical billing module

Customer demands 33 enhancements and tinkers with database

Unintended system consequences

Bu

t

Q and A

- 80 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx


Software configuration management



- 81 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Definition:

A set of management disciplines within the software engineering process to develop a baseline.

Description:

Software configuration management encompasses the disciplines and techniques of initiating, evaluating, and controlling change to software products during and after the software engineering process.

What is software configuration management?

- 82 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Multiple developers are working at the

same time...

What happened to this piece of code?

It worked yesterday!

How do I make sure that the right changes go into

the release?

What happened to the fix I added to

this code last week?

A bug, I cannot reproduce it.

Configuraiton management

How can I authorize access to the work

products?

Why configuration management ?

Problems

- 83 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Functions in configuration management

Configurationmanagement

process

Plan and perform for configuration audit

Verify with physical CI's Report and closure of

audit

ControlStatus

accounting

Verification Identification

Planning

CI identification Base lining

Adding of new CI's Update CI attributes Control changes

CI status update CI status tracking CI status reporting

Scoping Procedure definition Roles and responsibility Directory structure and

access definition

- 84 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Configurable Item (CI) – An aggregation of work products that is designated for configuration management and treated as a single entity in the configuration management process. Common CIs:– Process-related documentation (plans, standards, and procedures)

– Engineering documents and work products (requirements, design, code units, and test cases)

– Tools (compilers and other support tools)

– Receivables (customer- supplied items)

– System build for the software test activity or delivery

Baseline – Set of specifications or work product that has been formally reviewed and agreed upon. Baselines thereafter serve as the basis for further development and can be changed only through formal change control procedures.

Basic definitions

- 85 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Naming convention – A unique identification given to each configuration item. Example – <project name>_<doc name>

Version – Version defines unique number and status of the document. – All the document shall be versioned as m.n. where m is the numeric starting

with 1, indicating release version numbers. n is numeric, starting with 0, indicating the minor version number.

– Once document gets released,versioning will be done on the basis of defined changes (major/minor).

Basic definitions (cont.)

- 86 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

CI identification

- 87 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

CI identification

Configuration identification step involves identification of:– CI to be controlled

– Categorization of CI

– Identification of controls for selected CI's

– Baseline of CI's if available

– Preparation of configuration register with CI details

Functions in configuration management (cont.)

- 88 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Configuration control

- 89 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Configuration change control – change management

Changes can be triggered by any one of the following:– Requirement change request

– Problem report

– Defect(s)

All change requests are logged in XD portal in case of EA projects. TI projects uses CR log for the same.

Impact analysis will be done using XD portal for EA projects and CR log for TI projects.


- 90 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx


Approve CR (SCCB)

Rejected?Receive change

Request(PM)

Conduct impact analysis (TL/PM)

Close CR (TL/PM)

Plan for change Implementation

(PM)

No

Yes

Item already

configured?

Retrieve items (CM)

Verify change and update baseline

library (PM)

Update configuration status report/XD

portal

Monitor changeImplementation

(TL/PM)

Review/ test the change implementation

Yes

No

Yes

Send CR back to initiator (TL/PM)

Open deferred CR (TL/PM)

No

Label/version the artifact to be

delivered

Configuration change control – change management (flow)

Assign responsibilities to change the items affected

(PM)

- 91 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Configuration change control – version control

Version number should reflect the impact of changes. There can be major or minor changes.

Major change– Change of complete text or major part of the text.

– Defining new responsibilities and activities.

Minor changes– Typographical errors.

– Incorrect reference to related documents.

– Addition/deletion of references.

– Change of sequence of activities, etc.


- 92 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Software configuration management can be staffed in several ways:

A single team performs all software configuration management activities for the whole organization.

A separate configuration management team is set up for each project.

All the software configuration management activities are performed by the developers themselves.

Mixture of all of the above.

Managing software configurations

- 93 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Bugs that have been corrected reappear.

Previous releases of software cannot be rebuilt.

Previous releases of software cannot be found.

Files get lost.

Files are “mysteriously” changed.

The same or similar code exists multiple times in different projects.

Two developers accidentally change the same file concurrently.

Symptoms of poor configuration management

- 94 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

Benefits

Prevent unauthorized access to project work products

Coordinate, track, and manage change activities

Ability to deliver revisions, updates, and cross-platform versions faster

Less time wasted fixing old code

Confidence that each release addresses all the requested changes

Why configuration management ? (cont.)

Do configuration right, or forget about improving development process.

- 95 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

What is a baseline?

Baseline – Set of specifications or work product that has been formally reviewed and agreed upon. Baselines thereafter serve as the basis for further development, and can be changed only through formal change control procedures.

Questions?

- 96 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

List 5 examples of CI from software project?

PMP

TD

UTP

FSD

SRS

Questions?

- 97 - Cam

pus_

Intr

oduc

tion

to S

DLC

and

SE

Con

cept

s.pp

tx

What is SCCB?

Software change/configuration control board

Questions?

Q and A

Copyright © 2008 Deloitte Development LLC. All rights reserved.

Documents

SDLC and SE Concepts