Advanced Information Systems Analysis and Design: Class 2: System Development Processes and Methods

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

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?

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.

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.
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

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
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."

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.
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??

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.
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

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/

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

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

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
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

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

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

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)

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)

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.

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.
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

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)

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
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

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

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

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

V-Model with Incremental Development
Evolved Software Development Process Model
(with Incremental Development)
Customer Acceptance
System Test Scripts

Software Architecture System Integration
Incremental Dev. Plan System Test
Subsystem
Subsystem Test
Incremental Implementation
Development Cycle
Unit Test
Figure 2

V-Model with Specification
(with Inc. Dev. and Functional/Usage Specifications)
Customer Acceptance
Functional Usage
Specification Specification
Box Structure
Representations
Software Architecture System Test Scripts System Integration
Incremental Dev. Plan System Test

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

V-Model with Cleanroom Testing
(with Inc. Dev., Func./Usage Spec., and Correctness Verification/Statistical Testing)
Customer Acceptance
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
Development Cycle
Figure 4

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

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.

The Frameworks Quagmire

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/

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

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.

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.

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.

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.

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

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

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”

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”
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”

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

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

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

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

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

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

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

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

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

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

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

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
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

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

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

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.
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

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?

Example Development Processes
Waterfall Rational Synchronize Extreme

Unified And Programming
Process Stabilize
Changes Changes Changes

Discouraged Expected Encouraged

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
Traditional vs. Emergent Control

Extreme Programming Example

Process Controls Compared
Synchronize & Extreme
Waterfall RUP Stabilize Programming
 Flexibility requires broader portfolio of

controls
 Emergent outcome controls important for
flexibility

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.

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/

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

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

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.

Shift Left

DevOps Process

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

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

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

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

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

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

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

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

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

SupplyChain.com Profile
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

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

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

NISCM Profile
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)

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

Risk Profiles Across Examples
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

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.

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

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.

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

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?

Advanced Information Systems Analysis and Design: Class 2: System Development Processes and Methods

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Information Systems Analysis and Design: Class 2: System Development Processes and Methods

Uploaded by

Copyright:

Available Formats

Advanced Information Systems

Analysis and Design

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

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

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

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

 Development discipline enforces well-

 Both have strengths and weaknesses

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inception Elaboration Construction Transition

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

System Test Scripts

Software Design Test Scripts Subsystem Integration

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

System Test Scripts

Incremental Dev. Plan System Test

Software Design Test Scripts Subsystem Integration

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

Incremental Dev. Plan System Test

Software Design Test Scripts Subsystem Integration

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

Incremental Dev. Plan

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

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

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

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

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

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

 Individuals and interactions over processes and tools

That is, while there is value in the items on

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

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

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

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

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

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

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

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

-Used generatively, not imperatively

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

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

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

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

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

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

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

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