Software Engineering

Session 2 – Main Theme

Software Development Lifecycles (SDLCs)
Dr. Jean-Claude Franchitti

New York University

Computer Science Department
Courant Institute of Mathematical Sciences

Presentation material partially based on textbook slides

Software Engineering: A Practitioner’s Approach (7/e)
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009

Agenda

11 Session
Session Overview
Overview

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles (SDLCs)
(SDLCs)

33 Summary
Summary and
and Conclusion
Conclusion

2
What is the class about?

ƒ Course description and syllabus:

» http://www.nyu.edu/classes/jcf/g22.2440-001/
» http://www.cs.nyu.edu/courses/spring10/G22.2440-001/

ƒ Textbooks:
» Software Engineering: A Practitioner’s Approach
Roger S. Pressman
McGraw-Hill Higher International
ISBN-10: 0-0712-6782-4, ISBN-13: 978-00711267823, 7th Edition (04/09)
» http://highered.mcgraw-hill.com/sites/0073375977/information_center_view0/
» http://highered.mcgraw-
hill.com/sites/0073375977/information_center_view0/table_of_contents.html

Agenda

ƒ Software Engineering Detailed

ƒ Process Models
ƒ Agile Development
ƒ Software Engineering Knowledge
ƒ Roles and Types of Standards
ƒ ISO 12207: Life Cycle Standard
ƒ IEEE Standards for Software Engineering Processes and
Specifications
ƒ Summary and Conclusion
ƒ Readings
ƒ Assignment #1
ƒ Course Project

4
Icons / Metaphors

Information

Common Realization

Knowledge/Competency Pattern

Governance

Alignment

Solution Approach

55

Agenda

11 Session
Session Overview
Overview

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles (SDLCs)
(SDLCs)

33 Summary
Summary and
and Conclusion
Conclusion

6
Agenda – Software Engineering Fundamentals

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles SDLCs
SDLCs

Software Engineering Detailed

Process Models

Agile Development

Software Engineering Knowledge

Roles and Types of Standards

What is a SDLC

System Development Life Cycle:

ƒ It is about developing a software-driven
solution to a business problem
ƒ It concerns a process which takes from
two months to two years
ƒ This is called a System Development Life
Cycle but it should really be called a
(Business) Solution Development Life
Cycle

8
Software Engineering (1/2)

ƒ Some realities
ƒ A concerted effort should be made to understand the
problem before a software solution is developed
ƒ Design becomes a pivotal activity
ƒ Software should exhibit high quality
ƒ Software should be maintainable
ƒ The seminal definition
ƒ Software engineering is the establishment and use of sound
engineering principles in order to obtain economically
software that is reliable and works efficiently on real
machines

Software Engineering (2/2)

ƒ The IEEE definition

ƒ Software Engineering:
ƒ (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation,
and maintenance of software; that is, the application of
engineering to software
ƒ (2) The study of approaches as in (1)

10
A Layered Technology

tools

methods

process model

a “quality”
quality” focus

Software Engineering

11

A Process Framework

Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

12
Framework Activities

ƒ Communication
ƒ Planning
ƒ Modeling
ƒ Analysis of requirements
ƒ Design
ƒ Construction
ƒ Code generation
ƒ Testing
ƒ Deployment

13

Umbrella Activities

ƒ Software project management

ƒ Formal technical reviews
ƒ Software quality assurance
ƒ Software configuration management
ƒ Work product preparation and
production
ƒ Reusability management
ƒ Measurement
ƒ Risk management

14
Adapting a Process Model

ƒ The overall flow of activities, actions, and tasks and the

interdependencies among them
ƒ The degree to which actions and tasks are defined within each
framework activity
ƒ The degree to which work products are identified and required
ƒ The manner which quality assurance activities are applied
ƒ The manner in which project tracking and control activities are
applied
ƒ The overall degree of detail and rigor with which the process is
described
ƒ The degree to which the customer and other stakeholders are
involved with the project
ƒ The level of autonomy given to the software team
ƒ The degree to which team organization and roles are prescribed
15

The Essence of Practice

ƒ Polya* suggests:
1. Understand the problem (communication and analysis)
2. Plan a solution (modeling and software design)
3. Carry out the plan (code generation)
4. Examine the result for accuracy (testing and quality
assurance)
* http://www.stevemcconnell.com/rl-top10.htm

16
Understand the Problem

ƒ Who has a stake in the solution to the

problem? That is, who are the stakeholders?
ƒ What are the unknowns? What data, functions,
and features are required to properly solve the
problem?
ƒ Can the problem be compartmentalized? Is it
possible to represent smaller problems that
may be easier to understand?
ƒ Can the problem be represented graphically?
Can an analysis model be created?

17

Plan the Solution

ƒ Have you seen similar problems before? Are there

patterns that are recognizable in a potential solution?
Is there existing software that implements the data,
functions, and features that are required?
ƒ Has a similar problem been solved? If so, are
elements of the solution reusable?
ƒ Can subproblems be defined? If so, are solutions
readily apparent for the subproblems?
ƒ Can you represent a solution in a manner that leads
to effective implementation? Can a design model be
created?

18
Carry Out the Plan

ƒ Does the solution conform to the plan? Is

source code traceable to the design model?
ƒ Is each component part of the solution
provably correct? Has the design and code
been reviewed, or better, have correctness
proofs been applied to algorithm?

19

Examine the Result

ƒ Is it possible to test each component part of the

solution? Has a reasonable testing strategy
been implemented?
ƒ Does the solution produce results that conform
to the data, functions, and features that are
required? Has the software been validated
against all stakeholder requirements?

20
David Hooker’s General Principles*

ƒ 1: The Reason It All Exists

ƒ 2: KISS (Keep It Simple, Stupid!)
ƒ 3: Maintain the Vision
ƒ 4: What You Produce, Others Will Consume
ƒ 5: Be Open to the Future
ƒ 6: Plan Ahead for Reuse
ƒ 7: Think!

* http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment

21

Software Myths

ƒ Affect managers, customers (and other non-

technical stakeholders) and practitioners
ƒ Are believable because they often have
elements of truth,
but …
ƒ Invariably lead to bad decisions,
therefore …
ƒ Insist on reality as you navigate your way
through software engineering

22
How It all Starts

ƒ Every software project is precipitated by some

business need
ƒ The need to correct a defect in an existing application;
ƒ The need to the need to adapt a ‘legacy system’ to a
changing business environment;
ƒ The need to extend the functions and features of an
existing application, or
ƒ The need to create a new product, service, or system.

23

SDLC Characteristics

ƒ Whatever form it takes, it is always

followed by a maintenance cycle:
ƒ Maintenance is the most expensive part
ƒ If all the steps are done carefully maintenance is
reduced
ƒ For maintenance to be effective , documentation must
exist

24
Business Solution Characteristics

ƒ A software-driven solution consists of two

parts:
ƒ Model
ƒ Prototypes
ƒ Diagrams and supporting Documents
ƒ System
ƒ Hardware
ƒ Software

25

Some Definitions (1/3)

ƒ Prototype
ƒ An initial software-driven solution usually done with a
rapid development tool
ƒ Usually has limited functionality
ƒ Users can see results very quickly
ƒ Planning
ƒ The process of gathering what is needed to solve a
business problem
ƒ Includes a feasibility study
ƒ Includes project steps

26
Some Definitions (2/3)

ƒ Analysis
ƒ The process of determining detail requirements in the
form of a model
ƒ Design
ƒ The process of drawing blueprints for a new system
at a high-level first then at a detailed level
ƒ Construction
ƒ The actual coding of the model into a software
package
ƒ Uses one or more programming languages
ƒ Java
ƒ C#
ƒ C++
ƒ etc.

27

Some Definitions (3/3)

ƒ Implementation
ƒ Doing whatever is necessary to startup a system
ƒ Includes:
ƒ Database
ƒ Networks
ƒ Hardware configuration
ƒ Maintenance
ƒ Doing whatever is necessary to keep a system
running
ƒ Includes:
ƒ Repairs to correct errors
ƒ Rnhancements to accommodate changes in requirements

28
Deliverables

ƒ Deliverables consist mainly of diagrams and

their supporting documentation
ƒ For example:
ƒ Models that emphasize dynamics
ƒ Models that emphasize structure
ƒ Models can be used for specifying the outcome of
analysis
ƒ Models can be used for specifying the outcome of
design

29

Sample Deliverables – Planning (1/3)

ƒ Planning:
ƒ System Functions
ƒ A simple list of each requirement a system must do
ƒ For example:
ƒ record video rental
ƒ calculate fine
ƒ System Attributes
ƒ A simple property describing each requirement of a
system
ƒ For example:
ƒ record video rental under 15 seconds
ƒ calculate fine and return response in 5 seconds

30
Sample Deliverables – Planning (2/3)

ƒ Planning:

Environmental Diagram

Rent Video
Video Store
Information System Pay
Employees
Clerk

31

Sample Deliverables – Planning (3/3)

ƒ Planning:
ƒ Prototype
ƒ Recall it is a first system usually done with a rapid
development tool
ƒ Since users can see results very quickly they will
pay attention
ƒ Final product is seldom created in same tool as the
prototype

32
Sample Deliverables - Analysis

ƒ Analysis:
ƒ Use case
ƒ Shows the dynamics between the users (actors) of the
system and the system itself
ƒ This is a narrative representation
ƒ Conceptual Diagram
ƒ Shows the structure of the objects and their relationships
ƒ This is a graphical representation
ƒ System Sequence Diagram
ƒ Shows the dynamics between the users (actors) of the
system and the system itself
ƒ This is a graphical representation
ƒ Contracts
ƒ Shows the state of each object before each action
ƒ This is a narrative representation

33

Sample High-Level Architecture Design Conceptual Blueprint

e-Business Back-Office
Portal e-Business Services Systems
Users— Connectivity

Client

Web
Client
Administrator

Sales TradiDesk XML/Web

Enabling Component Legacy
User Facilities Manager Systems
VPN
Interfaces
Marketing

Facilitator

Phone

Visitor

Support
PDA
User XML-Based Application Data Legacy
Data Databases
Facilitator
Administrator

Data Repositories

34
Sample High-Level Architecture Design Logical Blueprint
Business e-Business
Users Connectivity e-Business Services Legacy Systems
Functions Portal

Facilitators Facilitator Interfaces University Intranet LAN

PBX-Based Service
PBX-Based Services Call Forwarding,
Teleconferencing, etc.
Presentation Enabling: Router
Authoring Portal Mgmt.
Posting
NT &
Component Manager
Unix Front Office Apps
Interface XML/Web Enabling Facilities Back-Office Systems
Application Server
Q&A Enabling:
University Front Office Apps Client Request Handler
Authoring
Internet or Chat Platform University Systems
Posting Firewall
Intranet LANs Educational Applications Application Logic Firewall
Professor (Custom Java Applications)

Win Ft Off. & Web Apps Client Request Handler Chatroom Component
2000
(via VPN) Maintenance Apps Subnet (within DMZ) Client Administration
Data Mining ChatUser Component
Software / Global Content Login, Authentification,
Web Server
Non-Repudiation
Monitoring / Backup Client & System
Administration Component
Telephony Svcs Proxy Server Registration Systems
Presentation Enabling:
Authoring Faxback
Web-Enabled Entitlement & Security
IVR
Applications Servlet Engine JSP Engine
Component Accounting Systems
Q&A Enabling: NT & Facilitator Application,
Unix Front Office Apps
Integration Channel, and Client/ Sales/Marketing Systems
System Admin Interfaces
System Support: Servlets/JSPs:
Monitoring University Business Intelligence
(Customer Analysis, Course Planning)
session hdlr Support Services Client Support Systtems
System Admin. Interne or SMIL presentation hdlr (carreer management, alumni
Intranet LANs Customer Care Services Q&A hdlr XML Core Services relations, library support, etc.)
Help Desk
Teaching (Call Center Support: Educational & Systems) XML MOM/POP hdlr (Doc Hdlr, Version Manager)
Assistant Win
etc.
Collaborative Applications
2000 (2D Avatars, Classroom Navigation, Chat, Events)
Ft Off. & Web Apps Session/State Mgmt. Internal Administration

University Internet LAN

(via VPN)
"Lights Out" Svcs System Administration Servlets
Process Automation & Course Development Systems
Email
XML
Fax
Dynamic Content Mgmt.
XML, Email, Fax "Lights Out" Services Interfaces
Facilitator/Client Admin. Servlets Course Production Systems
Site Development Svc.

Client Interfaces Client Request Handler API DataWarehouse-Driven Human Resources Systems
Processing
Clients Telephony-Based Payroll Systtems
Services XML-based
Component presentation
Manager Connectors
oriented publishing Support Systtems
Customer Calls Handling
(ACD, Flex-Routing, Call Center Mgmt.)
Firewall
templates
Course Production Systems)

Telephony Svcs
CSR Assisted Services
(Product Support, Issue Resolution, Proactive
IVR
Integrated Data Architecture Layer
Account Mgmt.)

Presentation Enabling:
Querying Web-Enabled
Locating Win Applications Database Management Systems (DBMS)
Viewing 2000
Web Applications Client Interface
(Presentation querying, locating, and viewing -

University Intranet WAN

Questions capture and Q&A viewring)
Q&A Enabling:
Capture Internet-Based Services
(XML interfaces, Email, Browser)
Viewing Customer Profiles XML SMIL Data Local Account Data
Personalization Interface
Time Critical MOM & POP XLF Data Entitlement/Security Data
Students University
Information
Internet LAN Channels Interface Templates Operational Data etc.
(Browsers, PDAs, WAPs)

Real Time Services In Memory Database Content-Mgmt Repository Global Application Data Replicas Legacy Operational Data
(Web Channels, Chat, TV Events, etc.)

Self Care Services

(tutorials, online help)

Remote Training Interface

Legend: Educational Research
Collaborative Applications Desktop Operational Data Store
PDA/WAP Applications (2D Avatars, Classroom Navigation, Chat, Events) Educational News
In scope Filesystems Client Knowledge Engine
Voice/Data Integration etc.
Teleweb / Web Integration Services
Metadata Repository
Out of scope WAP Server (Consolidated Messaging, Telephone-Based W eb
Services, Video Conf., etc.)
Business Information Warehouse Third Party Data

35

Sample High-Level Architecture Design Physical Blueprint

University Systems & Network Management Environment

University Mgmt. Firewall

Tape Silo
Veritas Network
Backup (shared service)
Component Manager Chat Platform
Connects to Firewall / IIOP Proxy Server Application Logic
WebLogic
Sun E420/Solaris 2.6

all devices below Sun E220/Solaris 2.6 ChatUser Component

Checkpoint Firewall-1
Stonebeat ChatRoom Component
IONA Wonderwall Proxy Server
Remote-1
NFR Flight Recorder

XML/Web Enabling Facilities

Application Support Services
Server XML Core Services
50GB Disk Array
enCommerce GetAccess
Sun E420/Solaris 2.6

Intrusion
TomCat jsp engine
TomCat servlet engine
Apache HTTP sever
nCipher SSL accelerator
Sun E220/Solaris 2.6

Session/State/EOD Mgmt
Detection Load
Balancers Dynamic Content Mgmt

Alteon AC3
Web Server
Router Servlets & JSP Security &
University Intranet LAN (dual)

Engines Entitlements Srv SMIL Data

Stonebeat
Checkpoint Firewall-1
Sun E220/Solaris 2.6

XLF Data
University Internet LAN (dual)

Operational Data
Firewall
Sybase 11.9.2
50GB Disk Array
Sun E4500/Solaris 2.6

Client Request Handler

Internet HSRP Global Application Data
Servlets/JSPs:
- session handler
- SMIL presentation handler
- Q&A handler XML POP
- Cocoon 2 XML POP handler Database Server Templates

Content Mgmt. Repository

Firewall Back-Office Systems
Router Sun E420/Solaris 2.6
200GB raid5 Disk Array Client Administration
Remote-1
NFR Flight Recorder

iPlanet Enterprise Svr

Webtrends
Internal Administration
Admin/Reporting
Students, Professor, and TA Interfaces
Intrusion Server Intrusion Detection
Web-Enabled Detection
Applications
Clients/Facilitators Facilitators, and Production Interfaces
Application/Admin
Client Interfaces
Workstation XML, Email, Fax (e.g.,SOJA Applet) Web-Enabled
Collaborative
University Applications
Applications Intranet LAN Professor/TA Facilitator
(e.g., Chat Applet) Application and
Client/System
Channels Interface Administration
Professor/TA Interfaces
Workstation Firewall
Sun E220/Solaris 2.6 Program
Checkpoint Firewall-1 Administrator
Stonebeat Intrusion Detection
NFR Flight Recorder
Remote-1

36
Sample Deliverables - Design

ƒ Design:
ƒ Interaction Diagram
ƒ Shows the interaction between objects
ƒ This is a graphic representation
ƒ It is a dynamic blueprint
ƒ Class Diagram
ƒ Shows the structure between objects
ƒ Shows the structure inside objects
ƒ This is a graphic representation
ƒ It is a static blueprint

37

Agenda – Software Engineering Fundamentals

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles SDLCs
SDLCs

Software Engineering Detailed

Process Models

Agile Development

Software Engineering Knowledge

Roles and Types of Standards

38
A Generic Process Model

39

Process Flow

40
Identifying a Task Set

ƒ A task set defines the actual work to be done to

accomplish the objectives of a software
engineering action
ƒ A list of the tasks to be accomplished
ƒ A list of the work products to be produced
ƒ A list of the quality assurance filters to be applied

41

Process Patterns

ƒ A process pattern
ƒ describes a process-related problem that is
encountered during software engineering work,
ƒ identifies the environment in which the problem
has been encountered, and
ƒ suggests one or more proven solutions to the
problem
ƒ Stated in more general terms, a process pattern
provides you with a template [Amb98] - a
consistent method for describing problem
solutions within the context of the software
process
42
Process Pattern Types

ƒ Stage patterns - defines a problem associated

with a framework activity for the process
ƒ Task patterns - defines a problem associated
with a software engineering action or work
task and relevant to successful software
engineering practice
ƒ Phase patterns - define the sequence of
framework activities that occur with the
process, even when the overall flow of
activities is iterative in nature

43

Prescriptive Models

ƒ Prescriptive process models advocate an orderly

approach to software engineering
That leads to a few questions …
ƒ If prescriptive process models strive for structure
and order, are they inappropriate for a software
world that thrives on change?
ƒ Yet, if we reject traditional process models (and
the order they imply) and replace them with
something less structured, do we make it
impossible to achieve coordination and
coherence in software work?

44
The Waterfall Model Revisited

Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

45

The V-Model

46
The Incremental Model

increment # n
Co m m u n i c a t i o n
Pla nni ng
M ode ling
analysis Co n s t ru c t i o n
design
c ode De p l o y m e n t
t est d e l i v e ry
fee dba c k

delivery of
nt h increment
increment # 2

Co m m u n i c a t i o n
Pl a nni ng

M ode ling
analy sis Co n s t ru c t i o n
design c ode De p l o y m e n t
t es t d e l i v e ry
fee dba ck
delivery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pla nning
M ode ling
analys is Co n s t r u c t i o n
des ign code
t est
De p l o y m e n t
de l i v e ry delivery of
fe edbac k

1st increment

project calendar time

47

Evolutionary Models: Prototyping

Q u i cQuick
k p lan
plan
Co m m u n icat io n
communication

Mo Modeling
d e lin g
Quick
Q u i cdesign
k d e sig n

Deploym ent
Deployment
Ddelivery
e live r y& Construction
& feedback
Fe e d b ack Co n st r u ct io n
of prototype
Construction
o fof prototype
p r o t o t yp e

48
Evolutionary Models: The Spiral Model Revisited

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
49

Evolutionary Models: Concurrent

none

Modeling act ivit y

represents the state

Under of a software engineering
activity or task
development

Await ing
changes

Under review

Under
revision

Baselined

Done

50
Still Other Process Models

ƒ Component based development—the process to

apply when reuse is a development objective
ƒ Formal methods—emphasizes the mathematical
specification of requirements
ƒ AOSD—provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects
ƒ Unified Process—a “use-case driven,
architecture-centric, iterative and incremental”
software process closely aligned with the Unified
Modeling Language (UML)

51

The Unified Process (UP)

Elaborat ion
elaboration

Incept ion
inception

const ruct ion

Release
t ransit ion
soft ware increment

product ion

52
UP Phases

UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

53

UP Work Products

Inception phase

Elaboration phase
Vision document
Init ial use-case model
Init ial project glossary Construction phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Design model
Transition phase
Project plan, Analysis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Delivered soft ware increment
Int egrat ed soft ware
Business model, Descript ion. increment Bet a t est report s
if necessary. Execut able archit ect ural General user feedback
Test plan and procedure
One or more prot ot ypes prot ot ype.
I nc e pt i o Test cases
n Preliminary design model Support document at ion
Revised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

54
Personal Software Process (PSP)

ƒ Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule
is created.
ƒ High-level design. External specifications for each component to be
constructed are developed and a component design is created. Prototypes
are built when uncertainty exists. All issues are recorded and tracked.
ƒ High-level design review. Formal verification methods (Chapter 21) are
applied to uncover errors in the design. Metrics are maintained for all
important tasks and work results.
ƒ Development. The component level design is refined and reviewed. Code
is generated, reviewed, compiled, and tested. Metrics are maintained for all
important tasks and work results.
ƒ Postmortem. Using the measures and metrics collected (this is a
substantial amount of data that should be analyzed statistically), the
effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness.

55

Team Software Process (TSP)

ƒ Build self-directed teams that plan and track their work,

establish goals, and own their processes and plans. These can
be pure software teams or integrated product teams (IPT) of
three to about 20 engineers.
ƒ Show managers how to coach and motivate their teams and
how to help them sustain peak performance.
ƒ Accelerate software process improvement by making CMM
Level 5 behavior normal and expected.
ƒ The Capability Maturity Model (CMM), a measure of the effectiveness
of a software process, is discussed in Chapter 30.
ƒ Provide improvement guidance to high-maturity organizations.
ƒ Facilitate university teaching of industrial-grade team skills.

56
CMM & PSP/TSP (http://www.sei.cmu.edu)

ƒ The Capability Maturity Model for Software (SW-

CMM) is used by organization to guide their
software process improvement efforts
ƒ Personal Software Process
ƒ http://www.sei.cmu.edu/tsp/psp.html
ƒ The Team Software Process (TSP) was designed
to implement effective, high-maturity processes for
project teams
ƒ If all projects in an organization are using the TSP,
does the organization exhibit the characteristics of
high process maturity, as described in the SW-
CMM?
ƒ http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr008.pdf
57

SEI’s IDEALModel

ƒ IDEAL is an organizational improvement model

58
Team Exercise #1 – Groups will present in class

ƒ Research and put together a comparative write-up or

traditional Process Models:
ƒ Waterfall
ƒV
ƒ Phased
ƒ Evolutionary
ƒ Spiral
ƒ CBSE
ƒ RUP
ƒ PSP/TSP
59

Agenda – Software Engineering Fundamentals

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles SDLCs
SDLCs

Software Engineering Detailed

Process Models

Agile Development

Software Engineering Knowledge

Roles and Types of Standards

60
The Manifesto for Agile Software Development

“We are uncovering better ways of developing software

by doing it and helping others do it. Through this work
we have come to value:
•Individuals and interactions over processes and
tools
•Working software over comprehensive
documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.”
more.”
Kent Beck et al

61

What is “Agility”?

ƒ Effective (rapid and adaptive)

response to change
ƒ Effective communication among all
stakeholders
ƒ Drawing the customer onto the team
ƒ Organizing a team so that it is in
control of the work performed
Yielding …
ƒ Rapid, incremental delivery of
software

62
Agility and the Cost of Change

63

An Agile Process

ƒ Is driven by customer descriptions of what

is required (scenarios)
ƒ Recognizes that plans are short-lived
ƒ Develops software iteratively with a heavy
emphasis on construction activities
ƒ Delivers multiple ‘software increments’
ƒ Adapts as changes occur

64
Agility Principles (1/2)

1. Our highest priority is to satisfy the customer through early

and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–to–face
conversation.
65

Agility Principles (2/2)

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity – the art of maximizing the amount of
work not done – is essential.
11. The best architectures, requirements, and designs
emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
66
Human Factors Revisited

ƒ the process molds to the needs of the people

and team, not the other way around
ƒ key traits must exist among the people on an
agile team and the team itself:
» Competence.
» Common focus.
» Collaboration.
» Decision-making ability.
» Fuzzy problem-solving ability.
» Mutual trust and respect.
» Self-organization.
67

eXtreme Programming (XP) - http://www.extremeprogramming.org/

ƒ A lightweight software methodology

ƒ Few rules and practices or ones which are
easy to follow
ƒ Emphasizes customer involvement and
promotes team work
ƒ See XP’s rules and practices at
http://www.extremeprogramming.org/rules.html

68
Extreme Programming (XP) (1/3)

ƒ The most widely used agile process, originally

proposed by Kent Beck
ƒ XP Planning
ƒ Begins with the creation of “user stories”
ƒ Agile team assesses each story and assigns a cost
ƒ Stories are grouped to for a deliverable increment
ƒ A commitment is made on delivery date
ƒ After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments

69

Extreme Programming (XP) (2/3)

ƒ XP Design
ƒ Follows the KIS principle
ƒ Encourage the use of CRC cards (see Chapter 8)
ƒ For difficult design problems, suggests the creation of
“spike solutions”—a design prototype
ƒ Encourages “refactoring”—an iterative refinement of
the internal program design
ƒ XP Coding
ƒ Recommends the construction of a unit test for a
store before coding commences
ƒ Encourages “pair programming”
ƒ XP Testing
ƒ All unit tests are executed daily
ƒ “Acceptance tests” are defined by the customer and
excuted to assess customer visible functionality
70
Extreme Programming (XP) (3/3)

spike solut ions

simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

refact oring

pair
programming

Release
software increment unit t est
project velocity computed cont inuous int egrat ion

accept ance t est ing

71

XP Project Lifecycle

72
eXtreme Programming (XP) Map

73

XP Iteration Planning

74
XP Unit Testing

75

Agile Modeling & XP Summarized

ƒ Practices-based software process whose scope is to

describe how to model and document in an effective and
“agile” manner
ƒ One goal is to address the issue of how to apply
modeling techniques on software projects taking an agile
approach such as:
ƒ eXtreme Programming (XP)
ƒ Dynamic Systems Development Method (DSDM)
ƒ SCRUM
ƒ etc.
ƒ Using modeling throughout the XP lifecycle
ƒ http://www.agilemodeling.com/essays/agileModelingXPLifecycle.htm
ƒ Additional information
ƒ http://www.agilemodeling.com/
ƒ http://www.agilemodeling.com/resources.htm

76
Adaptive Software Development (1/2)

ƒ Originally proposed by Jim Highsmith

ƒ ASD — distinguishing features
ƒ Mission-driven planning
ƒ Component-based focus
ƒ Uses “time-boxing” (See Chapter 24)
ƒ Explicit consideration of risks
ƒ Emphasizes collaboration for requirements
gathering
ƒ Emphasizes “learning” throughout the
process

77

Adaptive Software Development (2/2)

adapt ive cycle planning Requirement s gat hering

uses mission st at ement JAD
project const raint s mini-specs
basic requirement s
t ime-boxed release plan

Release
software increment
adjustments for subsequent cycles
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems
78
Dynamic Systems Development Method (1/2)

ƒ Promoted by the DSDM Consortium

(www.dsdm.org)
ƒ DSDM—distinguishing features
ƒ Similar in most respects to XP and/or ASD
ƒ Nine guiding principles
ƒ Active user involvement is imperative.
ƒ DSDM teams must be empowered to make decisions.
ƒ The focus is on frequent delivery of products.
ƒ Fitness for business purpose is the essential criterion for acceptance of
deliverables.
ƒ Iterative and incremental development is necessary to converge on an
accurate business solution.
ƒ All changes during development are reversible.
ƒ Requirements are baselined at a high level
ƒ Testing is integrated throughout the life-cycle.

79

Dynamic Systems Development Method (2/2)

DSDM Life Cycle (with permission of the DSDM consortium)

80
Scrum

ƒ Originally proposed by Schwaber and

Beedle
ƒ Scrum—distinguishing features
ƒ Development work is partitioned into “packets”
ƒ Testing and documentation are on-going as
the product is constructed
ƒ Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
ƒ Meetings are very short and sometimes
conducted without chairs
ƒ “demos” are delivered to the customer with the
time-box allocated
81

Scrum Process Overview

82
Scrum Timeline Breakdown

Project Start Project End

ƒ Agile based projects are broken
down into Releases

ƒ At the end of each Release, a

2-3 months working version of the product is

delivered to the Business Users

ƒ Each Release is made up of a

number of sprints
2-4 weeks ƒ At the end of each Sprint, a
working version of the product is
deployed with incremental
functionalities added over the
Daily
previous sprint

ƒ During each Sprint, daily scrum

calls are held where status update
is provided by the team

83

Crystal

ƒ Proposed by Cockburn and Highsmith

ƒ Crystal—distinguishing features
ƒ Actually a family of process models that
allow “maneuverability” based on problem
characteristics
ƒ Face-to-face communication is emphasized
ƒ Suggests the use of “reflection workshops”
to review the work habits of the team

84
Feature Driven Development (1/2)

ƒ Originally proposed by Peter Coad et al

ƒ FDD—distinguishing features
ƒ Emphasis is on defining “features”
ƒ a feature “is a client-valued function that can be
implemented in two weeks or less.”
ƒ Uses a feature template
ƒ <action> the <result> <by | for | of | to> a(n) <object>
ƒ A features list is created and “plan by feature”
is conducted
ƒ Design and construction merge in FDD

85

Feature Driven Development (2/2)

Reprinted with permission of Peter Coad

86
Agile Modeling

ƒ Originally proposed by Scott Ambler

ƒ Suggests a set of agile modeling principles
ƒ Model with a purpose
ƒ Use multiple models
ƒ Travel light
ƒ Content is more important than representation
ƒ Know the models and the tools you use to
create them
ƒ Adapt locally

87

Agenda – Software Engineering Fundamentals

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles SDLCs
SDLCs

Software Engineering Detailed

Process Models

Agile Development

Software Engineering Knowledge

Roles and Types of Standards

88
Software Engineering Knowledge

ƒ You often hear people say that software development

knowledge has a 3-year half-life: half of what you
need to know today will be obsolete within 3 years. In
the domain of technology-related knowledge, that’s
probably about right. But there is another kind of
software development knowledge—a kind that I think
of as "software engineering principles"—that does
not have a three-year half-life. These software
engineering principles are likely to serve a
professional programmer throughout his or her
career.
Steve McConnell

89

Principles that Guide Process - I

ƒ Principle #1. Be agile. Whether the process model you choose

is prescriptive or agile, the basic tenets of agile development
should govern your approach.
ƒ Principle #2. Focus on quality at every step. The exit
condition for every process activity, action, and task should
focus on the quality of the work product that has been
produced.
ƒ Principle #3. Be ready to adapt. Process is not a religious
experience and dogma has no place in it. When necessary,
adapt your approach to constraints imposed by the problem,
the people, and the project itself.
ƒ Principle #4. Build an effective team. Software engineering
process and practice are important, but the bottom line is
people. Build a self-organizing team that has mutual trust and
respect.

90
Principles that Guide Process - II

ƒ Principle #5. Establish mechanisms for communication and

coordination. Projects fail because important information falls
into the cracks and/or stakeholders fail to coordinate their
efforts to create a successful end product.
ƒ Principle #6. Manage change. The approach may be either
formal or informal, but mechanisms must be established to
manage the way changes are requested, assessed, approved
and implemented.
ƒ Principle #7. Assess risk. Lots of things can go wrong as
software is being developed. It’s essential that you establish
contingency plans.
ƒ Principle #8. Create work products that provide value for
others. Create only those work products that provide value for
other process activities, actions or tasks.

91

Principles that Guide Practice

ƒ Principle #1. Divide and conquer. Stated in a more

technical manner, analysis and design should always
emphasize separation of concerns (SoC).
ƒ Principle #2. Understand the use of abstraction. At
it core, an abstraction is a simplification of some
complex element of a system used to communication
meaning in a single phrase.
ƒ Principle #3. Strive for consistency. A familiar
context makes software easier to use.
ƒ Principle #4. Focus on the transfer of information.
Pay special attention to the analysis, design,
construction, and testing of interfaces.
92
Principles that Guide Practice

ƒ Principle #5. Build software that exhibits effective

modularity. Separation of concerns (Principle #1) establishes a
philosophy for software. Modularity provides a mechanism for
realizing the philosophy.
ƒ Principle #6. Look for patterns. Brad Appleton [App00]
suggests that: “The goal of patterns within the software
community is to create a body of literature to help software
developers resolve recurring problems encountered throughout
all of software development.
ƒ Principle #7. When possible, represent the problem and its
solution from a number of different perspectives.
ƒ Principle #8. Remember that someone will maintain the
software.

93

Communication Principles

ƒ Principle #1. Listen. Try to focus on the speaker’s words,

rather than formulating your response to those words.
ƒ Principle # 2. Prepare before you communicate. Spend the
time to understand the problem before you meet with others.
ƒ Principle # 3. Someone should facilitate the activity. Every
communication meeting should have a leader (a facilitator) to
keep the conversation moving in a productive direction; (2) to
mediate any conflict that does occur, and (3) to ensure than
other principles are followed.
ƒ Principle #4. Face-to-face communication is best. But it
usually works better when some other representation of the
relevant information is present.

94
Communication Principles

ƒ Principle # 5. Take notes and document decisions. Someone participating

in the communication should serve as a “recorder” and write down all
important points and decisions.
ƒ Principle # 6. Strive for collaboration. Collaboration and consensus
occur when the collective knowledge of members of the team is combined
…
ƒ Principle # 7. Stay focused, modularize your discussion. The more
people involved in any communication, the more likely that discussion will
bounce from one topic to the next.
ƒ Principle # 8. If something is unclear, draw a picture.
ƒ Principle # 9. (a) Once you agree to something, move on; (b) If you can’t
agree to something, move on; (c) If a feature or function is unclear and
cannot be clarified at the moment, move on.
ƒ Principle # 10. Negotiation is not a contest or a game. It works best
when both parties win.

95

Planning Principles

ƒ Principle #1. Understand the scope of the project.

It’s impossible to use a roadmap if you don’t know
where you’re going. Scope provides the software
team with a destination.
ƒ Principle #2. Involve the customer in the planning
activity. The customer defines priorities and
establishes project constraints.
ƒ Principle #3. Recognize that planning is iterative.
A project plan is never engraved in stone. As work
begins, it very likely that things will change.
ƒ Principle #4. Estimate based on what you know.
The intent of estimation is to provide an indication of
effort, cost, and task duration, based on the team’s
current understanding of the work to be done.
96
Planning Principles

ƒ Principle #5. Consider risk as you define the plan. If you have
identified risks that have high impact and high probability,
contingency planning is necessary.
ƒ Principle #6. Be realistic. People don’t work 100 percent of
every day.
ƒ Principle #7. Adjust granularity as you define the plan.
Granularity refers to the level of detail that is introduced as a
project plan is developed.
ƒ Principle #8. Define how you intend to ensure quality. The
plan should identify how the software team intends to ensure
quality.
ƒ Principle #9. Describe how you intend to accommodate
change. Even the best planning can be obviated by uncontrolled
change.
ƒ Principle #10. Track the plan frequently and make
adjustments as required. Software projects fall behind schedule
one day at a time. 97

Modeling Principles

ƒ In software engineering work, two classes of

models can be created:
ƒ Requirements models (also called analysis models)
represent the customer requirements by depicting
the software in three different domains: the
information domain, the functional domain, and
the behavioral domain.
ƒ Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.

98
Requirements Modeling Principles

ƒ Principle #1. The information domain of a problem

must be represented and understood.
ƒ Principle #2. The functions that the software
performs must be defined.
ƒ Principle #3. The behavior of the software (as a
consequence of external events) must be
represented.
ƒ Principle #4. The models that depict information,
function, and behavior must be partitioned in a
manner that uncovers detail in a layered (or
hierarchical) fashion.
ƒ Principle #5. The analysis task should move from
essential information toward implementation detail. 99

Design Modeling Principles

ƒ Principle #1. Design should be traceable to the requirements model.

ƒ Principle #2. Always consider the architecture of the system to be built.
ƒ Principle #3. Design of data is as important as design of processing
functions.
ƒ Principle #5. User interface design should be tuned to the needs of the
end-user. However, in every case, it should stress ease of use.
ƒ Principle #6. Component-level design should be functionally
independent.
ƒ Principle #7. Components should be loosely coupled to one another
and to the external environment.
ƒ Principle #8. Design representations (models) should be easily
understandable.
ƒ Principle #9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity.

100
Agile Modeling Principles

ƒ Principle #1. The primary goal of the software team is to build software,
not create models.
ƒ Principle #2. Travel light—don’t create more models than you need.
ƒ Principle #3. Strive to produce the simplest model that will describe the
problem or the software.
ƒ Principle #4. Build models in a way that makes them amenable to
change.
ƒ Principle #5. Be able to state an explicit purpose for each model that is
created.
ƒ Principle #6. Adapt the models you develop to the system at hand.
ƒ Principle #7. Try to build useful models, but forget about building
perfect models.
ƒ Principle #8. Don’t become dogmatic about the syntax of the model. If it
communicates content successfully, representation is secondary.
ƒ Principle #9. If your instincts tell you a model isn’t right even though it
seems okay on paper, you probably have reason to be concerned.
ƒ Principle #10. Get feedback as soon as you can.

101

Construction Principles

ƒ The construction activity encompasses a set of coding

and testing tasks that lead to operational software that
is ready for delivery to the customer or end-user.
ƒ Coding principles and concepts are closely aligned
programming style, programming languages, and
programming methods.
ƒ Testing principles and concepts lead to the design of
tests that systematically uncover different classes of
errors and to do so with a minimum amount of time
and effort.

102
Preparation Principles

ƒ Before you write one line of code, be sure

you:
ƒ Understand of the problem you’re trying to solve.
ƒ Understand basic design principles and concepts.
ƒ Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate.
ƒ Select a programming environment that provides tools
that will make your work easier.
ƒ Create a set of unit tests that will be applied once the
component you code is completed.

103

Coding Principles

ƒ As you begin writing code, be sure you:

ƒ Constrain your algorithms by following structured programming
[Boh00] practice.
ƒ Consider the use of pair programming
ƒ Select data structures that will meet the needs of the design.
ƒ Understand the software architecture and create interfaces that are
consistent with it.
ƒ Keep conditional logic as simple as possible.
ƒ Create nested loops in a way that makes them easily testable.
ƒ Select meaningful variable names and follow other local coding
standards.
ƒ Write code that is self-documenting.
ƒ Create a visual layout (e.g., indentation and blank lines) that aids
understanding.

104
Validation Principles

ƒ After you’ve completed your first coding

pass, be sure you:
ƒ Conduct a code walkthrough when appropriate.
ƒ Perform unit tests and correct errors you’ve uncovered.
ƒ Refactor the code.

105

Testing Principles

ƒ Al Davis suggests the following:

ƒ Principle #1. All tests should be traceable to
customer requirements.
ƒ Principle #2. Tests should be planned long before
testing begins.
ƒ Principle #3. The Pareto principle applies to
software testing.
ƒ Principle #4. Testing should begin “in the small”
and progress toward testing “in the large.”
ƒ Principle #5. Exhaustive testing is not possible.

106
Deployment Principles

ƒ Principle #1. Customer expectations for the

software must be managed. Too often, the customer
expects more than the team has promised to deliver,
and disappointment occurs immediately.
ƒ Principle #2. A complete delivery package should
be assembled and tested.
ƒ Principle #3. A support regime must be established
before the software is delivered. An end-user expects
responsiveness and accurate information when a
question or problem arises.
ƒ Principle #4. Appropriate instructional materials
must be provided to end-users.
ƒ Principle #5. Buggy software should be fixed first,
delivered later.
107

Agenda – Software Engineering Fundamentals

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles SDLCs
SDLCs

Software Engineering Detailed

Process Models

Agile Development

Software Engineering Knowledge

Roles and Types of Standards

108
Process Assessment and Improvement

ƒ Standard CMMI Assessment Method for Process Improvement

(SCAMPI) — provides a five step process assessment model that
incorporates five phases: initiating, diagnosing, establishing, acting and
learning.
ƒ CMM-Based Appraisal for Internal Process Improvement (CBA
IPI)—provides a diagnostic technique for assessing the relative maturity of
a software organization; uses the SEI CMM as the basis for the assessment
[Dun01]
ƒ SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent of the standard is
to assist organizations in developing an objective evaluation of the efficacy
of any defined software process. [ISO08]
ƒ ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]

109

Other Standards

ƒ ISO 12207
ƒ http://www.acm.org/tsc/lifecycle.html
ƒ http://www.12207.com/
ƒ IEEE Standards for Software Engineering Processes
and Specifications
ƒ http://standards.ieee.org/catalog/olis/se.html
ƒ http://members.aol.com/kaizensepg/standard.htm

110
Agenda

11 Session
Session Overview
Overview

22 Software
Software Engineering
Engineering LifeCycles
LifeCycles (SDLCs)
(SDLCs)

33 Summary
Summary and
and Conclusion
Conclusion

111

Course Assignments

„ Individual Assignments
„ Reports based on case studies / class presentations
„ Project-Related Assignments
„ All assignments (other than the individual assessments) will
correspond to milestones in the team project.
„ As the course progresses, students will be applying various
methodologies to a project of their choice. The project and related
software system should relate to a real-world scenario chosen by each
team. The project will consist of inter-related deliverables which are
due on a (bi-) weekly basis.
„ There will be only one submission per team per deliverable and all
teams must demonstrate their projects to the course instructor.
„ A sample project description and additional details will be available
under handouts on the course Web site

112
Team Project

„ Project Logistics
„ Teams will pick their own projects, within certain constraints: for instance,
all projects should involve multiple distributed subsystems (e.g., web-
based electronic services projects including client, application server, and
database tiers). Students will need to come up to speed on whatever
programming languages and/or software technologies they choose for their
projects - which will not necessarily be covered in class.
„ Students will be required to form themselves into "pairs" of exactly two (2)
members each; if there is an odd number of students in the class, then one
(1) team of three (3) members will be permitted. There may not be any
"pairs" of only one member! The instructor and TA(s) will then assist the
pairs in forming "teams", ideally each consisting of two (2) "pairs", possibly
three (3) pairs if necessary due to enrollment, but students are encouraged
to form their own 2-pair teams in advance. If some students drop the
course, any remaining pair or team members may be arbitrarily reassigned
to other pairs/teams at the discretion of the instructor (but are strongly
encouraged to reform pairs/teams on their own). Students will develop and
test their project code together with the other member of their programming
pair.

113

Team Project Approach - Overall

ƒ Document Transformation methodology driven

approach
» Strategy Alignment Elicitation
• Equivalent to strategic planning
– i.e., planning at the level of a project set
» Strategy Alignment Execution
• Equivalent to project planning + SDLC
– i.e., planning a the level of individual projects + project
implementation

ƒ Build a methodology Wiki & partially implement the

enablers
ƒ Apply transformation methodology approach to a
sample problem domain for which a business solution
must be found
ƒ Final product is a wiki/report that focuses on
» Methodology / methodology implementation / sample
business-driven problem solution
114
Team Project Approach – Initial Step

ƒ Document sample problem domain and

business-driven problem of interest
» Problem description
» High-level specification details
» High-level implementation details
» Proposed high-level timeline

115

Assignments & Readings

ƒ Readings
» Slides and Handouts posted on the course web site
» Textbook: Chapter 1 & Part One-Chapters 2-4

ƒ Team Project
» Team Project proposal (format TBD in class)

ƒ Team Exercise #1
» Presentation topic proposal (format TBD in class)

ƒ Project Frameworks Setup (ongoing)

» As per reference provided on the course Web site

116
Next Session: Software Development Lifecycles (SDLCs)

117

Any Questions?

118
Next Session: Planning and Managing Requirements

119