MD 240 Systems Development

1
MD 240Systems Development
2
Key Ideas

• Software and systems development is notoriously
  tricky
• Most development projects fail get used to it
• Many methodologies for managing and improving IS
  development
• Tradeoffs between software development methods
• extent of understanding of end user requirements
• flexibility of development process
• size of development team
• location of development team

3
Common Criticisms of Software Development Projects
4
Common Criticisms of Software Development Projects

• Physical product designers are much better at
  making successful, high quality products,
  compared to software developers
• Physical products are easier to design because
  they are tangible, whereas software is
  intangible, and thus more difficult to design
• Software development projects are too unique to
  be able to manage them well

5
Common CriticismsProduct Developers Better Than
IS Developers

• Software Development is NOT like Bridge 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

6
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
14-4
7
UPSIDE Failure is a 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)
• Through failure, we learn how to eventually
  succeed

8
Common CriticismsSoftware Projects Too Unique To
Manage

• EXPERT VIEW (Steve McConnell) 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.)

9
Assuming You Dont Want to Play Gilligan in Your
Future Job
10
Achieving Desirable MIS Development Project
Outcomes
11
Desirable MIS Project Outcomes

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

12
Desirable MIS Project Outcomes

• Low maintenance
• Scalability
• of system capacity
• Integration with other systems
• Minimal negative cross impacts
• Reusability
• of software components from this project during
  future development projects

13
Strategic TradeoffsEnd-Users and ISD Must 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 developed by the project
• 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)

14
Strategic Tradeoffs

• 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

15
Background
16
Evolution of Development Environment
Technologies

• Architectures
• Monolithic, main-frame based Terminal/Mainframe
• Standalone PC Applications
• 2/3-tier, Client/Server Fat clients,
  proprietary servers or Databases
• n-tier, distributed Web/Browser based clients,
  Application/Web servers, legacy system
  integration, Databases etc.
• Web Services
• Languages
• VB, C, C, Smalltalk, Cobol, PL1, Fortran,
  Pascal, HTML etc.
• New Java, JavaScript, dynamic HTML, XML,
  Scripting Languages, etc.

17
Evolution of Development Environment
Technologies

• Communication/Transactional Technologies
• RPC, proprietary Messaging (e.g. MQS), CICS, IMS,
  embedded SQL etc.
• CORBA, RMI /IIOP, XML, SOAP, JTS, JMS, WebDAV,
  WAP, JDBC, SQL/J etc.
• Databases
• Relational DBMS, Hierarchical DBMS (IMS)
• Entity Beans (using O/R mapping technologies),
  and still RDBMS, OODBMS
• Component Architectures
• Platform-dependent Microsoft COM/DCOM etc.
• Platform-independent J2EE (JSP, Servlet, EJBs,
  Beans, ), Web Services etc.

18
Evolution of Development Paradigm
Continuous Evolution
Monolithic Applications
Distributed Applications
Hardly no code reuse
Reusable components web services
Proprietary, platform specific technologies
Standardized, platform independent technology
Distributed, global team development
Centralized, local development
Standalone, single developer, point solution
products
Integrated, multi-developer, and web-enabled
products
19
Evolution of Development Paradigm

• Modern Management Issues
• Very fast paced new world doesnt allow for long
  software development life cycles
• Rapid release cycles may compromise quality,
  reliability and scalability
• Competition is only a few mouse-clicks away and
  might develop competitive solutions in web
  time

20
Potential Problems During Software Development
21
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.)

22
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

23
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

24
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

25
Avoid Problems by Using an Appropriate Software
Development Methodology
26
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.

27
SDLC Management Methods

• Pure Waterfall
• Code-and-Fix
• Spiral Model
• 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.

28
SDLC Methodology Landscape
Waterfall Model Spiral Model/ Modified Waterfall
Model Rapid Application Development (RAD) Rapid
Prototyping Rational Unified Process
(RUP) Adaptive Software Development
(ASD) Step-by-Step eXtreme Programming
(XP) End-User Development
Order
Big Brother
Predictive
Adaptive
Cowboy Coding
Chaos
29
A Caveat ...

• Methodologies, Products Technologies
• provide help with being more successful,
• but they are not the answer without a team that
  is qualified and disciplined about a process, and
• the process is meaningless without being tied to
  real business objectives

30
Highly Structured Development Methodologies
31
Early SDLC The Waterfall Method

• 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
32
Eight-Stage Waterfall SDLC

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

33
Eight Stage Modified Waterfall SDLC
34
Modified Waterfall (Overlapping Stages)Benefits
and Risks

• 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

35
STAGE 1Project Initiation

• Functional Manager
• Formal planning process
• IS organization

36
STAGE 2Feasibility Studies

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

37
STAGE 3Logical Analysis and Design

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

38
STAGE 4Actual Design, Acquisition and/or
Development

• Generic IS functions input, output, and storage
• Modeling tools
• Data Flow Diagrams
• Entity Relationship Diagrams
• CASE tools
• User involvement

39
STAGES 5 6Implementation and Operation of
Systems

• Parallel conversion
• Direct cutover
• Pilot conversion
• Phased

40
STAGES 7 8Post-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

41
Modern Flexible/Adaptive Development Methods for
Teams Developing Complex or Time-Critical Software
42
Environments of Traditional SDLCs vs. Modern SDLCs

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

43
Modern SDLC MethodsCommon Development Artifacts

• Business case / model
• Requirements analysis
• Use-case model / user activities
• Software architecture / design (UML)
• Risk assessment
• List of open issues
• Project / Release / Development / Deployment plan
• Prototypes
• Reusable components
• Software product
• Documentation / User manuals etc.

44
Modern SDLC MethodsCommon Development Tools
Software Tools for Team Development

• With global, collaborative team development,
  appropriate team development tools become more
  important
• Such required tools support

• Requirements capture
• Visual modeling
• Configuration mgt. version control
• Component development
• Component assembly
• Tools for automated testing

• Performance quality analysis
• Cross dependency planning and defect tracking
• Online collaboration tools
• Customer Support etc.

45
Unified Modeling Language (UML) Development Tools
46
Unified Modeling Language (UML) Development Tools
47
Unified Modeling Language (UML) Development Tools
48
Unified Modeling Language (UML) Development Tools
49
Modern SDLC Methods Complex or Quickly Needed
Systems

• Rapid Application Development (RAD)
• Rapid Prototyping
• Object-Oriented Development (OOD)
• Rational Unified Process (RUP)
• Extreme Programming (XP)
• LINUX Open Source Approach
• End-User Development (EUD)

50
Rapid Application Development (RAD)Components
and Capabilities

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

51
Rapid Prototyping

• Focus 1 develop something quickly from the
  users initial set of requirements
• get it into the users hands
• get feedback quickly
• 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?

52
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

53
Object-Oriented Development

• Use OO modeling techniques and software
  components
• Benefits
• Reduces complexity of systems development
• Systems are quicker and easier to build and
  maintain
• Improves productivity
• Objects may be reused in future projects
• Systems are more flexible
• Allows system analysts to think in real world
  terms
• Ideal for Web development

54
Rational Unified Process (RUP)

• Based on four phases
• Inception, Elaboration, Construction, and
  Transition
• Employs UML OO techniques and tools
• Allows for iteration within phases and across
  phases
• Defines the following workflows
• Core process workflowsBusiness Modeling,
  Requirements, Analysis Design, Implementation,
  Test, Deployment
• Core supporting workflowsConfiguration Change
  Mgmt., Project Mgmt., and Environment
• More Info www.rational.com

55
Extreme Programming (XP)

• eXtreme Programming, developed by Kent Beck, 1996
• XP uses very iterative approach
• Based upon four values
• Communication, simplicity, feedback, and courage
• Twelve XP practices support the four values
• Release iteration planning, small releases,
  metaphor, simple design, testing, refactoring,
  pair programming (two programmers work together),
  collective ownership, continuous integration, 40
  hour week, on-site customer, coding standards

56
LINUX Open Source Development Approach

• Violates fundamental software development rules
• Academics theorized that beyond a certain number
  of programmers, development teams become
  non-functional due to complexity of the process
• Based on an academic gift culture
• The more software you give, the more you are
  respected
• Thoroughly uses Internet to spread programming
  tasks across the world to thousands of
  programmers
• Core group that controls whether their
  contributions are included
• Alpha, beta, final versions are distributed by
  the Internet, allowing programmers across the
  world to very quickly contribute to debugging of
  program
• Development cycle much faster than corporate
  development cycles

57
Modern SDLCsBest Practices Common to Modern
Methods

• Enforce application lifecycle process (an SDLC)
• Plan phases and iterations
• Do not only predict, also be adaptive in process
• Involve customer in all phases
• Evolve artifacts ( process) over iterations
• Keep it simple, only create necessary artifacts
• Use parallel engineering
• Use and design reusable components
• Create prototypes

58
Modern SDLCsBest Practices Common to Modern
Methods

• Apply common design patterns
• Apply coding standards
• Code Reviews
• Refactor code whenever necessary
• Use pair programming where reasonable
• Test, test test even more as early as possible
• Create automated unit-, integration-,
  regression-, performance-test, etc.
• Track and manage defects, open issues changes
  in a unified defect management tool/process

59
Modern SDLCsHow to Avoid Problems
Avoiding Problems With SDLC Process

• Make process seamless through appropriate
  automation and integrations
• Keep process simple
• The format of your process itself is not as
  important as the activity and thought that go
  into producing it
• Typical measures of a process are
• Reliability, Predictability, Repeatability across
  teams and applications / projects / products
• An underestimated measure of project process
  success is the morale of the team at the end of
  the project

60
Modern SDLCsHow to Avoid Problems
Avoiding Development Team Problems

• Great team-players are much more important than a
  group of individual superstars
• Fit the tasks to the skills and motivation of the
  people available
• Embrace cultural diversity and use it to your
  benefit
• Develop a team spirit which makes each team
  member proud to be part of the process

61
Pure Cowboy Coding
62
End-User Development

• Many end users are now sophisticated enough to
  program their own software
• Benefits
• Development speed
• Business orientation
• Small applications
• Control
• Apparent cost savings

63
End User Development Problems to be Managed by ISD

• EUD often necessitates additional spending
• Hardware/Software/Training/Support
• Employees may be neglecting other duties
• E-Us may have limited managerial or technical
  skills
• Software can have unknown problems (e.g.
  quality/bugs)
• Employee many not know how to manage SDLC
• Documentation often lacking
• End user assumes he/she will be the only one ever
  using
• Software may become critical to organization
• Security

64
End User Development

• Best Practices
• Auditing EUD programs
• Dividing computing responsibilities

65
References

• Ewe, Lars, (WebGain, Inc.) Team Development for
  Modern Applications, Sun JavaOne, BOF-1510, June
  5, 2001, San Francisco, CA.