itec 2010a lecture 4 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ITEC 2010A Lecture 4 PowerPoint Presentation
Download Presentation
ITEC 2010A Lecture 4

Loading in 2 Seconds...

play fullscreen
1 / 48

ITEC 2010A Lecture 4 - PowerPoint PPT Presentation


  • 113 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ITEC 2010A Lecture 4' - benicio


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
itec 2010a lecture 4
ITEC 2010ALecture 4

CASE tools and the Life Cycle continued

(end of chapter 3)

system development life cycle sdlc variations
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
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
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
  • 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
slide8
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
slide9

The “Classic” Waterfall Life Cycle

Project planning

Analysis

Design

Implementation

slide10

A newer method: rapid prototyping (with iteration)

Requirements

Gathering (Analysis)

Quick

Design

Build

Prototype

Evaluate and

Refine Requirements

Engineer

Project

slide13

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
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
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
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
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
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
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
slide27

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
slide28
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
slide29
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
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
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
slide32

Evolution of Software Tools

CASE-

Code generators

CASE-

Analysis +

Design

sophistication

Debuggers

Compilers

Assemblers

current status of case
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
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
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.
slide36
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)
slide37
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
slide38
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
slide39
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
slide40
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
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)
slide43
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)
slide44
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!)
slide45
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
slide46
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
slide47
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!