Some notes for Software Engineering

by Herbert J. Bernstein
© Copyright 1999, 2002 Herbert J. Bernstein

Development Methodologies

• Software/Systems/Applications Development Life Cycles
• Confusion between methodologies and cycles
• A cycle is a fact
• A methodology is a plan for dealing with facts
• Cycles are circular
• There are many possible cycles (see http://www.itmweb.com/essay552.htm
  • Systems are born and die and new generations carry on
  • Change is a constant
• Stages
• Definition of the problem (Conception)
• Needs Analysis (Definition of Requirements)
• Consideration of Alternatives (Feasibility Analysis)
• Creating a solution (Labor)
• Detailed design
• Construction
• Testing
• Implementing a solution (Delivery)
• Installation and handoff
• Initial Operation and Support (Raising the child)
• Improvements, bug fixes, …
• Mature Operation and Support (Leaving home)
• Obsolescence (Old age, retirement and death)
• Waterfall life cycle model
  • Life-cycle for newly created systems, being created in isolation from other systems
  • Ideally, each stage is completed correctly and "signed-off" before going to the next
  • In practice, it is necessary to go back "up-hill" and iterate
• Evolutionary life cycle model
  • Existing software "spawns" new software
  • Designs derived from existing designs
  • Software components derived from existing components (templates)
  • Later stages of life cycle of existing products happen in parallel with earlier stages for newly spawned products
  • No barrier to going "up-hill"
  • Chaotic and Darwinian
  • Assumes "open design", "open source" environment
• "Fifth-generation" formal life-cycle
  • Designs are created
  • Designs are automatically translated into software
• Spiral life cycle model
  • Development in related layers
  • Like waterfall, each layer feeds into the next
  • Essential waterfall stages with each layer
  • Similar phases within each layer replace backtracking in waterfall
• Methodologies
• Spontaneous creation
• Waterfall -- stage by stage with no backtracking
• Waterfall with backtracking
• Evolutionary development -- many phases happen in parallel
• Formal development
• Spiral development
• JAD, PD, RAD -- techniques used in all of the above
• Classic development
• IT controls and drives the development process
• IT staff acts as hub
• Respond to users/managers one at a time
• Joint Application Development
• Users/managers drive the development process
• Highly structured, formal, group-oriented process
• Face to face interactions among major stakeholders and developers
• Roles
• Facilitator
• Plans the process
• Independently guides the process (not subordinate to any party)
• Resolves disputes
• Ensures followthough
• Scribe
• Keep and disseminate records of the meeting(s)
• Stakeholders
• Managers
• Identify business needs
• Users
• Identify operational needs
• Developers
• Primarily listen to understand the evolving specification
• Respond when necessary via the facilitator
• JAD preparation
• Defining the project, identifying stakeholders, participants, etc.
• Preliminary research
• Initial needs analysis
• Consideration of alternatives
• Session preparation
• Space, amenities, infrastructure
• Visual aids, CASE tools, etc.
• JAD sessions
• Clear agenda
• Allocated time for each topic
• Intensive, no distractions
• Heavy use of visual aids, CASE, prototypes
• Face-to-face
• All parties must be heard, all parties equal
• Spanning days or weeks until all issues are resolved
• Work towards group concensus
• Final report
• Participatory Design
• Bring together users and developers
• Bypass middle managers
• Design with users, not by users, not for users
• Simulate problems and solutions, model systems, play "games"
• Work bottom up from the real or proposed workflow
• Rapid Application Development
• Bring together users and developers into formal focus groups, JAD-like
• Informal PD-like and web-based communications encouraged
• Early and frequent prototyping, with "fake" models as with PD
• Users test designs and prototypes
• Extensive use of reusuable components
• Formal use of version control systems
• Drop features to stay on schedule ("timeboxing")
• Iterate until the project is complete
• JAD/PD/RAD differences (derived in part from web page formerly at http://sern.ucalgary.ca/~bowen/613/jad/)
• PD less structured, less formal than JAD
• RAD combines some of the features of PD and JAD
• JAD and RAD focus on quantitative measures
• PD focuses on qualitative measures
• RAD will produce a result, but it may not be what was needed
• JAD and RAD treat managers as users
• PD treats managers as distinct from actual users