ITEC 2010A Lecture 4

1. ITEC 2010ALecture 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 Project planning Analysis Design Implementation

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

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!