Itec 2010a lecture 4 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

ITEC 2010A Lecture 4 PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

ITEC 2010A Lecture 4

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 l.jpg

ITEC 2010ALecture 4

CASE tools and the Life Cycle continued

(end of chapter 3)


System development life cycle sdlc variations l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

  • 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 l.jpg

The “Classic” Waterfall Life Cycle

Project planning

Analysis

Design

Implementation


Slide10 l.jpg

A newer method: rapid prototyping (with iteration)

Requirements

Gathering (Analysis)

Quick

Design

Build

Prototype

Evaluate and

Refine Requirements

Engineer

Project


Slide13 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

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 l.jpg

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 l.jpg

Evolution of Software Tools

CASE-

Code generators

CASE-

Analysis +

Design

sophistication

Debuggers

Compilers

Assemblers


Current status of case l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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 l.jpg

  • 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!


  • Login