(SDLC)

UNIT OBJECTIVE
• Understand the influences on a project
• Understand what a software process is
• Understand two common models
WHAT EACH PARTY CONTROLS

Client Side Tech Side

Every software project has three client The tech team has three controls
controls
Process

People Technology

Cost Time

Functionality

Software Engineering is about managing the client side and defining the tech side
while managing risk.
MOST EVERYTHING INVOLVES TEAMS

• The effectiveness of the team relates directly to success

• Working with and within teams requires extra effort for

• Communication
• Ever play the operator game?
• Documentation
• Tooling
• Hand-offs (process exchanges or role turn-over)

• Remember, you cannot read other people’s minds

CIRCLE OF LIFE

1. Teams come, operate, evolve or disband

2. People come, grow, and

eventually move on

3. Projects come, grow, enter stasis or

evolve

Your project has to accommodate these

facts of project life
PROJECT INFLUENCES
• Scale
• Affects the ability to know “everything”
• Complexity becomes a critical factor, if it wasn’t already

• Legacy
• Rarely is everything from scratch
• Being able to extend others’ work is essential
PROFESSIONALISM
Personal Ethics Effects
• Confidentiality • Developers and administrators may have access to
• Respecting confidences of employers or clients highly confidential information
regardless if there is a formal agreement
• Competence
• Accurately reflect what you can do and accept
• Systems that do not work can destroy a company
only work that is within your competence
• Intellectual Property • IPR violations can be result in fines or cease and
• Protecting the IP of employers and clients desist orders
• Misuse
• Do not use skills or resources inappropriately
• System abuse can paralyze a company
PROCESS

• noun pro·cess
a series of actions that produce
something or that lead to a particular result
http://www.merriam-webster.com/dictionary/process

Typical “Good” Qualities

Effective Actually Used

Efficient Reusable
Relevant Managed
Valid Measurable
Usable
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
• Purpose
• Lead to good software
• Reduce risk
• Enable visibility and measurement
• Enable teaming

• Key attributes
• Outcomes/results of processes are key deliverables or products
• Roles are clear
• Pre and post conditions are understood and held true
KEY ELEMENTS IN ANY SDLC

1. Feasibility

2. Specification
3. Architecture and Design
4. Development
5. Validation

6. Evolution/Maintenance

The devil is in the details of how the steps are organized and executed
PROCESS MODELS
WATERFALL MODEL (CIRCA 1968)
• Sequential process phases
• One step completes before next one starts Feasibility
Feasibility Analysis

• Rational process
• Enables careful planning
• This is how construction is done. Requirement
Specification
Documents
• Good for
• some piece of the system cannot be easily changed (e.g.
hardware)
• where explicit and exhaustive testing is required
before launch Architecture Design
& Design Documents

• Challenges
• Heavyweight process
• Meaning the process is followed systematically Development Code
and completely (slow)
• Specification is a negotiation process
• Specifications precede the system
Test plans
• World rarely is known upfront and even Validation
and results
more rarely stays fixed
• Hard to adapt to upstream changes once the
step completes
Evolution &
Updates
Maintenance
WATERFALL MODEL
• Real projects rarely follow a sequential flow

• Hard to state all requirements explicitly

• No maintenance or evolution involved

• Customer must have patience

• Any blunder can be disastrous

BOEHM’S FIRST LAW

Errors are most frequent during

requirements and design activities

and are more expensive the later

they are removed.
WHAT THIS MEANS IN PRACTICE

Relative cost of an error depending on when it is discovered

300

250

200
Cost

150

100

50

0
Requirements Design Code Unit Test System Test Field
Project Phase
ITERATIVE MODELS
• System is created by successive
versions.
• Go through each process step, then Feasibility
iterate • Feasibility
Analysis
• Similar to how you are taught to write a paper
• Includes feedback between steps
Specification
• Lowers the cost of implementing Evolution & • Requirem
requirement changes Maintenance ent
Document
• Allows some client/user feedback to be
considered
• Smaller sized steps means delivery of
something comes sooner
• Value is created earlier Validation Architecture
• It may not be clear where in the • Test plan & Design
and • Design
program the project is results Document
• Changes can lead to messy designs
and implementations Developmen
t
• Code
AGILE MANIFESTO

Individuals and interactions over

processes and tools • This is a response to over-zealous and
rigid process mongering
Working software over comprehensive
documentation
• Emphasizes getting to the right result
Customer collaboration over contract versus creating a lot of useless
negotiation documents, over-planning, or blindly
following process
Responding to change over following a
plan • However, this is NOT a repudiation
of documentation or plans.
That is, while there is value in the items
on
the right, we value the items on the left
more.

http://agilemanifesto.org/
 AGILE IS A SET OF SDLC APPROACHES
Glossary:
• RUP – Rational Unified Process
• https://en.wikipedia.org/wiki/Rational_Unified_Pro
cess
• XP – Extreme Programming
• https://en.wikipedia.org/wiki/Extreme_programmin
g
• DSDM - Dynamic
systems development
method
• https://en.wikipedia.org/wiki/Dynamic_systems_dev
elopment_method
• FDD - Feature-driven development
• https://en.wikipedia.org/wiki/Feature-
driven_development

Borrowed from Haresh Karkar

http://www.slideshare.net/hareshkarkar/overview-of-agile-methodology
AGILE
• Emphasis
• producing small increments of software in a reasonably short time frame
• Entire process is run during a sprint
• Sprint results are deployed

• Antithesis of Waterfall
• Plans develop incrementally and evolve
• Client collaboration versus client negotiation
• Specification follows from working system, not the reverse
• Immediate feedback from deployment
• Responding to change rather than following a plan
• Enhancements, new features, and bug fix are all prioritized as candidates for focus
during next sprint
• Emphasis on keeping scope small
• Although the impact of changes will grow over time

“[…] is like driving at night in the fog. You can only see as far as your headlights, but
you can make the whole trip that way.”
— E.L. Doctorow, Writers At Work: The Paris Review Interviews
SCRUM

Emphasis on small, semi-independent teams ideally delivering discrete pieces of a system

Team ideally has total responsibility for the components it produces

Leads to devOps models

1. Team
• Small, cross-functional, self-organizing units

2. Scope
• Small deliverable scope delivered in consensus priority order
• Priorities can be adjusted (typically at sprint start)

3. Timeline
• Small iterations (2-3 weeks is typical) emphasizing delivery at the end
HOW SCRUM TYPICALLY OPERATES

A sprint is one iteration through the process

The backlog contains all the work needing doing

• Includes features and other tasks

User stories describe the function from the consumer’s perspective

 The User may be another software component/system.

• You estimate how much work/time each User Story will take
• The client provides her view of the priorities in the backlog.
• The tech team reassesses priorities to allow for dependencies or difficulties
• The backlog is now a roadmap for the sprint or day within the sprint

Daily stand-ups to discuss progress and plans for what is next

• A scrum-master choreographs the sprint and keeps the team focused and distractions at bay.
SCRUM

In rugby, a scrum is the way you restart the game after a minor infraction.
TEST-FIRST DESIGN

• Puts test specification as the critical

design activity Defines
Specification (non)function
• Understands that deployment objectives
comes when the system passes
testing Defines
acceptance Informs Design
designs objectives

• Clearly defines what success means Defines

system
• No more guesswork as to Tests
what “complete” means

System Development
Verified under test
• The act of defining tests requires one system
to understand how the solution
works Deployment
KEY CONCERNS DRIVING IN SELECTING A PROCESS

• What is the net tolerance for finding

errors in deployment?
Typical view of
waterfall
• How fast is the market moving?
Typical view of
iterative
• Are the teams experienced with a
particular process?

• Is the contract fixed and firm?

• When do the clients expect to see

something?
Adapted from
http://www.agilemodeling.com/essays/costOfChange.htm
Copyright © 2003 Scott W. Ambler
EVEN WITH ADVANCES IN PROCESS, PROJECT SUCCESS
REMAINS RISKY

Pessimist View Optimist View

Lean

Iterative

Agile

Ad-Hoc

All projects
Traditional

0 23 45 68 90 113
0% 25% 50% 75% 100%
Successful Challenged Failed
Success Challenged Failed

Standish Group (UK), Chaos Study, 1995 Dr. Dobb’s Journal 2013 IT Project Success Survey posted
at www.ambysoft.com/surveys/
WALKING THE SDLC
STEPS
FEASIBILITY

• Determines if a project should be attempted

• Usually done once at the beginning by senior (trusted) team members

Feasibility study is a proposal

• Does not require prototyping, but often includes it

The decision maker is the audience

• This person may not be sufficiently technical
• In large organizations, this can be a walk-up multiple hierarchies

• Budget processes and staffing usually follow from a positive response

• Two outcomes
1. Yea
2. Nay
WHAT GOES INTO A FEASIBILITY STUDY

1. Recommendation

2. Technology
3. Economic
4. Legal
5. Operational
6. Schedule
UNCERTAINTY MAKES THIS VERY HARD

Challenges Mitigations
• Clients are unsure what they need at a
useful level of detail • Experience can guide process
• But the most experienced people
• Benefits are hard to quantify may not be the most technically
current
• Impacts and recognizing unintended
consequences is even harder to quantify
• Solicit support and build interest for the
• Approach is often based on very rough
guesses project
• Beware of irrational enthusiasm
• Organizational structures may need change • Leads to unreasonable expectations
• Senior executives rarely forget your
• Assumptions may be faulty
promises
THE BOSS’ VIEW
(ADAPTED FROM BILL ARMS)

The Main Line Additional Considerations

• Senior member(s) of the client’s organization
decide whether to begin a major software project.
• Do I trust this team?
• Have we tried this before?
• Client: who is this project for?
• Market maker? Fast follower?
• Scope: is it well defined? Where are there
dependencies and on whom? • Is this really worth investing in?
• Are there IPR issues?
• Benefits: are the benefits real and quantifiable? Do I
trust these numbers? • License dependencies?
• Technical: Is the project possible?
• Can this organization pull this off?
• Is there at least one technical way to carry out the project? • Management capabilities
• Resources: what are the estimates of staff, • Development capabilities
time, equipment, etc.?
• Operational capabilities
• What are the options if the project is not done? • Sales capabilities