Around 1990: All is not well in IS land; productivity questions
& poor software engineering:
Yourdon, E. (1992) Decline and Fall of the American
Programmer.
Gibbs, W. (1994): Software's Chronic Crisis (Kock, p. 4):
U.S. software industry: total 1990: $100B; off-the-shelf
(10%), 1998: $135B off-the-shelf.
75% of all software are operational failures.
25% of all large development initiatives canceled.
Average schedule overshoot 50%.
Problem:
so what was going on?
"...plexuses of brittle logic..."
Mary Shaw
SEI (Carnegie Mellon) Capability Maturity Model (CMM).
CMM Scores Gibbs (1994):
261 teams rated.
Stage 1 Initial: 75%.
Stage 2 Repeatable + Stage 3: Defined: 24%.
Stage 5: Optimized: 2.
SW-CMM 1998-2002:
1345 organizations.
508 companies.
6,765 projects.
47.1% offshore organizations.
Scores:
Level 1 Initial: 16.9%.
Level 2 Repeatable: 43.2%.
Level 3 Defined: 24.6%.
Level 4 Managed: 8%.
Level 5: Optimized 7.3%.
Gibbs' solutions:
Software engineering as 'engineering.'
Documented process.
Attitude change.
Certification?
Formalized design (formal methods/UML).
Kock:
Tom
DeMarco: Structured Analysis and
System Specification. Prentice-Hall, 1979.
1980s: CASE tools... Still a promise?
p.3: "Systems analysis and
design emerged from the need to
perform certain activities around, and particularly prior to, the steps
involved in developing a computer system using software engineering
tools and techniques."
Problem: p.3:
Analysis and design a "necessary evil"?
Design as
Engineering (Experimental Stress Analysis Notebook,
1994):
"Design is the essence of engineering."
"Design is the art of engineering."
"Design is the intent of engineering."
Design for the four F's (Dally (1997) Introduction
to
Engineering Design):
Function: does the product/service/device do what it
is
supposed to do?
Fit: does the design permit all components and
subcomponents to fit and operate together (architecture)?
Is there a nominal fit; a fit in principle (meet minimum
constraints)?
Tolerances and exception handling on the interfaces
between
components.
Form & Finish: Ergonomics and handling.
Figure 1.1 (p. 4) Cost of fixing errorsvs. project stage.
2/3 or more of system life cycle cost occurs after!
development
(implementation & long-term maintenance).
Problem:
what
do
you think of the shape of the curve in Figure 1.1. E.g., why would it be exponential?
Problem:
What
about the overall cost curve? What about long-term maintenance?
p. 5/6: Systems (or Software) Development Life Cycle;
the waterfall model:
System planning:
Analysis of existing problems and/or opportunities.
Specification of measures of success of the solution
(evaluation/impact assessment starts here).
Feasibility study:
Evaluation of existing and possible (new) architectures
(technical
feasibility).
Phasing estimates.
Estimates of organizational requirements (organizational
feasibility).
Project management plan.
Cost/benefit estimates (economic feasibility).
Prepares an organization for the commitment to an IS.
Needs analysis or requirements definition &
analysis:
Inventory of business processes and the role of people,
tasks, programs and information in this process:
Can we conceptualize the business processes as a set of
tasks?
Who and what are conducting these tasks?
How does information flow along and between tasks?
Which task needs which information? When? For how long?
How precise and reliable must information be to serve the task?
Business Process Management (BPM) extensions:
What ar the stochastic (probabilistic) components of
these processes?
What (probability) distributions do they follow?
How do these processes behave (dynamics).
Can we simulate these processes so that we can conduct
'what if' analysis?
Can we simulate these processes for optimization?
Etc.
System design: (Problem:
Kock's 'Design' entry (see table 1.1)?)
Functional design:
User functions (user interfaces).
Data processing functions.
Architectural design:
Main components, statics & dynamics of the
information
infrastructure.
1, n tier solution specifications.
Specification of third party tools vs. in-house vs.
outsourced development.
Specification of OSs, languages, development tools.
Etc.
Software design:
Database schema (if applicable).
Datatypes, classes, functions, etc.
File structures.
Internal vs.
external information.
Development:
Development environment:
Indiv. developer environments.
Code repositories (e.g., RCS-->CVS, SourceSafe
-->Team Foundation
Server, Subversion, etc.)
Overnight builds.
Regression testing.
Profilers, debuggers, IDEs, etc.
System release policy.
Bug tracking tools.
Program documentation policies and tools.
Database development:
Generation of schema.
Physical layout.
Population:
Static tables.
Dynamic tables.
(Simulation/optimization) model development:
Integrate existing model codes.
Develop new (additional) codes.
Link models with the database(s).
Develop QA/QC codes.
Develop user interfaces and link with other components.
Develop system/batch system codes.
Test:
Testing protocols (unit & integration).
Testing environments.
Processing of test results.
Implementation or rollout:
Hardware and third-party software installations.
System releases and/or installation on sponsor's
computers.
All-or-nothing cutover.
Parallel systems.
On-site system testing.
User training.
Maintenance:
User support.
Continued bug tracking, fixing and performance
enhancements.
Release update/patch processes & tools.
OS/system updates.
Documentation updates.
Additional system development.
User training.
System Development models & philosophies:
Waterfall
(see above):
Kock: "does
not
address business process
redesign" (p. 6).
Problem: is
this a fundamental critique against the waterfall model?
Problem: p.
7/8: contrast the waterfall model with object-oriented programming.
