ITEC 4010: Systems Analysis and Design II.

1. ITEC 4010: Systems Analysis and Design II. Professor Peter Khaiter Lecture 4System Development Part IIIReview

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

4. SDLC Variations (cont.) FIGURE 4-1 The waterfall model of the SDLS. Lecture 4

5. SDLC Variations (cont.) FIGURE 4-2 Life cycles with different names for phases. 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 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 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 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 Lecture 4

10. The “Classic” Waterfall Life Cycle Project planning Analysis Design Implementation Lecture 4

11. A newer method: rapid prototyping (with iteration) Requirements Gathering (Analysis) Quick Design Build Prototype Evaluate and Refine Requirements Engineer Project Lecture 4

12. Iteration in SDLC (cont.) FIGURE 4-5 Iteration across life cycle phases. Lecture 4

13. The Prototyping Approach to Development FIGURE 4-6 A system development approach based on developmental prototypes. 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) Lecture 4

15. Prototyping Approach (cont.) FIGURE 4-7 Development of a user interface prototype using WYSIWYG dialog box editor. 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 Lecture 4

17. Spiral life cycle (cont.) FIGURE 4-8 The spiral life cycle model. 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) Lecture 4

19. Multiview SDLC FIGURE 4-9 Phases of the multiview SDLC 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 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 Lecture 4

22. CASE Approach (cont.) FIGURE 4-10 A CASE tool repository contains all information about the system. 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 Lecture 4

24. Types of CASE tools (cont.) FIGURE 4-11 The CASE tool Visual Analyst showing a data flow diagram. Lecture 4

25. Types of CASE tools (cont.) FIGURE 3-23 The visual modeling tool Rational Rose showing diagrams from the object-oriented approach Lecture 4

26. Types of CASE tools (cont.) FIGURE 3-24 The round-trip engineering tool Together J showing a class diagram with synchronized Java source code. 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 Lecture 4

28. Evolution of Software Tools CASE- Code generators CASE- Analysis + Design sophistication Debuggers Compilers Assemblers 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 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 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 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 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 Lecture 4