1. ITEC 2010A Lecture 4 CASE tools and the Life Cycle continued (end of chapter 3)

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

5. 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

6. 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

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

8. 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

9. The “Classic” Waterfall Life Cycle Analysis Design Implementation Project planning

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

13. 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)

15. 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

17. 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. 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

20. 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. 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

26. 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

27. 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

28. 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

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

30. 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

31. 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

32. Assemblers Compilers Debuggers CASE- Analysis + Design CASE- Code generators Evolution of Software Tools sophistication

33. 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

34. 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

35. 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.

36. 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)

37. 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

38. 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

39. 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

40. 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

42. 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)

43. 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)

44. 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!)

45. 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

46. 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

47. 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!