MD 240 Systems Development

1
MD 240Systems Development
2
Why Do MIS Books Apologize and Criticize the
History of Failures in IS Development?
3
Systems Development Adage 1 Other Developers
Better Than IS Developers

• Software Development is NOT like Bridge Building
  (or House Building)
• Bridges (Houses)
• Built on-time
• Built on-budget
• Do not fall down
• Software
• Never comes in on-time
• Never comes in on-budget
• Always breaks down
• Caveats
• Bridges do fall down LA earthquake/Tacoma
  Narrows Bridge
• Post-1980 houses were so well architected that
  they do not breathe, meaning that most mold in
  place fall apart DO NOT BUY

4
Grim Reality of Design Development Human
Track Record Uniformly Poor

• Formal Development Methods?
• Many thousands of books (more than other areas?)
• Marketing product design techniques
• TQM, QFD
• Flowcharting Service blueprints
• Study under a master
• Personal intuition
• How to books

• Things Humans Create
• Information Systems
• Goods
• Services
• Creative Works (Books, Songs, Paintings)

Failures? Obviously many, from your textbooks
statements many studies confirm Many (ex Food
industry, 10,000 new products introduced yearly,
most fail) So many they coined term Honeymoon
Effect consumers tire of service Most songs,
paintings, book ideas never get started, few
reach any market
5
Systems Development Adage 2 Gilligans
Island IS/IT Development

• Most organizations attempts at systems
  development are like Gilligans Island.
• At the beginning of each episode, Gilligan, the
  Skipper, or the Professor comes up with a
  cockamamie scheme to get off the island.
• The scheme seems as though it is going to work
  for a while, BUT
• As the episode unfolds, something goes wrong, and
  by the end of the episode, the castaways find
  themselves back where they started stuck on the
  island.
• Most companies make classic mistakes during
  systems development, leaving them back on the
  island (behind schedule, over cost, etc.)

6
Failure is a Necessary Cost of Determining Good
Designs and Development Practices

• . . . the Tacoma Narrows bridge failure has
  given us invaluable information . . . . It has
  shown that every new structure which projects
  into new fields of magnitude involves new
  problems for the solution of which neither theory
  nor practical experience furnish an adequate
  guide. It is then that we must rely largely on
  judgment and if, as a result, errors or failures
  occur, we must accept them as a price for human
  progress.
• (Othmar Ammann, lead Tacoma Narrows bridge
  designer, member of the Federal Works Agency
  Commission investigating the collapse of the
  Tacoma Narrows Bridge)

7
Assuming You Dont Want to Play Gilligan How
can we avoid getting hit with the Skippers hat
at the end of a project?
8
Desirable IS Outcomes

• On-time
• On-budget
• Full functionality
• User acceptance
• Favorable costs-to-benefits ratio

9
Desirable IS Outcomes

• Low maintenance
• Scalability
• Integration with other systems
• Minimal negative cross impacts
• Reusability

10
Translating Desirable Outcomes into
StrategyWhat Must ISD and End-Users Choose
Between?

• Cost
• objective low
• Delivery Time/Schedule
• objective as fast as possible
• able to meet fixed drop-dead dates
• runaway prevention
• Flexibility
• of software / of systems
• of development process
• Quality
• objective high/perfect quality of conformance to
  specified design
• objective high quality of software design (i.e.,
  it satisfies users needs perfectly)

11
Inevitable Tradeoffs in any Product Development

• High quality (design, conformance) may cost more
• High quality (design, conformance) may take
  longer time
• Flexible development process may allow better
  quality of design
• Flexible development process may result in lower
  conformance quality (software bugs)
• Flexible development process may extend
  development time
• Note Context Dependent
• Space Shuttle/Airplane life critical gt OFTEN
  CANNOT MAKE TRADEOFFS, MUST DO IT RIGHT THE
  FIRST TIME
• Word Processor Functioning and use is subjective
  gt EASIER TO DO

12
Potential Troubles Head-Hunters, Monkeys
Throwing Coconuts During Development ...
13
Preventing Potential ProblemsWhat Are They?

• Classic People-Related Mistakes
• Undermined motivation
• Weak personnel
• Uncontrolled problem employees
• Heroics - (Ill save the day!)
• Adding people to a late project
• Noisy, crowded offices
• Friction between developers and customers
• Unrealistic expectations
• Lack of effective project sponsorship
• Lack of user input
• Politics placed over substance
• Wishful thinking - (No problem! Ill have it
  done in a week!)
• Source Rapid Development, Steve McConnell
• Note Quotes are my personal classic mistakes.

14
Preventing Potential ProblemsWhat Are They?

• Classic Process-Related Mistakes
• Overly optimistic schedules
• Insufficient risk management
• Contractor failure
• Insufficient planning
• Abandonment of planning under pressure - (Were
  too far behind! Just code the ! thing!)
• Wasted time during the fuzzy front end
• Shortchanged upstream activities
• Inadequate design
• Shortchanged quality assurance
• Insufficient management controls
• Premature or overly frequent convergence
• Omitting necessary tasks from estimates
• Planning to catch up later
• Code-like-hell programming

15
Preventing Potential ProblemsWhat Are They?

• Classic Product-Related Mistakes
• Requirements gold-plating
• Feature creep - (This is fantastic! But could
  you also add this?)
• Developer gold-plating
• Push-me, pull-me negotiation
• Research-oriented development
• Source Rapid Development, Steve McConnell

16
Preventing Potential ProblemsWhat Are They?

• Classic Technology-Related Mistakes
• Silver-bullet syndrome
• Overestimated savings from new tools or methods
• Switching tools in the middle of a project
• Lack of automated source-code control - (Surely
  Im not stupid enough to work on the same file
  that youre working on at the same time.)
• Source Rapid Development, Steve McConnell

17
How Might We Avoid Development Problems?
18
Systems Development Life Cycle (SDLC)

• An SDLC represents a set of general categories
  that show the major steps, over time, of an
  information systems development project.

19
A Menu of SDLC Types

• Pure Waterfall
• Code-and-Fix
• Spiral
• Modified Waterfall
• Sashimi (Waterfall With Overlapping Phases)
• Waterfall With Sub-Projects
• Waterfall With Risk Reduction
• Evolutionary Prototyping
• Staged Delivery
• Design-to-Schedule
• Evolutionary Design
• Design-to-Tools
• Commercial Off-the-Shelf Software
• Forget the development, I can buy software
  packages that give me sufficient functionality
  and hook em all together.

20
The Waterfall Method Early SDLC

• Non-Overlapping Stages
• Milestones well-defined
• Easier to evaluate performance
• Little continuity of developer teams across
  stages
• Hand-off of planning documents between stages
• Works well for well-understood yet complex
  projects

Finished Planning Document Flow
Team A Stage A
Team B Stage B
Send it Back. They need to Revise Their Plan!
Team C Stage C
21
An Eight-Stage SDLC

• Project initiation
• Feasibility study
• Logical analysis and design
• Acquisition and development
• Implementation
• Operation
• Post-audit evaluation
• Maintenance

22
Eight Stage SDLC Sashimi is essentially what
youll be doing
23
Sashimi SDLC ApproachWaterfall with
Overlapping Stages

• Benefits
• Reasonable approach for many problems
• Good for small, well-defined projects
• Works well when you have personnel continuity
  across stages
• Drawbacks
• Milestones more ambiguous
• Harder to track progress
• Parallel processes may lead to miscommunication,
  mistaken assumptions, inefficiency

24
Project Initiation

• Functional Manager
• Formal planning process
• IS organization

25
Feasibility Studies

• Technology
• Economics
• Organizational factors
• Legal, ethical, and other constraints

26
Logical Analysis and Design

• Determine the systems functions
• How will it accomplish those functions
• Logical design
• Physical design / technical design

27
Logical Design

• Generic IS functions input, output, and storage
• Modeling tools DFDs, ERDs
• User involvement

28
Implementation of Systems

• Parallel conversion
• Direct cutover
• Pilot conversion
• Phased

29
Post-Audit Maintenance

• Post-Implementation (or Post-Failure) Audit
• Very important - how else do you learn what you
  did right and/or wrong?
• Reality Once youre done, project teams break up
  or move away, inhibiting audit
• Maintenance
• Cleaning up bugs in the system
• Ongoing redesigns to improve functionality

30
What if you need to quickly develop complex
softwareto solve complex problems?
31
Beyond Simple WaterfallsTraditional vs. Modern
SDLC

• Traditional SDLCs
• Early systems replaced existing processes
  problems often were well known
• Modern Development
• Minimal overhead
• Flexibility and responsiveness
• Concurrent tasks
• Focused analysis

32
Methods for Complex or Quickly Needed Systems

• Prototyping
• Rapid Application Development (RAD)
• Object-Oriented Development (OOD)
• End-User Development (EUD)

33
Prototyping

• In many ways, the opposite of an old-style SDLC
• Focus 1 develop something quickly from the
  users initial set of requirements
• Focus 2 refine and extend the prototype based
  on the users requirements, which are identified
  by using the prototype
• Is this what you were asking us for?
• Note also used often in designing goods

34
Rapid Application Development

• Rapid Application Development (RAD)
  methodologies and tools have capabilities to meet
  the demands of the new environment.

35
Components and Capabilities of RAD

• GUI development environment
• Reusable components
• Code generator
• Programming language

36
RAD Best Practices

• Change Board
• Daily Build and Smoke Test
• Designing for Change
• Evolutionary Delivery
• Evolutionary Prototyping
• Goal Setting
• Inspections
• Joint Application Development (JAD)
• Measurement
• Miniature Milestones
• Outsourcing
• Principled Negotiation
• Rapid-Development Languages
• Requirements Scrubbling

• Reuse
• Signing Up
• Spiral Lifecycle Model
• Staged Delivery
• Theory-W Management
• Throwaway Prototyping
• Timebox Development
• Tools Group
• Top-10 Risks List
• User-Interface Prototyping
• Voluntary Overtime
• Source Rapid Development, Steve McConnell

37
Object-Oriented DevelopmentBenefits

• Reduces complexity of systems development
• Systems are quicker and easier to build and
  maintain
• Improves productivity
• Objects may be reused

38
Object-Oriented DevelopmentBenefits

• Systems are more flexible
• Allows analysis to think in real world terms
• Ideal for Web development

39
End-User DevelopmentTrends

• Increasingly powerful desktop hardware
• Declining hardware costs
• Increasingly diverse software capabilities
• Increasingly computer-literate population
• Backlog of IS projects

40
End-User DevelopmentTrends

• Development speed
• Business orientation
• Small applications
• Control
• Apparent cost savings

41
EUD Problems

• Additional spending
• Hardware
• Software
• Training
• Support
• Neglecting other duties
• Limited managerial technical skills
• Documentation
• Security

42
EUD Solutions

• Auditing EUD programs
• Dividing computing responsibilities

43
More InformationBuy a Steve McConnell Book