Advanced Information Systems

Analysis and Design

Class 2: System Development
Processes and Methods

Alan R. Hevner
University of South Florida

August 30, 2018 Copyright © 2018 Alan R. Hevner 1

Class 2 Outline
 Software Development Processes and Methods – Definitions
 Plan-Driven Processes and Methods
 Waterfall Development Models
 Spiral Development Models
 V-Model with Incremental Development and Cleanroom Concepts
 Agile Processes and Methods
 The Agile Manifesto
 Rational Unified Process (RUP)
 Extreme Programming
 Control in Flexible Software Development
 DevOps
 Concepts
 Industry Status
 Risk Management
 Risk Identification, Analysis, and Control
 Using Risk to Balance Discipline and Agility
 Designing the Right Process and Method for Your Project
 Cost Estimation for Software Projects

August 30, 2018 Copyright © 2018 Alan R. Hevner 2

Software Process
 A software process determines the order of
phases (i.e., activities) involved in software
development and evolution and establishes
transition criteria for progressing from one
phase to the next.
 What phase and activities shall we do next?
 How do we know when we are finished with an
development phase?

August 30, 2018 Copyright © 2018 Alan R. Hevner 3

Software Method
 A software method instructs how to perform the
activities in each software development phase
and how to represent the artifacts of that phase.
 How do we produce the artifacts of this development
phase?
 What representations are appropriate for the
artifacts?
 Methodology is used to denote a collection of
related methods.

August 30, 2018 Copyright © 2018 Alan R. Hevner 4

Agility vs. Discipline (B&T Chapter 1)

 Development discipline enforces well-

ordered application of processes and
methods. Consistency, repeatability, and
correctness are prized.
 Development agility emphasizes creativity
and adaptability to a changing environment.
Fast reaction time and focus on customer are
prized.
August 30, 2018 Copyright © 2018 Alan R. Hevner 5
Background
 Two approaches to software development
 Disciplined (CMMI, document-based, heavy
process)
 Agile (XP, tacit knowledge, light process)

 Both have strengths and weaknesses

 Agile and disciplined proponents are
believers
 Many of us are perplexed

August 30, 2018 Copyright © 2018 Alan R. Hevner 6

Sources of Perplexity
 Distinguishing method use from method misuse
 Claiming XP use when simply “not documenting”
 “CMM Level 4 Memorial Library” of 99 2-inch binders
 Overgeneralization based on the most visible
instances
 XP is Agile; CMMI is Discipline
 Multiple definitions
 Quality: customer satisfaction or process compliance?
 Claims of universality
 The pace of IT change is accelerating and Agile methods adapt
to change better than disciplined methods therefore Agile
methods will take over the IT world.
 Software development is uncertain and the CMMI improves
predictability therefore all software developers should use the
CMMI
August 30, 2018 Copyright © 2018 Alan R. Hevner 7
Sources of Perplexity (2)
 Early success stories
 Chrysler project that successfully birthed XP was later cancelled
 Cleanroom has never made it into the mainstream
 Purist interpretations (and internal disagreements)
 “Don't start by incrementally adopting parts of XP. Its pieces fit
together like a fine Swiss watch“
 "An advantage of agile methods is that you can apply them
selectively and generatively."
 "If you aren't 100% compliant with SW CMM Level 3, don't
bother to bid"
 "With the CMMI continuous interpretation, you can improve your
processes in any order you feel is best."

August 30, 2018 Copyright © 2018 Alan R. Hevner 8

Key Definitions
 Agile method –
 one which fully adopts the four value propositions and twelve
principles in the Agile Manifesto.
 Discipline – (per Webster)
 control gained by enforcing obedience or order;
 orderly or prescribed conduct or pattern of behavior;
 self-control.
 Plan-driven –
 a description for disciplined methods (order is often defined in
plans)
 Plan – (per Webster)
 a method for achieving an end (a process plan);
 an orderly arrangements of parts of an overall design (a product
plan).
 We assume that such plans are documented.
August 30, 2018 Copyright © 2018 Alan R. Hevner 9
Balancing Agility and Discipline
 Some view agility and discipline as end points on
a 2-dimensional scale.
 Traditional software processes emphasized
discipline.
 SEI CMMI
 Recent software processes have focused on
agility.
 XP and Scrum
 Can we find a balance??

August 30, 2018 Copyright © 2018 Alan R. Hevner 10

Plan-Driven Processes/Methods
 Foundations come from Engineering fields and
Total Quality Management (TQM)
 Initial Process Models came from Dept. of
Defense (DoD) standards:
 DoD-STD-2167a
 MIL-STD-498
 Large organizations (e.g., IBM) adapted DoD
process models for own use.
 Essential component of plan-driven process
models is continuous process improvement.
 Large requirements for documentation.
August 30, 2018 Copyright © 2018 Alan R. Hevner 11
Plan-Driven Concepts
 Process Capability
 Process Improvement
 Organizational Maturity
 Software Engineering Process Groups (SEPGs)
 Risk Management
 Verification – Build the product right.
 Validation – Build the right product.
 Software System Architecture

August 30, 2018 Copyright © 2018 Alan R. Hevner 12

Agile Processes/Methods
 Foundations come from rapid product
development needs of the market (e.g., E-
Commerce) and the ‘de-humanizing’ feel of
too much discipline.
 ‘Lightweight’ processes and methods
 Agile Manifesto (Appendix B)
 http://agilemanifesto.org/

August 30, 2018 Copyright © 2018 Alan R. Hevner 13

Agile Concepts
 Embrace Change
 Fast Cycle/ Frequent Delivery
 Simple Design (You Aren’t Going to Need It)
 Refactoring
 Pair Programming
 Retrospective
 Tacit Knowledge
 Test-Driven Development

August 30, 2018 Copyright © 2018 Alan R. Hevner 14

Finding Middle Ground
 A pragmatic view
 Both approaches have “home grounds”
 A broad range of environments and needs
 Trends require better handling of rapid change
 Processes should be the right weight for the job
 Risk-based analysis is one key to finding middle
ground

August 30, 2018 Copyright © 2018 Alan R. Hevner 15

Contrasts and Home Grounds
 Comparison is difficult, but 4 areas have clear
differences
 Application
 The type of project
 Management
 Communication and control aspects
 Technical
 How the software is developed
 Personnel
 The type and competency of developers and
stakeholders
August 30, 2018 Copyright © 2018 Alan R. Hevner 16
Application Characteristics
 Primary goals
 A: Rapid value, responsiveness to change
 D: Predictability, stability, high assurance
 Size
 A: Small to medium
 D: Large
 Environment
 A: Turbulent, high change
 D: Stable, requirements defined

August 30, 2018 Copyright © 2018 Alan R. Hevner 17

Management Characteristics
 Customer Relations
 A: Dedicated, collocated
 D: Contractual
 A: Trust through working software and participation
 D: Trust through process maturity evaluations
 Planning and Control
 A: Means to an end
 D: Anchor processes, communication
 Project Communications
 A: Tacit, interpersonal knowledge, poor scalability
 N developers requires N(N-1)/2 communication paths
 D: Explicit, documented knowledge

August 30, 2018 Copyright © 2018 Alan R. Hevner 18

Technical Characteristics
 Requirements
 A: Adjustable, informal stories
 D: Formally baselined, complete, consistent,
traceable, testable specifications
 Development
 A: Simple Design
 D: Planning, Architecture-based design
 Testing
 A: Automated, test-driven
 D: Planned, requirements-driven

August 30, 2018 Copyright © 2018 Alan R. Hevner 19

Personnel Characteristics
 Customers
 A: CRACK customers throughout development
 D: CRACK customers early
 CRACK: Collaborative, Representative, Authorized,
Committed, and Knowledgeable
 Developers
 A: Heavy mix of high caliber throughout
 D: Heavy mix early with lower capability later
 Culture
 A: Many degrees of freedom (Thrives on chaos)
 D: Clear policies and procedures (Thrives on order)

August 30, 2018 Copyright © 2018 Alan R. Hevner 20

 Personnel Characteristics (2)
Level Characteristics
3 Able to revise a method (break its rules) to fit an unprecedented new situation
2 Able to tailor a method to fit a precedented new situation
1A With training, able to perform discretionary method steps (e.g., sizing stories to fit increments, composing
patterns, compound refactoring, complex COTS integration). With experience can become Level 2.
1B With training, able to perform procedural method steps (e.g. coding a simple method, simple refactoring,
following coding standards and CM procedures, running tests). With experience can master some Level 1A skills.
-1 May have technical skills, but unable or unwilling to collaborate or follow shared methods.
(Skill, Understanding)

(Formality, Documentation)

August 30, 2018 Copyright © 2018 Alan R. Hevner 21

Misconceptions on Plan-Driven
Processes/Methods
 Plan-driven processes/methods are bureaucratic.
 Having documented plans guarantees compliance
with plans.
 Plan-driven processes/methods can succeed with a
lack of talented people.
 High maturity guarantees success.
 There are no penalties in applying plan-driven
processes/methods when change is foreseeable.

August 30, 2018 Copyright © 2018 Alan R. Hevner 22

Misconceptions on Agile
Processes/Methods
 Agile processes/methods don’t plan.
 Agile processes/methods require uniformly
talented people.
 Agile processes/methods can make the
slope of the cost-to-change vs. time curve
flat.
 You Aren’t Going to Need It (YAGNI) is a
universally safe assumption and won’t
alienate your customers.
August 30, 2018 Copyright © 2018 Alan R. Hevner 23
 The Five Critical Factors
Factor Agile Disciplined
Size Small products and teams Large products and teams
Limited scalability up Limited scalability down
Criticality Untested on safety-critical Can be adapted for highly
products (Simple design and critical products and
lack of documentation) environments
Dynamism Designed for highly dynamic Designed for highly stable
environments environments
Personnel Requires continuous Specification requires presence
presence of experts of experts
Fewer experts needed later
Culture Thriving on chaos Thriving on order

August 30, 2018 Copyright © 2018 Alan R. Hevner 24

Five Critical Decision Factors
Personnel
(% Level 1B) (% Level 2&3)
40 15

30 20

20 25

Criticality
Dynamism
(Loss due to impact of defects) 10 30
(% Requirements-change/month)

Many 0 35
1
Lives Single 5
Essential 10
Life Discretionary
Funds 30
Funds Comfort
50

3 Ag i l
90 e
10
70
30 Disc
ip line
50 d
100
30

300
Size 10

(# of personnel) Culture
(% thriving on chaos vs. order)

August 30, 2018 Copyright © 2018 Alan R. Hevner 25

Plan-Driven SW Development
Processes
 Code and Fix Process
 Waterfall Processes
 Spiral Processes
 Rational Unified Process (RUP)
 V-Model Processes
 Incremental Development
 Cleanroom Extensions
 Evolutionary Processes
 Prototyping Models
 Object-Oriented Processes
August 30, 2018 Copyright © 2018 Alan R. Hevner 26
 Waterfall Model
Requirements
analysis
Specifications &
models

Design
Specifications & models
R
i Code and unit test
s
Tested code
k
Subsystem integration
Executable subsystem

System integration

Executable system

Time

August 30, 2018 Copyright © 2018 Alan R. Hevner 27

 Spiral Model of Software Process
CUMMULATIVE
COST
PROGRESS
THROUGH
DETERMINE EVALUATE
STEPS
OBJECTIVES, ALTERNATIVES
ALTERNATIVES, IDENTIFY,
CONSTRAINTS RESOLVE RISKS

RISK ANALYSIS

RISK ANALYSIS

RISK ANALYSIS
OPERATIONAL
COMMITMENT PROTOTYPE
RISK PROTOTYPE3
PARTITION
ANAL. PROTOTYPE2
PROTO-
TYPE1
REVIEW
EMULATIONS
RQTS PLAN MODELS
CONCEPT OF BENCHMARKS
LIFE CYCLE
OPERATION SOFTWARE
PLAN
RQTS
SOFTWARE DETAILED
DEVELOP- PRODUCT DESIGN
REQUIREMENTS
MENT PLAN DESIGN
VALIDATION

CODE
INTEGRATION
DESIGN VALIDATION
AND TEST UNIT
AND VERIFICATION
PLAN NEXT PLAN TEST
PHASES INTEGRA-
TION AND
ACCEPT- TEST
IMPLEMEN- ANCE TEST
TATION DEVELOP, VERIFY
NEXT LEVEL PRODUCT

August 30, 2018 Copyright © 2018 Alan R. Hevner 28

 Rational Unified Process (RUP)

Engineering Manufacturing
Stage Stage

Inception Elaboration Construction Transition

LCO LCA IOC
Feasibility Architecture Usable Product
Iterations Iterations Iterations Releases

R D I D R D I D R D I D R D I D
E E M E E E M E E E M E E E M E
Q S P P Q S P P Q S P P Q S P P
Management Management Management Management
RATIONAL
Software Corporation

August 30, 2018 Copyright © 2018 Alan R. Hevner 29

V-Model Process
Software Development Process Model

Customer Acceptance
Requirements Analysis Test Scripts Field Test

System Test Scripts

Software Architecture System Integration

System Test

Subsystem

Software Design Test Scripts Subsystem Integration

Subsystem Test

Implementation

Unit Test
Figure 1

August 30, 2018 Copyright © 2018 Alan R. Hevner 30

V-Model with Incremental Development
Evolved Software Development Process Model
(with Incremental Development)

Customer Acceptance
Requirements Analysis Test Scripts Field Test

System Test Scripts

Software Architecture System Integration

Incremental Dev. Plan System Test

Subsystem

Software Design Test Scripts Subsystem Integration

Subsystem Test

Incremental Implementation
Development Cycle
Unit Test
Figure 2

August 30, 2018 Copyright © 2018 Alan R. Hevner 31

V-Model with Specification
Evolved Software Development Process Model
(with Inc. Dev. and Functional/Usage Specifications)

Customer Acceptance
Requirements Analysis Test Scripts Field Test
Functional Usage
Specification Specification
Box Structure
Representations
Software Architecture System Test Scripts System Integration

Incremental Dev. Plan System Test

Box Structure
Representations Subsystem

Software Design Test Scripts Subsystem Integration

Subsystem Test
Box Structure
Representations
Incremental Implementation
Development Cycle
Unit Test
Figure 3

August 30, 2018 Copyright © 2018 Alan R. Hevner 32

V-Model with Cleanroom Testing
Evolved Software Development Process Model
(with Inc. Dev., Func./Usage Spec., and Correctness Verification/Statistical Testing)

Customer Acceptance
Requirements Analysis Test Scripts Field Test
Functional Usage
Specification Specification
Box Structure
Representations System Test Scripts
Software Architecture

Incremental Dev. Plan

Box Structure System Integration
Representations
Statistical Testing
Software Design
Software Certification
Correctness Verification

Box Structure
Representations
Incremental Implementation
Development Cycle

Figure 4

August 30, 2018 Copyright © 2018 Alan R. Hevner 33

Other Process Models
 Evolutionary Prototyping
 Risks of Prototype lacking essential
functionality and quality attributes
 Rapid Application Development Models
 Object-Oriented Process Models
 Fountain Model
 Numerous Industry Process Models

August 30, 2018 Copyright © 2018 Alan R. Hevner 34

Quality Control of Software
Development Processes
 Foundation in Total Quality Management
 Deming, Juran, Crosby, etc.
 Process Capability – the range of results
expected from following a process.
 Process Performance – the actual results
achieved from following a process.
 Process Maturity – an organization’s ability to
consistently follow and improve its process.

August 30, 2018 Copyright © 2018 Alan R. Hevner 35

The Frameworks Quagmire

August 30, 2018 Copyright © 2018 Alan R. Hevner 36

 SEI Capability Maturity Model
Integration (CMMI)
 Staged Representation CMMI-DEV Version 1.2
 Level 1 – Initial (Heroes)
 Level 2 – Managed (Project management)
 Level 3 – Defined (Engineering processes)
 Level 4 – Quantitatively Managed (Product and process
quality)
 Level 5 – Optimizing (Continuous quality improvement)

 SEI CMMI
 http://cmmiinstitute.com/

August 30, 2018 Copyright © 2018 Alan R. Hevner 37

 The Personal Software Process (PSP)
and the Team Software Process (TSP)
 The Personal Software Process (PSP) shows engineers
how to
 manage the quality of their projects
 make commitments they can meet
 improve estimating and planning
 reduce defects in their products
 The Team Software Process (TSP) helps the high-
performance engineering teams to
 ensure quality software products
 create secure software products
 improve process management in an organization
 http://www.sei.cmu.edu/tsp

August 30, 2018 Copyright © 2018 Alan R. Hevner 38

The Agile Manifesto - I
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.

August 30, 2018 Copyright © 2018 Alan R. Hevner 39

The Agile Manifesto – II
 Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
 Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
 Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
 Business people and developers must work
together daily throughout the project.

August 30, 2018 Copyright © 2018 Alan R. Hevner 40

The Agile Manifesto – III
 Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
 The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
 Working software is the primary measure of progress.
 Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

August 30, 2018 Copyright © 2018 Alan R. Hevner 41

The Agile Manifesto – IV
 Continuous attention to technical excellence and
good design enhances agility.
 Simplicity – the art of maximizing the amount of work
not done – is essential.
 The best architectures, requirements, and designs
emerge from self-organizing teams.
 At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.

August 30, 2018 Copyright © 2018 Alan R. Hevner 42

Various Agile Methods Available
 Appendix A in Boehm and Turner
 Adaptive Software Development (ASD)
 Agile Modeling
 Crystal methods
 Dynamic System Development Methodology
(DSDM)
* eXtreme Programming (XP)
 Feature Driven Development
 Lean Development
 Scrum

August 30, 2018 Copyright © 2018 Alan R. Hevner 43

 eXtreme Programming (XP)
 Principles
 The 12 Practices
 http://extremeprogramming.org

August 30, 2018 Copyright © 2018 Alan R. Hevner 44

XP Principles – I
 Philosophy: Take known good practices
and push them to extremes
 “If code reviews are good, we’ll review
code all the time”
 “If testing is good, we’ll test all the time”
 “If design is good, we’ll make it part of
everybody’s daily business”

August 30, 2018 Copyright © 2018 Alan R. Hevner 45

XP Principles – II
 “If simplicity is good, we’ll always leave the
system with the simplest design that
supports its current functionality”
 “If architecture is important, everybody will
work defining and refining the architecture
all the time”
 “If integration testing is important, then
we’ll integrate and test several times a
day”
August 30, 2018 Copyright © 2018 Alan R. Hevner 46
XP Principles – III
 “If short iterations are good, we’ll make
the iterations really, really short –
seconds and minutes and hours, not
weeks and months and years”
 “If customer involvement is good, we’ll
make them full-time participants”

August 30, 2018 Copyright © 2018 Alan R. Hevner 47

XP: The 12 Practices
 The Planning Game  Pair Programming
 Small Releases  Collective Ownership
 Metaphor  Continuous Integration
 Simple Design  40-hour Week
 Testing  On-site Customer
 Refactoring  Coding Standards

-Used generatively, not imperatively

August 30, 2018 Copyright © 2018 Alan R. Hevner 48
The Planning Game
 Quickly determine the scope of the next
release by combining business priorities
and technical estimates.
 Use stories to facilitate knowledge transfer
 Put decisions in the hands of the person
with the best knowledge:
 business decisions Customer
 software decisions Developer
 Plan only as far as your knowledge allows
 next iteration or next release

August 30, 2018 Copyright © 2018 Alan R. Hevner 49

Small Releases
 Put a simple system into production
quickly, then release new versions on a
very short cycle.
 Supports quick feedback from users
 Simplify the tracking of metrics
 stories per iteration project velocity
 Increase the manageability of the
project for the customer

August 30, 2018 Copyright © 2018 Alan R. Hevner 50

Metaphor
 Guide all development with a single,
simple shared story of how the whole
system works.
 Provide an overarching view of the
project
 Connect program to work process

August 30, 2018 Copyright © 2018 Alan R. Hevner 51

Simple Design
 The system should be designed as simply as
possible at any given moment.
 Design embodies only the needed complexity
and no more
 emphasis on top-down or bottom-up design as
needed to meet this iteration’s stories
 extra complexity removed when discovered
 Simpler designs are easier to modify, maintain,
and describe
 Decreases the cost of design changes
 But no notion of product line architecture

August 30, 2018 Copyright © 2018 Alan R. Hevner 52

Testing
 Programmers continually write unit tests which
must run flawlessly for development to continue.
 Unit tests verify the programmer’s work
 must be done by programmer
 constant testing makes finding new bugs faster and
easier
 Functional tests verify that a story is complete
 developed by customer
 tests define functional requirements

August 30, 2018 Copyright © 2018 Alan R. Hevner 53

Refactoring
 Programmers restructure the system without
changing its behavior to remove duplication,
improve communication, simplify, or add
flexibility.
 Procedure for implementing iterative design
 behavior-preserving
 improves communication among developers
 adds flexibility to the programming process
 Design is important – do it all the time
 software development process is a design process
 But redesign much more expensive for large systems

August 30, 2018 Copyright © 2018 Alan R. Hevner 54

Pair Programming
 All code is written by two programmers at
a single machine
 Inspections are important, so do them all
the time
 Increase implicit knowledge transfer
 Decrease cycle time, but increase effort

August 30, 2018 Copyright © 2018 Alan R. Hevner 55

Costs and Benefits of Pair Programming
 Reference: Williams and Kessler, Pair Programming
Illuminated, Addison-Wesley, 2003.
 Benefits
 Mistakes get caught as they are being made.
 Defect content is lower.
 Designs are better and code length shorter.
 Team solves problems faster.
 Individuals learn significantly more.
 Multiple people understand each piece of the system.
 People learn to work together and talk more often together.
 People enjoy their work more
 Costs
 15% overhead

August 30, 2018 Copyright © 2018 Alan R. Hevner 56

Collective Ownership
 Anyone can change any code anywhere in the
system at any time.
 Everyone owns all of the code
 anyone can change any code anywhere
 no personal ownership of modules
 no egoless programming either
 Everyone is permitted access to all the code so
everyone has a stake in knowing all of the code
(that they will work with)
 Requires deserved trust
 But still has scalability problems

August 30, 2018 Copyright © 2018 Alan R. Hevner 57

Continuous Integration
 Integrate and build the system many times
a day, every time a task is completed.
 The system always works
 there is always something to be released
 Similar to rapid releases
 fast feedback to developers on problems
 no ‘big bang’ integration disasters

August 30, 2018 Copyright © 2018 Alan R. Hevner 58

40-hour Week
 Work no more than 40 hours a week as a
rule.
 No heroes
 Knowledge can only be transferred at a
limited rate
 Work for sustained speed, not a single
sprint
 never work overtime a second week in a row
August 30, 2018 Copyright © 2018 Alan R. Hevner 59
On-site Customer
 A real, live user available full-time to
answer questions as they occur
 Programmers don’t know everything
 Business knowledge is the key to a
successful business project

August 30, 2018 Copyright © 2018 Alan R. Hevner 60

Coding Standards
 Programmers write all code in
accordance with rules emphasizing
communication through the code.
 Common standard promotes
understanding of other developers’ code
 Helps promote team focus

August 30, 2018 Copyright © 2018 Alan R. Hevner 61

August 30, 2018 Copyright © 2018 Alan R. Hevner 62
Scrum
 Scrum is a popular agile method with well-
defined roles, activities, and artifacts
 Scrum Overview
 https://www.scrumalliance.org/agile-
resources/overview-of-the-scrum-framework

August 30, 2018 Copyright © 2018 Alan R. Hevner 63

Controls in Flexible Software Development
 Flexible software development processes
provide clear control mechanisms to
manage progress and quality
 Control Theory is used to understand the
control mechanisms in both Plan-Driven
and Agile Processes
 M. Harris, R. Collins, and A. Hevner, “Control of Flexible Software Development
under Uncertainty,” Information Systems Research: Special Issue on Flexible and
Distributed Information Systems Development, September 2009.
 M. Harris, A. Hevner, and R. Collins, "Controls in Flexible Software Development,"
Communications of the Association for Information Systems: Vol. 24, Article 43,
2009. Available at: http://aisel.aisnet.org/cais/vol24/iss1/43.
August 30, 2018 Copyright © 2018 Alan R. Hevner 64
 85% of CIOs indicate agility
is part of core business
strategy
Motivation (Ware 2004)

 Plan-driven vs agile?  Comparing agile

 FBI Virtual Case Project methods
$170 Million
 Process studies use assertions
 Plan-driven may feel more
& proof of concept
successful (Zelkowitz et al. 1998)
(MacCormack et al. 2001)

 Agile versus ad hoc?  Adapting agile

 Agile Manifesto methods (Boehm 2004)
(Beck 2001)

Plan Driven

Controlled
Flexibility Ad Hoc

August 30, 2018 Copyright © 2018 Alan R. Hevner 65

Control Theory
Knowledge of Transformation Process

Perfect Imperfect

Availability of High Behavioral or Outcome Outcome

Outcome
Measures Low Behavioral Clan

 Control theory  Portfolios of control

(Ouchi 1977, 1979, 1980; Ouchi et al (Orlikowski 1991, Henderson 1992, Kirsch
1978; Kirsch 1996, 1997, 2004) 1997, Choudhury et al. 2003, Nidumolu et
al. 2003-2004)
 Clan / Self-control
 Clan-Team Control  Dynamic controls
(Orlikowski 1991, Choudhury et al. 2003,
 Clan-Attitude Control Cardinal et al. 2004, Kirsch 2004)
 Over time, controls need to change

 Adaptable controls?

August 30, 2018 Copyright © 2018 Alan R. Hevner 66

Example Development Processes

Waterfall Rational Synchronize Extreme

Unified And Programming
Process Stabilize

Changes Changes Changes

Discouraged Expected Encouraged

August 30, 2018 Copyright © 2018 Alan R. Hevner 67

Emergent Outcome Controls
 Traditional outcome control
 A priori specification
 Flexible processes
 Outcomes emerge throughout development
 Actively manage emergent outcomes
 Two types of emergent outcome control mechanisms
 Scope boundaries
 Limit amount of creativity
 Time limit
 Functional limit
 Ongoing feedback
 User Representatives
 Market / Technical Feasibility
 Example: Incremental development
August 30, 2018 Copyright © 2018 Alan R. Hevner 68
Traditional vs. Emergent Control

August 30, 2018 Copyright © 2018 Alan R. Hevner 69

Extreme Programming Example

August 30, 2018 Copyright © 2018 Alan R. Hevner 70

 Process Controls Compared
Synchronize & Extreme
Waterfall RUP Stabilize Programming

 Flexibility requires broader portfolio of

controls
 Emergent outcome controls important for
flexibility

August 30, 2018 Copyright © 2018 Alan R. Hevner 71

Research ModelEnvironment Development Processes Results

H1 H2
Plan Driven Processes
- -
Controlled Flexible Processes
Unpredictability + Emergent Outcomes + + Product-
-Market •Bounded Scope Market
-Technology Match
+ •Ongoing User Feedback -
Ad-hoc H3

 H1: As the market and technology become less predictable, software

development is less likely to be managed using a plan-driven method.
 H2: In an uncertain environment, mechanisms that manage emergent
outcomes are more likely to match the market’s needs than a plan-
driven method.
 H3: In an uncertain environment, mechanisms that manage emergent
outcomes are more likely to match the market’s needs than an ad hoc
approach.

August 30, 2018 Copyright © 2018 Alan R. Hevner 72

DevOps
 DevOps (a combination of "development" and "operations") is
a software engineering culture and practice that aims at unifying
software development (Dev) and software operations (Ops).
 The main characteristic of the DevOps movement is to strongly
advocate automation and monitoring at all steps of software
construction, from integration, testing, releasing to deployment
and infrastructure management.
 DevOps aims at shorter development cycles, increased
deployment frequency, more dependable releases, in close
alignment with business objectives.
 References:
 https://devops.com/
 https://theagileadmin.com/what-is-devops/

August 30, 2018 Copyright © 2018 Alan R. Hevner 73

DevOps Goals
 Improved deployment frequency
 Faster time to market
 Lower failure rate of new releases
 Shortened lead time between fixes
 Faster mean time to recovery (in the event of a
new release crashing or otherwise disabling the
current system)
 Enhanced customer experience
 Increased innovation capacity

August 30, 2018 Copyright © 2018 Alan R. Hevner 74

DevOps - Basics
 DevOps applies agile and lean principles across
the entire software supply chain
 Enhanced customer experience
 Increased innovation capacity
 Faster time to value
 Lower failure rates and faster mean time to recovery
 DevOps requires an organizational culture shift
 Operations
 Development
 Quality Assurance - Testing

August 30, 2018 Copyright © 2018 Alan R. Hevner 75

DevOps Transformation
 The process of transforming and adapting a
software development methodology in
accordance with Agile development methods
as opposed to the older Waterfall technique.
 Thanks to this transformation, development
and operations teams are no longer siloed
and are often merged into a single unit where
development and operations teams work
across the entire application cycle enabling
efficient DevOps processes.

August 30, 2018 Copyright © 2018 Alan R. Hevner 76

Shift Left

August 30, 2018 Copyright © 2018 Alan R. Hevner 77

DevOps Process

August 30, 2018 Copyright © 2018 Alan R. Hevner 78

State of DevOps in 2018
 Interop ITX Research Report
 https://www.interop.com/reports

August 30, 2018 Copyright © 2018 Alan R. Hevner 79

Returning to the Boehm and Turner Text

 Chapter 3
A Day in the Life of XP Project
 A Day in the Life of an TSP Project
 Chapter 4
 Scaling up Agile Methods – Bad Smells
 Lease Management Case Study
 Streamlining Plan-Driven Methods
 Command Center Processing and Display System
Replacement

August 30, 2018 Copyright © 2018 Alan R. Hevner 80

Using Risk to Balance
Discipline and Agility - Overview
Step 1. Step 2. Discipline risks
Risk Analysis Risk dominate Go Risk-driven
Comparison Agile
Rate the project’s
environmental, agility- Compare
oriented and discipline- the agile
Go Risk-driven
oriented risks. and
Agility risks Disciplined
disciplined
risks dominate

Neither dominate
Uncertain No
about
Step 3.
ratings? Architecture
Analysis
Go Risk-driven
Yes Agile in agile
Architect application to
parts; Go Risk-
encapsulate agile parts
Buy information via driven Disciplined
prototyping, data elsewhere
collection and analysis

Step 5.
Execute and Monitor

Deliver incremental
capabilities according to Tailor life cycle process
strategy around anchor point
commitment milestones
Monitor progress and
risks/opportunities,
readjust balance and Step 4.
process as appropriate Tailor Life Cycle

August 30, 2018 Copyright © 2018 Alan R. Hevner 81

Risks Used in Risk Comparison
 Environmental risks
 Technology uncertainties
 Many stakeholders
 Complex system-of-systems
 Agility-oriented risks
 Scalability
 Use of simple design
 Personnel turnover
 Too-frequent releases
 Not enough agile-capable people

 Discipline-oriented risks
 Rapid change
 Need for rapid results
 Emergent requirements
 Not enough discipline-capable people

August 30, 2018 Copyright © 2018 Alan R. Hevner 82

Three Examples
 Agent-based systems
 Small – Event Managers application
 Medium – SupplyChain.com application
 Large – National Information System for
Crisis Management (NISCM) application
 Each example results in a development
strategy based on risk analyses

August 30, 2018 Copyright © 2018 Alan R. Hevner 83

Event Managers Project
 Small startup company
 Diverse set of smaller agent-based planning
applications
 This project: support for managing the
infrastructure and operations of conferences and
conventions
 Widening variety of options and
interdependencies, makes an agent-based
approach highly attractive

August 30, 2018 Copyright © 2018 Alan R. Hevner 84

 Event Managers Profile
Risk Items Risk Ratings
Event Managers Personnel
Environmental Risks (% Level 1B) (% Level 2&3)
E1. Technology uncertainties  40 15

E2. Many stakeholders  30 20

E3. Complex system of systems 

Risks of using Agile Methods  20 25

A1. Scalability  Criticality

Dynamism
(Loss due to impact of defects)
A2. Use of simple design 
10 30
(% Requirements-change/month)
A3. Personnel turnover  Many 0 35
1
A4. Too-frequent releases  Lives Single
Life
Essential
Funds Discretionary
10
5

30
A5. Not enough agile-capable people  Funds Comfort
50

Risks of using disciplined methods  3

D1. Rapid change 

90

10
D2. Need for rapid results  70
30
D3. Emergent requirements  50

D4. Not enough discipline-capable  100

30
people 300
Risk rating scale:  - Serious but manageable risk Size 10

 - minimal risk  - Very serious but manageable risk (# of personnel) Culture
(% thriving on chaos vs. order)
 - moderate risk  - Show-stopper risk

August 30, 2018 Copyright © 2018 Alan R. Hevner 85

 Event Managers Strategy
1. Startup 2. Design, Development and Deployment
Teambuilding and Shared
Vision

Customer
Management;
Representative
Users

• Establish CRACK joint

management team
• Develop shared vision,
• Test, exercise, deploy new increment
results chain, life cycle
• Re-prioritize next-increment features
strategy, infrastructure
• Analyze lessons learned; prepare
choices
strategy for next increment
• Establish commitment
Joint Developer- to proceed, incremental
Customer Agile Team
capabilities, backlog
• Develop next-increment
features

August 30, 2018 Copyright © 2018 Alan R. Hevner 86

SupplyChain.com Profile
 Turnkey agent-based supply chain management
systems
 Distributed, multi-organization teams of about 50
people
 Parts of applications are relatively stable, while
others are highly volatile
 Architectures are driven by a few key COTS
packages that are also continually evolving

August 30, 2018 Copyright © 2018 Alan R. Hevner 87

 SupplyChain.com Profile
Risk Items Risk Ratings
SupplyChain.com
Environmental Risks Personnel
(% Level 1B) (% Level 2&3)
E1. Technology uncertainties  40 15

E2. Many stakeholders  20

30
E3. Complex system of systems 
Risks of using Agile Methods  20 25

A1. Scalability  Criticality

(Loss due to impact of defects) Dynamism
10 30
A2. Use of simple design  (% Requirements-change/month)

A3. Personnel turnover  Many

Lives Single
0 35
5
1

A4. Too-frequent releases 

Essential 10
Life Discretionary
Funds 30
Funds Comfort
50

A5. Not enough agile-capable people  3

Risks of using disciplined methods  90

D1. Rapid change 

10
70

D2. Need for rapid results 

30
50

D3. Emergent requirements  100

30

D4. Not enough discipline-capable  300

people Size 10

(# of personnel) Culture
Risk rating scale:  - Serious but manageable risk (% thriving on chaos vs. order)
 - minimal risk  - Very serious but manageable risk
 - moderate risk  - Show-stopper risk

August 30, 2018 Copyright © 2018 Alan R. Hevner 88

 SupplyChain.com Strategy
Startup 1. 2. Systems 3. Design, Development and Deployment
Teambuilding Definition and
and Shared Architecting • Ensure representative • Use risk to determine
Furnish CRACK Vision exercise of incremental content of artifacts
representatives capabilities
and alternates • Monitor progress and
• Elaborate supply new operational • Communicate • Analyze
chain operational development proposed feedback on
• Develop benefits-
Stakeholders
realization results concept, prototypes, redirections current
chains transition strategy • Prepare for and version
Project • Evaluate and
• Identify missing execute • Reprioritize
Manager and
stakeholders determine COTS, • Monitor project progress, acceptance features
Risk
Management • Enhance mutual Review; reuse, and Review; risk resolution, and new tests, • Prepare
Team understanding Commit architecture choices Commit technology installation, strategy for
• Explore goals, to • Prioritize and to developments operational next
options, technology, proceed sequence desired proceed • Identify and work critical evolution increment
prototypes, risks capabilities, project-level actions • Consolidate
outstanding risks process
• Establish project lessons
organization, overall learned
Staff and process, and feature
organize to cover teams
all success-
critical risk areas • Develop and integrate
new feature increments

Agile Feature Team

August 30, 2018 Copyright © 2018 Alan R. Hevner 89

NISCM Profile
 Broad coalition of government agencies and
critical private-sector organizations
 Support cross-agency and public-private sector
coordination of crisis management activities
 Adaptive mobile network, virtual collaboration,
information assurance, and information
integration technology
 Private-sector system-of-systems integration
contractor

August 30, 2018 Copyright © 2018 Alan R. Hevner 90

 NISCM Profile
Risk Items Risk Ratings
NISCM
Environmental Risks
Personnel
E1. Technology uncertainties  (% Level 1B) (% Level 2&3)
E2. Many stakeholders  40 15

E3. Complex system of systems  30 20

Risks of using Agile Methods 

A1. Scalability  —  20 25

A2. Use of simple design  —  Criticality

(Loss due to impact of defects) 10 30
Dynamism
A3. Personnel turnover  (% Requirements-change/month)

A4. Too-frequent releases  Many

Lives Single
0 35
5
1

A5. Not enough agile-capable people  — 

Essential 10
Life Discretionary
Funds 30
Funds Comfort
50
Risks of using disciplined methods 
D1. Rapid change  3
90

D2. Need for rapid results  10

70

D3. Emergent requirements  30

D4. Not enough discipline-capable 

50

100

people 30

Risk rating scale:  - Serious but manageable risk

300
Size 10

 - minimal risk  - Very serious but manageable risk (# of personnel) Culture
 - moderate risk  - Show-stopper risk (% thriving on chaos vs. order)

August 30, 2018 Copyright © 2018 Alan R. Hevner 91

 NISCM Strategy
Startup Teambuilding Systems Design, Development and
and Shared Definition and Deployment
Vision Architecting

• Prepare for/select • Ensure representative

competitors for exercise of incremental
Furnish CRACK component subcontract capabilities
representatives • Develop results chains definition • Monitor progress and new
and alternates • Identify missing • Elaborate operational operational development
stakeholders concept, prototypes,
• Enhance understanding transition strategy
• Explore goals, options, Hold Life • Evaluate/determine Hold Life
Stakeholders technology, prototypes, Cycle COTS, reuse, and Cycle
risks Objective architecture choices Architecture
• Negotiate mutually Review. If • Develop/ validate critical- Review. If • Use risk to determine content of
satisfactory objectives feasibility infrastructure software feasibility artifacts
and priorities rationale is • Prioritize/sequence rationale is
• Staff and organize • Formulate top-level valid, desired capabilities, valid,
to cover all operational concept, commit to outstanding risks commit to • Communicate • Analyze
• Monitor project progress,
success-critical requirements, proceed • Formulate definitive proceed proposed feedback on
risk resolution, and new
risk areas architecture, life cycle operational concept, redirections current
technology developments
• Prepare for and plan, feasibility rational requirements, • Prepare for version
• Identify/work critical project-
select competitors • Select winning system architecture, life cycle and execute • Reprioritize
level actions
for concept integration contract plan, feasibility rationale acceptance features
• Continuously integrate/ test
definition • Use to solicit/select tests, • Prepare
growing software
component installation, strategy for
infrastructure and
subcontractors operational next
NSO and I3-led Project components
evolution increment
Risk Management Team

Plan, specify,
develop stable,
• Develop compatible higher-criticality
Organize module
Stable, Higher-criticality component-level
into increments
Module Teams prototypes, requirements, disciplined
architectures, plans, and agile
critical software, feasibility module Plan, specify,
rationale teams develop dynamic,
• Classify modules by likely
lower-criticality
stability and criticality module
Dynamic, Lower-criticality
Module Teams increments

August 30, 2018 Copyright © 2018 Alan R. Hevner 92

Risk Profiles Across Examples
Risk Items Risk Ratings
Event Managers SupplyChain.com NISCM
Environmental Risks
E1. Technology uncertainties   
E2. Many stakeholders   
E3. Complex system of systems   
Risks of using Agile Methods   
A1. Scalability    — 
A2. Use of simple design    — 
A3. Personnel turnover   
A4. Too-frequent releases   
A5. Not enough agile-capable people    — 
Risks of using disciplined methods   
D1. Rapid change   
D2. Need for rapid results   
D3. Emergent requirements   
D4. Not enough discipline-capable people   
Risk rating scale:  - Serious but manageable risk
 - minimal risk  - Very serious but manageable risk
 - moderate risk  - Show-stopper risk

August 30, 2018 Copyright © 2018 Alan R. Hevner 93

Conclusions (Chapter 6)
 Neither agile nor disciplined methods provide a silver
bullet
 Agile and disciplined methods have home grounds
where one clearly dominates the other
 Future trends are toward application developments that
need both agility and discipline
 Some balanced methods are emerging
 It is better to build your method up than to tailor it down
 Methods are important, but potential silver bullets are
more likely to be found in areas dealing with people,
values, communications, and expectations
management.

August 30, 2018 Copyright © 2018 Alan R. Hevner 94

Software Project Cost Estimation

 Extremely difficult and error-prone task.

 Essential skill for Project Managers
 Three Basic Techniques
 Expert Judgment – Use your most experienced analyst
 Analytic Models – All models are wrong, some are useful.
 COCOMO II -
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

 Analogy – Case Based Reasoning

 Find a previous project that resembles the new project

August 30, 2018 Copyright © 2018 Alan R. Hevner 95

Estimation Process
 Step 1 – Estimate Size of the Product
 Lines of Code
 Function Points
 Step 2 - Estimate the Effort
 Person-Months
 Identify Staff Resources (Number and Skills)
 Step 3 – Estimate the Schedule
 Calendar Months
 Step 4 – Present your estimates in ranges and
periodically refine the ranges as the project
progresses.

August 30, 2018 Copyright © 2018 Alan R. Hevner 96

Estimation Guidelines
 Avoid off-the-cuff estimates.
 Plan adequate time for preparing estimates.
 Use data from previous projects.
 Involve your team in generating estimates.
 Estimate by walk-through.
 Estimate by categories.
 Estimate at a low level of detail.
 Don’t omit common tasks.
 Use software estimation tools.
 Use several different estimation techniques and compare results.
 Change estimation practices as the project progresses.
 Modify estimates based on type of system to be built.
 System product
 Business product
 Mass-market product
 Build Optimistic, Efficient, and Nominal schedules

August 30, 2018 Copyright © 2018 Alan R. Hevner 97

Class 2 Discussion Question
 Consider a recent software development project in which
you have participated. Did your process need more
discipline or more agility to be effective? Why?

August 30, 2018 Copyright © 2018 Alan R. Hevner 98