Transcript ITEC 2010A Systems Analysis and Design I The Analyst as

ITEC 2010A
Lecture 4
CASE tools and the Life Cycle continued
(end of chapter 3)
System Development Life Cycle (SDLC)
Variations
• Traditional approach: “Waterfall method” – only
when one phase is finished does the project team
drop down (fall) to the next phase
– Fairly rigid approach – decisions at each phase get
frozen
– Can’t 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
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
SDLC Variations
• 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
Iteration
• 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
• Iteration: 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
The “Classic” Waterfall Life Cycle
Project planning
Analysis
Design
Implementation
A newer method: rapid prototyping (with iteration)
Requirements
Gathering (Analysis)
Quick
Design
Build
Prototype
Evaluate and
Refine Requirements
Engineer
Project
Prototyping tool requirements
• 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)
Spiral life cycle
• 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
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)
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
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
Types of CASE tools
• Upper CASE tools
– Support analyst during the analysis and design phases
• Lower CASE tools
– Support for implementation – eg. 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 modelling
• Based on UML standard for object orientation
• Allows for reverse-engineering and code generation (can
integrate with other tools like Visual C++ etc.)
• “Round trip engineering” – synchronized updating
Background: The case for CASE
• Why need CASE?
– As software systems get large and more complex they have
become prone to unpredictable behaviour and bugs
– Problem of systems that are not reliable, do not meet
requirements or that just plain don’t work!
– CASE tries to eliminate or reduce design and development
problems
– Ultimate goal of CASE is to separate the application
program’s design (and analysis) from the program’s code
implementation
• Generally, the more detached the design process is from actual
coding, the better
• Traditional software development emphasized programming and
debugging, CASE focuses on good analysis and design
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
• 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
• 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
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
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 (eg. 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
Evolution of Software Tools
CASECode generators
CASEAnalysis +
Design
sophistication
Debuggers
Compilers
Assemblers
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
Analysis and Design in More Detail
Overview:
• Analysis phase defines in detail what the
information systems needs to accomplish (do)
• Alternative design ideas should emerge from this
analysis
• The best design alternative should be selected
from them
• During design phase the selected alternative is
designed in detail
Analysis Phase Activities
• Gather Information
– Involves gathering lots of information
– Can get information from people who will be using the
system
• By interviewing them
• By observing them
– Can get other information by reviewing documents and
policy statements (eg. At a bank)
– Can involve the analyst actually doing some or part of
the task to get a feel for what is done
• In order to automate order-entry you may need to become an
“expert” on the task (knowing how orders are processed)
– Need to understand current and future users, locations,
system interfaces, possible solutions, etc.
• Define System Requirements
– Technical Requirements
• Eg. Facts about needed system performance, no. of
transactions
– Functional Requirements
• What the system is required to do (e.g. reduce fuel costs by
calculating where is best to fuel up)
– Involves modelling
• Logical Model
– Any model that shows what the system is required to do without
committing to any one technology – requirements model is
logical
• Physical Model
– Any model that shows how the system will actually be
implemented
• Models are often graphical in nature
– Data flow diagrams (DFDs)
– Entity-relationship diagrams (ERDs)
• Prioritize Requirements
– Important to establish which functional and technical
requirements are most critical
– Why? Since resources are always limited and you want
to address the most important things
– If not addressed can lead to “scope creep”, where the
scope of the project just seems to expand over time
• Prototype for Feasibility and Discovery
– If system involves new technology the team may need
to get exposed to it
– Good idea for projects where requirements are hard to
define beforehand
• By showing prototypes to end users can get feedback into what
is really needed (e.g. showing end users or management)
– Prototypes help users (and analysts) to think creatively
• Generate and Evaluate Alternatives
– Could include considering more than one method to
develop system
– Could involve in-house development or outsourcing to
to a consulting firm
– Might be able to use “off the shelf” software package
– Each alternative has costs and benefits to be considered
– Also must consider technical feasibility
• Review Recommendations with Management
– Usually done when all the above are completed
– Must decide if project should continue at all
– Must decide on which alternative is best (if you are
going ahead with the project)
– NOTE – at this point should include CANCELLATION
of project an option
• May have found costs were too high
• May have found benefits were lower than thought
• Maybe the business environment suddenly changed making the
project obsolete
– Detailed documentation has been collected
• System requirements
• Proposed design solution
Design Phase Activities
• Prototype for Design Details
– Want to continue to create and evaluate prototypes
(could involve some usability engineering methods)
– Often associated with interface design, or to confirm
design choices (e.g. database, programming
environments etc.)
– Think of how to use prototypes to help understand
design decisions
– Important part of rapid application development (RAD)
• Design the User Interface
– To the user “the interface IS the system”
– Nature of user interface emerges very early during
design
– Need specification of the kind of tasks the users will
complete
– Activity of user interface design occurs during system
design phase
– Can involve iterative development and refinement of
user interfaces (testing with end users)
– Range of interface options increasing
• Graphical user interfaces (GUIs)
• Network user interfaces (e.g. for the WWW)
• Design the System Interfaces
– No real system exists in a vacuum
– Will probably need to interface with other systems and
databases
– All systems should be designed to work together from
the beginning
– Interfacing problems can be quite complex (e.g. health
care information systems that can’t “talk” to each
other!)
• Design the Application Architecture
– Specifying in detail how all system activities will be
carried out
– These activities are specified as logical models at first
– Once a specific design alternative is selected, the
physical models can be designed
– Decision has to be made about automation boundary
– Models could include
• Physical data flow diagrams
• Structure charts
• Object-interaction diagrams
– Approach to application design will vary depending on
the technology being used
• E.g. Web based Java application versus COBOL program
• Design and Integrate the Network
– May need to change existing network or develop one
– May need to call in experts on networking
– Issues
•
•
•
•
Reliability
Security
Throughput
Ability for systems to “talk” to each other
• Design and Integrate the System Controls
– Need to ensure system has adequate safeguards to
protect organizational assets -- system controls
– Must be considered in the context of
•
•
•
•
User interfaces
System interfaces
Application architectures
Database and network design
– Control over access to system (by authorized users
only)
– Database controls ensure that data cannot be
accidentally (or maliciously) altered
– Network controls also essential!