ITEC 4010: Systems Analysis and Design II.

1. ITEC 4010: Systems Analysis and Design II. Professor Peter Khaiter

2. Lecture 4 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. Lecture 4 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 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

4. Lecture 4 4 SDLC Variations (cont.)

5. Lecture 4 5 SDLC Variations (cont.)

6. Lecture 4 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. Lecture 4 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. Lecture 4 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. Lecture 4 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. Lecture 4 10 The “Classic” Waterfall Life Cycle

11. Lecture 4 11 A newer method: rapid prototyping (with iteration)

12. Lecture 4 12 Iteration in SDLC (cont.)

13. Lecture 4 13 The Prototyping Approach to Development

14. Lecture 4 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. Lecture 4 15 Prototyping Approach (cont.)

16. Lecture 4 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. Lecture 4 17 Spiral life cycle (cont.)

18. Lecture 4 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. Lecture 4 19 Multiview SDLC

20. Lecture 4 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. Lecture 4 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. Lecture 4 22 CASE Approach (cont.)

23. Lecture 4 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. Lecture 4 24 Types of CASE tools (cont.)

25. Lecture 4 25 Types of CASE tools (cont.)

26. Lecture 4 26 Types of CASE tools (cont.)

27. Lecture 4 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. Lecture 4 28 Evolution of Software Tools

29. Lecture 4 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. Lecture 4 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. Lecture 4 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. Lecture 4 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. Lecture 4 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