Itec 2010a lecture 4
Download
1 / 48

ITEC 2010A Lecture 4 - PowerPoint PPT Presentation


  • 109 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 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

Project planning

Analysis

Design

Implementation


Slide10 l.jpg

A newer method: rapid prototyping (with iteration) development activities multiple times, sometimes at increasing levels of detail or accuracy

Requirements

Gathering (Analysis)

Quick

Design

Build

Prototype

Evaluate and

Refine Requirements

Engineer

Project


Slide13 l.jpg

Prototyping tool requirements development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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) development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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) development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

CASE-

Code generators

CASE-

Analysis +

Design

sophistication

Debuggers

Compilers

Assemblers


Current status of case l.jpg
Current Status of CASE development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

  • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

    • 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 development activities multiple times, sometimes at increasing levels of detail or accuracy

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


ad