ITEC 4010: Systems Analysis and Design II'

1
ITEC 4010 Systems Analysis and Design II.
Lecture 4System Development Part IIIReview

• Professor Peter Khaiter

2
Topics

• System Development Life Cycle Variations
• Iterations in System Development Life Cycle
• The Prototyping Approach to Development
• CASE Approach to Development
• Causes of failure in Software Development
• Stats on Software Errors

3
System Development Life Cycle (SDLC) Variations

• Traditional approach Waterfall method only
  when one phase is finished the project team drop
  down (fall) to the next phase
• Fairly rigid approach decisions at each phase
  get frozen
• Cant easily go back to previous phases (each
  phase would get signed off)
• Good for traditional type of projects, e.g.
  payroll system or system with clearly definable
  requirements
• Not as good for many of the new types of
  interactive and highly complex applications
• applications where it is hard to specify all
  requirements once and for all

4
SDLC Variations (cont.)
FIGURE 4-1 The waterfall model of the SDLS.
5
SDLC Variations (cont.)
FIGURE 4-2 Life cycles with different names for
phases.
6
Differences in Approaches

• Traditional approach include feasibility study at
  beginning, with system investigation and systems
  analysis as the Analysis phase
• Information engineering includes earlier part of
  cycle information strategy planning, as first
  phase
• The objectory model includes only four phases
• Despite differences, the same overall tasks need
  to be carried out e.g. planning, analysis,
  design and implementation

7
Differences in Approaches (cont.)

• The pure waterfall approach is less used now
• The activities are still planning, analysis,
  design and implementation
• However, many activities are done now in an
  overlapping or concurrent manner
• Done for efficiency when activities are not
  dependent on the outcome of others they can also
  be carried out

8
Iteration in SDLC

• Iteration assumes no one gets the right results
  the first time
• Do some analysis, then some design, then do some
  further analysis, until you get it right
• Idea not always realistic to complete analysis
  before starting design
• Waterfall no longer applies - Phases become
  blurred
• Decisions are not frozen at the end of each phase
• Good for projects where requirement
  specifications are hard to arrive at
• However, can lead to ambiguity
• Harder to know how far you are along in the
  project
• Could be hard to manage

9
Iteration in SDLC

• Iteration is the process of looping through the
  same development activities multiple times,
  sometimes at increasing levels of detail or
  accuracy
• Information engineering can be done with
  iteration
• Object-oriented approach considered to be highly
  iterative
• Example Iterative design and development of user
  interfaces in health care can cycle iteratively
  through the following
• Design interface
• Test (evaluate) with users early on (video-based
  usability testing)
• Redesign, based on results of testing with users

10
The Classic Waterfall Life Cycle
Project planning
Analysis
Design
Implementation
11
A newer method rapid prototyping (with iteration)
Requirements Gathering (Analysis)
Quick Design
Build Prototype
Evaluate and Refine Requirements
Engineer Project
12
Iteration in SDLC (cont.)
FIGURE 4-5 Iteration across life cycle phases.
13
The Prototyping Approach to Development
FIGURE 4-6 A system development approach based
on developmental prototypes.
14
Prototyping Approach (cont.)

• Flexibility and power needed for fast development
• WYSIWYG (what you see is what you get)
  development of interface components
• Generation of complete programs, program
  skeletons etc.
• Rapid customization of software libraries or
  components
• Sophisticated error-checking and debugging
  capabilities
• In example on next slide you can easily draw
  the interface, by selecting buttons, menus etc.
  and dragging onto the screen (e.g. Visual Basic)

15
Prototyping Approach (cont.)
FIGURE 4-7 Development of a user interface
prototype using WYSIWYG dialog box editor.
16
The Spiral Approach to Development

• Project starts out small, handling few risks
• Project expands in next iteration to address more
  risks
• Eventually the system is completed (all risks
  addressed)
• At the middle (start of the project) there is low
  risk and project is still small easy to manage
• You work out from the middle, expanding out your
  project

17
Spiral life cycle (cont.)
FIGURE 4-8 The spiral life cycle model.
18
Variations based on an emphasis on people

• Sociotechnical systems
• Systems that include both social and technical
  subsystems
• Both social and technical subsystems must be
  considered
• User-centered design/Participatory design
• Example in text Multiview
• Activity analysis (activity theory)
• Actors and activities they do (not in text)
• Diagram not just system functions but human
  activity as well
• Main idea Human activity must be studied in
  detail (as well as technical aspects) often
  forgotten!!
• Example study of activity in intensive care
  unit as basis for system design (versus expert
  system approach)

19
Multiview SDLC
FIGURE 4-9 Phases of the multiview SDLC
20
Variations based on speed of development

• RAD Rapid Application Development
• Try to speed up activities in each phase
• E.g. scheduling intensive meetings of key
  participants to get decisions fast
• Iterative development
• Building working prototypes fast to get feedback
  (can then be directly expanded to finished
  system)
• If not managed right can be risky

21
Computer-Aided System Engineering (CASE)

• CASE tools Software tools designed to help
  system analyst complete development tasks
• The CASE tool contains a database of information
  called a repository
• Information about models
• Descriptions
• Data definitions
• References that link models together
• Case tools can check the models to make sure they
  are complete and follow diagramming rules
• Also can check if the models are consistent
• Adds a number of capabilities around the
  repository

22
CASE Approach (cont.)
FIGURE 4-10 A CASE tool repository contains all
information about the system.
23
Types of CASE tools

• Upper CASE tools
• Support analyst during the analysis and design
  phases
• Lower CASE tools
• Support for implementation e.g. generating
  programs
• Tools may be general, or designed for specific
  methodology (like for information engineering
  TIs IEF, CoolTools)
• Examples of CASE tools
• Visual Analyst for creating traditional models
• Called integrated application development tool
• Rational Rose for object-oriented modeling
• Based on UML standard for object orientation
• Allows for reverse-engineering and code
  generation (can be integrated with other tools
  like Visual C etc.)
• Round trip engineering synchronized updating

24
Types of CASE tools (cont.)
FIGURE 4-11 The CASE tool Visual Analyst showing
a data flow diagram.
25
Types of CASE tools (cont.)
FIGURE 3-23 The visual modeling tool Rational
Rose showing diagrams from the object-oriented
approach
26
Types of CASE tools (cont.)
FIGURE 3-24 The round-trip engineering tool
Together J showing a class diagram with
synchronized Java source code.
27
What CASE can do to help

• Help to make analysis and design process more
  rigorous and complete, to reduce bugs later
• Examples of functions in tools
• Provide support for diagramming (for analysis and
  design)
• Provide support for checking consistency of
  design
• Provide graphing support to help users visualize
  an existing or proposed information system (e.g.
  Data flow diagrams)
• Detail the processes of your system in a
  hierarchical structure
• Produce executable applications based on your
  data flow diagrams (which can be made from point
  and click placements of icons)
• Integrate specific methodologies into windowing
  environments

28
Evolution of Software Tools
CASE- Code generators
CASE- Analysis Design
sophistication
Debuggers
Compilers
Assemblers
29
Current Status of CASE

• A number of commercial products
• Some aspects (e.g. diagramming support) are
  widely applicable and useful
• Other features such as code generation are more
  specific
• CASE tools not so successful for generic code
  generation
• However, specific code generation is now being
  used for things such as user interface design
  (e.g. Visual C allows you to draw the
  interface and it generates the code)
• As ideas become successful often no longer called
  CASE

30
Causes of failure (and symptoms) in software
development

• Requirements Analysis
• No written requirements
• Incompletely specified requirements
• No user interface mock-up
• No end user involvement (can happen may have
  talked to clients BUT not users!)
• Design
• Lack of, or insufficient, design documents
• Poorly specified data structures and file formats
• Infrequent or no design reviews

31
Causes of failure (and symptoms) in software
development (cont.)

• Implementation
• Lack of, or insufficient coding standards
• Infrequent or no code reviews
• Poor in-line code documentation
• Unit test and Integration
• Insufficient module testing
• Lack of proper or complete testing
• Lack of an independent quality assurance group

32
Causes of failure (and symptoms) in software
development (cont.)

• Beta Test Release
• Complete lack of a beta test
• Insufficient duration for beta test
• Insufficient number of beta testers
• Wrong beta testers selected
• Maintenance
• Too many bug reports
• Fixing one bug introduces new bugs

33
Stats on Software Errors (large systems)

• Most software errors originate in the Analysis
  and Design phases (65)
• Unfortunately, less than one-third of these
  errors are caught before acceptance testing
  begins
• About 35 of errors occur during coding
• Cost of fixing an error goes up the later it is
  caught!
• This is basis for emphasis in CASE on Analysis
  and Design