SDLC and SE Concepts

Introduction to SDLC and SE Concepts
New hire orientation program
Deloitte Consulting LLP
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
-2-
duction to SDLC and SE Concepts.pptx
Timelines
Introduction to SDLC and SE

Concepts
Introduction and getting started

Date : 6th July 2009
Software
Software is the collection of.
Computer programs
Procedures
Rules
Data
Associated documentation
-4-
A definition of process
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:
Process is one of three quality leverage points
People
Outputs
Process
Technology
-5-
Inputs
Software engineering
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).
-6-
Application of a systematic, disciplined, and quantifiable approach to

the development, operation, and maintenance of a software(IEEE93).
Goals of software engineering

High-quality product
-7-
At low cost
Software development models

Waterfall model
Prototyping model
Iterative enhancement model
-8-
Spiral model
Waterfall model
Sequential
Enforces complete requirements specification
Cannot proceed to the next phase till the current phase is over
Does not model the reality
-9-
Earliest availability of the working model Midway through the project
Prototyping model
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.
- 10 -
Danger of mistaking the prototype as the real software.
Iterative model
Software developed and delivered in increments.
Each increment adds some functionality.
- 11 -
At each step, enhancements based on clients feedback analysis and

design are carried out.
Spiral model
Risk driven
Iterative steps
Planning
Risk analysis
Development
Customer evaluation
Provides early indication of risks
- 12 -
Requires high management skills
Programmer versus software engineer

Individual with good skills
Part of a team
Programming-in-the-small
Programming-in-the-large
Knowledge on
Design approaches
Data structures
Algorithms
OO, modules, etc.

Top-down/bottom-up
Fluent in several programming

languages
Translates requirements into

specifications
May lack formal training
Familiarity in multiple application

areas
Converses with users
Sees big picture
Can model application
Good communication and
interpersonal skills
- 13 -
Minimal exposure to CS
What are the key challenges facing software engineering?

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
- 14 -
There is increasing pressure for faster delivery of software
Q and A

SDLC Jargon made easy

Agenda
What is SDLC?
SDLC phases
SDLC models
SDLC key success factors
References
Summary
Q and A
What is SDLC?
An acronym for system development life cycle.
A set of stages/phases that all information systems go through in
their lifecycle.
- 18 -
A conceptual model used in system development.
SDLC phases
The generic phases of SDLC are:
Analysis
Design
Build/test
Deployment
- 19 -
Maintenance
SDLC phases (cont.)
Design
Build/test
Design
Specification
Architecture
Scope
Deployment
Business
Requirement
Proof of
Master Test
Requirements
Specification
Concept
Strategy
Product
Cases
- 20 -
Build
Deployment
Design Test
Selection
Maintenance
Maintenance
Execute
Test
Analysis
Analysis
Design
Build/test
Deployment
Maintenance
Analysis phase
The analysis phase involves:
Study the clients 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.
- 21 -
Get sign-off from the authorized client personnel.
Analysis
Design
Build/test
Deployment
Maintenance
Design phase
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.
- 22 -
Get sign-off from the authorized client personnel.
Analysis
Design
Build/test
Deployment
Maintenance
Build/test phase
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.
- 23 -
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.
Analysis
Design
Build/test
Deployment
Maintenance
Deployment phase
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.
- 24 -
Help the users to increase their comfort level in using the new system.
Analysis
Design
Build/test
Deployment
Maintenance
Maintenance phase
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.
- 25 -
Make changes to accommodate customers functional or performance

enhancement requirements.
SDLC models
The more popular SDLC models are:
The linear sequential model.
The prototyping model.
The rapid application development (RAD) model.
- 26 -
The following few slides explain each of these models.
Linear sequential model

The linear sequential model
Analysis
Design
Build/test
Deployment
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.
- 27 -
Is the oldest and most widely used model.
Linear sequential model (cont.)

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.
- 28 -
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.
Prototyping model
Listen to customer
Customer
test-drives
prototype
- 29 -
Build/revise
prototype
Prototyping model (cont.)

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.
- 30 -
Pilot system will further lead to detailed development life cycle.
Prototyping model (cont.)

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.
- 31 -
Less/no focus on quality and hence may create more issues in the final
system.
RAD model
Modelling
(business,
data, and
process)
Application
generation
Testing and
turnover
Team 1
New
system
Team 2
- 32 -
Team 3
RAD model (cont.)

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.
- 33 -
Demands well-understood requirements and highly scalable scope.
RAD model (cont.)

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.
- 34 -
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.
SDLC key success factors

Planning and scheduling
Document reviews
Following development standards
Code reviews and walk-through
Configuration management (version control)
Issue tracking
Testing and defect prevention
- 35 -
Change management process
References
Deloitte KX Portal https://kx.deloitteresources.com/default.aspx
Deloitte Learning Center https://www.deloittenet.com/dtlearning/default.asp
Books
Software Engineering A Practitioners 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/
- 36 -
Summary
Define SDLC
SDLC phases
SDLC models
Key success factors
- 37 -
References
Q and A

Requirement engineering process

Topics
Why requirement engineering?
Types of requirement
Users of requirement
Requirement Measure
Guidelines for writing requirement document
Requirement management flow
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
- 41 -
Why requirement engineering
- 42 -
Users perception of requirement
- 43 -
Designers perception of requirement
- 44 -
Developers perception of requirement
Types of requirements 1
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
- 45 -
A detailed software description, which can serve as a basis for a design or

implementation. Written for developers
Types of requirements 1 (cont.)

Client managers
User requirements
System end users

Client engineers
Contractor managers
System architects
System requirements
System end users

Client engineers
System architects
Software developers
Client engineers (perhaps)
System architects
Software developers
- 46 -
Software design
specification
Types of requirements 2
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
- 47 -
Requirements that come from the application domain of the system and that
reflect characteristics of that domain
Different users of requirement document

System customers
Specify the requirements and read them to check that they meet their needs.
They specify changes to the requirements
Managers
Use the requirements document to plan a bid for the system and to plan the
system development process
System test engineers
System maintenance
engineers
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
- 48 -
System engineers
Requirements measures
Property
Speed
Measure
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
Percentage of target dependent statements
Number of target systems
- 49 -
Portability
Guidelines for writing requirements

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
- 50 -
Characterize responses to unexpected events
Guidelines for writing requirements (cont.)

Requirements document structure.
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
- 51 -
RM process Functional spec (FS) preparation

Alternative solutions
(for decision making)
Input
Business
requirement
Review
requirements
Create FS
Output
Baseline
functional specs
Sign off FS
Review FS
- 52 -
For changes, refer to change control procedure
RM process Technical spec (TS) preparation

Input
Functional spec
Tech spec
review checklist
Initial object
review/
requirements
understanding
Output
Baseline
technical spec
Baseline test
cases
Sign off TS and

test cases
Create TS and
test cases
Review TS and
test cases
- 53 -
Requirements management
Input
Requirement
document
(FS/TS)
Requirements
allocation and
understanding
Maintain
configuration
status report
Revised FS/TS
Receive
clarifications
Prepare
communication
log/issue log
Receive
response
- 54 -
Output
Reviewed FS/TS
Software requirements in a nutshell

Software requirements
Vision and
scope
User
requirements
User cases
Functional
requirements
System
requirements
Software
requirements
specification
Quality
attributes
Other
nonfunctional
requirements
Constraints
- 55 -
Business
requirements
Key points
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 provide
User requirements are high-level statements of what the system

should do
- 56 -
Nonfunctional requirements constrain the system being developed or

the development process
Q and A

Software testing techniques

Software testing
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.
- 59 -
Test to assure confidence in operation; not to find bugs.
Ad-hoc Test
Error Scenario Test
Shakeout Test
Regression Test
Deployment Test
Seven formal test phases
- 60 -
User Acceptance Test
Operational Test
Performance Test
Development
test phases
Integration Test
System Test
Packaged Validation/
String Test
Unit Test
Various types of tests

Test phases
Supplementary
test phases
Testing phases
System
specification
Acceptance test
plan
Service
System design
System
integration test
plan
Acceptance test
Subsystem
integration test
plan
System
integration test
- 61 -
Detailed design
Module and unit

code and tess
Subsystem
integration test
Requirements
specification
Testing approaches
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
- 62 -
Stress based No load, impulse, uniform, linear growth, exponential

growth by 2s
Testing approaches (cont.)

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
- 63 -
Certification The process of assuring that the solution solves the

problem
Test process
Program or doc
Prototype
or model
Subset of input
Expected output
Test
strategy
Subset of input
Compare
Execute
Actual output
Test
results
Execute
- 64 -
Input
Fault detection versus confidence building

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
- 65 -
A project with no problems is in deep trouble
Testing requirements
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:
- 66 -
Missing information
Wrong information
Extra information
Traceability tables
Features Requirements relate to observable system/product features
Source Source for each requirement
Dependency Relation of requirements to each other
Subsystem Requirements by subsystem
- 67 -
Interface requirements relation to internal and external interfaces
Traceability table: Pressman

Subsystem
R01
R02
R03
S02
S03
- 68 -
Requirement
S01
Test documentation
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.
- 69 -
In small projects many of these can be combined.
Human static testing

Reading Peer reviews (best and worst technique)
Walk-through and inspections
Correctness proofs
- 70 -
Stepwise abstraction from code to specification
Inspections
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
- 71 -
Constructive attitude essential; do not use for programmers

performance reviews
Walk- through
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
- 72 -
Nondirective listening
The value of inspections/walk-through (Humphrey 1989)

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.
- 73 -
Inspections resulted in a 10 times reduction in cost of finding errors.
Top-down and Bottom-up (Humphrey 1989)

Bottom-up
Major features
Advantages
Top-down
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
No test stubs are needed

It is easier to adjust staffing needs
No test drivers are needed

The control program, plus a few
modules forms a basic early
prototype
Errors in critical modules are found early
Interface errors are discovered

early
Disadvantages
Test drivers and harness are needed
Test stubs are needed
Many modules must be integrated before

a working program is available
The extended early phases dictate

a slow staff buildup
Interface errors are discovered late
Errors in critical modules at low

levels are found late
- 74 -
Modular features aid debugging
Some specialized tests

Testing GUIs
Testing with client/server architectures
Testing documentation and help facilities
Testing real-time systems
Acceptance test
- 75 -
Conformance test
Lessons learned
Before you reuse software look below the surface.
Lack of functionality
No support
Hidden costs
Poor documentation
Poor performance
- 76 -
Vendor instability
Customer interests
Price
Schedule
- 77 -
Reliability
Response time
Throughput
Features
After
Installation
Before
Why bad things happen to good systems

Customer buys off-the-shelf
Customer refuses critical billing

module
with enhancements
Customer demands 33
enhancements and tinkers with
database
Unintended system
consequences
- 78 -
Developers complies
But
System works with 40%-60%

flow- through
Q and A

Software configuration management
- 80 -

What is software configuration management?

Definition:
A set of management disciplines within the software engineering process
to develop a baseline.
Description:
- 81 -
Software configuration management encompasses the disciplines and

techniques of initiating, evaluating, and controlling change to software
products during and after the software engineering process.
Why configuration management ?
How do I make
sure that the right
changes go into
the release?
Problems
Multiple developers
are working at the
same time...
What happened to
the fix I added to
this code last
week?
How can I authorize

access to the work
products?
Configuraiton management
- 82 -
What happened to
this piece of code?
It worked
yesterday!
A bug, I cannot
reproduce it.
Functions in configuration management
Scoping
Procedure definition
Roles and responsibility
Directory structure and
access definition
Planning
Verification
Configuration
management
process
Status
accounting
Identification
CI identification
Base lining
Control
CI status update
CI status tracking
CI status reporting
Adding of new CI's

Update CI attributes
Control changes
- 83 -
Plan and perform for

configuration audit
Verify with physical CI's
Report and closure of
audit
Basic definitions
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
- 84 -
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 (cont.)

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.
- 85 -
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).
- 86 duction to SDLC and SE Concepts.pptx
CI identification
Functions in configuration management (cont.)

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
- 87 -
- 88 duction to SDLC and SE Concepts.pptx
Configuration control

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.
- 89 -
Impact analysis will be done using XD portal for EA projects and CR log
for TI projects.

Configuration change control change management (flow)
Receive change
Request
(PM)
Yes
No
Conduct impact
analysis (TL/PM)
Approve CR
(SCCB)
Rejected?
No
Yes
Update configuration
status report/XD
portal
Open deferred
CR (TL/PM)
Send CR back to
initiator (TL/PM)
Assign responsibilities to
change the items affected
(PM)
Verify change and

update baseline
library (PM)
Review/
test the change
implementation
Close CR (TL/PM)
Monitor change
Implementation
(TL/PM)
No
Item
already
configured?
Plan for change

Implementation
(PM)
Label/version the
artifact to be
delivered
Retrieve items (CM)
- 90 -
Yes

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.
- 91 -
Managing software configurations

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.
- 92 -
Mixture of all of the above.
Symptoms of poor configuration management

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.
- 93 -
Two developers accidentally change the same file concurrently.
Why configuration management ? (cont.)

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
- 94 -
Do configuration right, or forget about improving

development process.
Questions?
What is a baseline?
- 95 -
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?
List 5 examples of CI from software project?
PMP
TD
UTP
FSD
- 96 -
SRS
Questions?
What is SCCB?
- 97 -
Software change/configuration control board
Q and A
- 99 -
Copyright 2008 Deloitte Development LLC. All rights reserved.

SDLC and SE Concepts

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDLC and SE Concepts

Uploaded by

Copyright:

Available Formats

Introduction to SDLC and SE Concepts

New hire orientation program

Deloitte Consulting LLP

Introduction and getting started

System development life cycle

duction to SDLC and SE Concepts.pptx

Introduction to SDLC and SE

Deloitte Consulting LLP

duction to SDLC and SE Concepts.pptx

duction to SDLC and SE Concepts.pptx

duction to SDLC and SE Concepts.pptx

Application of a systematic, disciplined, and quantifiable approach to

Goals of software engineering

duction to SDLC and SE Concepts.pptx

Software development models

duction to SDLC and SE Concepts.pptx

duction to SDLC and SE Concepts.pptx

Earliest availability of the working model Midway through the project

duction to SDLC and SE Concepts.pptx

Danger of mistaking the prototype as the real software.

duction to SDLC and SE Concepts.pptx

At each step, enhancements based on clients feedback analysis and

Provides early indication of risks

duction to SDLC and SE Concepts.pptx

Requires high management skills

Programmer versus software engineer

OO, modules, etc.

Fluent in several programming

Translates requirements into

May lack formal training

Familiarity in multiple application

duction to SDLC and SE Concepts.pptx

What are the key challenges facing software engineering?

duction to SDLC and SE Concepts.pptx

There is increasing pressure for faster delivery of software

Introduction to SDLC and SE Concepts

Deloitte Consulting LLP

duction to SDLC and SE Concepts.pptx

A conceptual model used in system development.

duction to SDLC and SE Concepts.pptx

SDLC phases (cont.)

duction to SDLC and SE Concepts.pptx

duction to SDLC and SE Concepts.pptx

Get sign-off from the authorized client personnel.

duction to SDLC and SE Concepts.pptx

Get sign-off from the authorized client personnel.

duction to SDLC and SE Concepts.pptx

The testing activities involve:

duction to SDLC and SE Concepts.pptx

duction to SDLC and SE Concepts.pptx

Make changes to accommodate customers functional or performance

duction to SDLC and SE Concepts.pptx

The following few slides explain each of these models.

Linear sequential model

duction to SDLC and SE Concepts.pptx

Is the oldest and most widely used model.

Linear sequential model (cont.)

duction to SDLC and SE Concepts.pptx

duction to SDLC and SE Concepts.pptx

Prototyping model (cont.)

duction to SDLC and SE Concepts.pptx

Pilot system will further lead to detailed development life cycle.

Prototyping model (cont.)

duction to SDLC and SE Concepts.pptx