SYSTEM DEVELOPMENT Dr Manolya Kavakli Department of Computing Macquarie University Sydney, Australia SYSTEM DEVELOPMENT This repository of slides is intended to support the named chapter. The slide repository should be used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector. Each slide includes instructor notes. To view those notes in PowerPoint, click-left on the View Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor notes. The instructor notes are also available in hardcopy as the Instructor Guide to Accompany Systems Analysis and Design Methods, 6/ed.

Systems Analysis Phases Scope Definition (Preliminary investigation) Phase Is the project worth looking at? Problem Analysis Phase Is a new system worth building? Requirements Analysis Phase What do the users need and want from the new system? Logical Design Phase What must the new system do? Decision Analysis Phase What is the best solution? Conversion Notes The phases correspond to the following fifth edition terms: Scope definition = former Preliminary investigation Problem analysis (no change from 5 ed) Requirements analysis (no change from 5 ed) Logical design (new in 5 ed) Decision analysis (no change from 5 ed)

Scope Definition Phase Context Teaching Notes The focus is on system owner perspectives.

Tasks for the Scope Definition Phase Teaching Notes This is called a task diagram for a phase. This is a look “inside” a phase. It decomposes the phase into its component tasks . It is only a guideline. Each project will adapt these tasks to the project at hand. Tasks may be added, split, or deleted according to the methodology and route used. The dashed line is a control flow (as contrasted to a solid data flow). In this case, it represents a decision that determines whether the next task is necessary.

Sample Request for System Services Teaching Notes Not all businesses have a formal document to initiate projects.

Sample Problem Statements Teaching Notes Alternatively, this information could be documented in a business memo or report. Define columns for students and walk through sample

Scope Definition Phase Steering body – a committee of executive business and system managers that studies and prioritizes competing project proposals to determine which projects will return the most value to the organization and thus should be approved for continues systems development. Also called a steering committee. Project charter – the final deliverable for the preliminary investigation phase. A project charter defines the project scope, plan, methodology, standards, and so on. Preliminary master plan includes preliminary schedule and resource assignments (also called a baseline plan). Detailed plan and schedule for completing the next phase of the project. Teaching Notes Completion of the project charter represents the first milestone in a project The project, in most cases, must be approved by the steering body before it can proceed

Context of Problem Analysis Phase Teaching Notes The focus is on both system owner and system user perspectives. We are looking at the building blocks of the existing system.

Tasks for Problem Analysis Phase No additional notes

Cause-and-Effect Analysis Cause-and-effect analysis – a technique in which problems are studied to determine their causes and effects. In practice, effects can be symptomatic of more deeply rooted or basic problems which, in turn, must be analyzed for causes and effects until such a time as the causes and effects do not yield symptoms of other problems. Teaching Tip Analyze a problem using cause-and-effect analysis. If you know “fishbone diagrams”, demonstrate cause-and-effect analysis using the diagrams.

System Improvement Objectives Objective – a measure of success. It is something that you expect to achieve, if given sufficient resources. Reduce the number of uncollectible customer accounts by 50 percent within the next year. Increase by 25 percent the number of loan applications that can be processed during an eight-hour shift. Decrease by 50 percent the time required to reschedule a production lot when a workstation malfunctions. Constraint – something that will limit your flexibility in defining a solution to your objectives. Essentially, constraints cannot be changed. The new system must be operational by April 15. The new system cannot cost more than $350,000. The new system must be web-enabled. The new system must bill customers every 15 days. Teaching Notes The criteria for success of an information system should be measured in terms of objectives. Formulate objectives as an in-class exercise.

Sample Cause-and-Effect Analysis No additional notes

System Improvement Report Insert Figure 5-13 Teaching Notes The focus is on system user perspectives. Requirements can be expressed in narrative, model, and prototype forms, or any combination thereof.

Context of Requirements Analysis Teaching Notes The focus is on system user perspectives. Requirements can be expressed in narrative, model, and prototype forms, or any combination thereof.

Tasks for Requirements Analysis Teaching Notes Some of the tasks are completed in parallel.

Functional vs. Nonfunctional Requirements Functional requirement – a description of activities and services a system must provide. inputs, outputs, processes, stored data Nonfunctional requirement – a description of other features, characteristics, and constraints that define a satisfactory system. Performance, ease of learning and use, budgets, deadlines, documentation, security, internal auditing controls Teaching Notes It is not that functional requirements are mandatory and nonfunctional requirements are optional. The list of example nonfunctional requirements includes mandatory items. The difference is that functional requirements describe functions that the system must perform. Nonfunctional requirements are not functions to be done but qualities that the system must have if it is to be successful.

Expressing System Requirements Draft Functional and Nonfunctional Requirements Could use simple list of system improvement objectives Increasingly systems analysts express functional requirements using Use Cases Use case – a business scenario or event for which the system must provide a defined response. Use cases evolved out of object-oriented analysis; however, their use has become common in many other methodologies for systems analysis and design. Conversion Notes The 6th edition is emphasizing Use Cases throughout the text as a common systems analysis tool, not just an OOA tool.

Prioritize System Requirements Prioritization of requirements can be facilitated using timeboxing. Timeboxing – a technique that delivers information systems functionality and requirements through versioning. The development team selects the smallest subset of the system that, if fully implemented, will return immediate value to the systems owners and users. That subset is developed, ideally with a time frame of six to nine months or less. Subsequently, value-added versions of the system are developed in similar time frames. A mandatory requirement is one that must be fulfilled by the minimal system, version 1.0 A desirable requirement is one that is not absolutely essential to version 1.0. It may be essential to the vision of a future version. No additional notes

Context of Logical Design Phase Teaching Notes The focus is on system user perspectives.

Tasks for Logical Design Phase No additional notes.

Context of Decision Analysis Phase Teaching Notes The focus is on system user and system designer perspectives. Notice the transition to technical concerns leading to a system proposal that includes data, process, and interface elements.

Tasks for Decision Analysis Phase No additional notes.

Feasibility Technical feasibility – Is the solution technically practical? Does our staff have the technical expertise to design and build this solution? Operational feasibility – Will the solution fulfill the users’ requirements? To what degree? How will the solution change the users’ work environment? How do users feel about such a solution? Economic feasibility – Is the solution cost-effective? Schedule feasibility – Can the solution be designed and implemented within an acceptable time period? No additional notes

Candidate Systems Matrix No additional notes (Continued)

Candidate Systems Matrix No additional notes

Feasibility Matrix No additional notes

Outline for a Typical System Proposal Introduction Purpose of the report Background of the project leading to this report Scope of the report Structure of the report Tools and techniques used Solution generated Feasibility analysis (cost-benefit) Information systems requirements Alternative solutions and feasibility analysis Recommendations Appendices No additional notes.

Systems Analysis and Design 7th Edition Chapter 10 Systems Implementation 28

Phase Description Systems Implementation is the fourth of five phases in the systems development life cycle Includes application development, documentation, testing, training, data conversion, and system changeover The deliverable for this phase is a completely functioning information system 29 29

Chapter Objectives Explain the importance of software quality assurance and software engineering Describe the application development process for structured, object-oriented, and agile methods Draw a structure chart showing top-down design, modular design, cohesion, and coupling 30 30

Chapter Objectives Explain the coding process Explain unit, integration, and system testing Differentiate between program, system, operations, and user documentation List the main steps in system installation and evaluation 31 31

Chapter Objectives Develop a training plan for each group of participants, compare in-house and outside training, and describe effective training techniques Describe data conversion and changeover methods Explain post-implementation evaluation and the final report to management 32 32

Introduction The system design specification serves as a blueprint for constructing the new system The initial task: application development Before a changeover can occur, the system must be tested and documented carefully, users must be trained, and existing data must be converted A formal evaluation of the results takes place as part of a final report to management 33 33

Software Quality Assurance Software Engineering: software development process that stresses solid design, accurate documentation, and careful testing. Capability Maturity Model (CMM) designed by SE Goal: to improve software quality Capability Maturity Model Integration (CMMI) Goal: Process improvement CMMI tracks an organization's processes, using five maturity layers The maturity levels: Performed Managed Defined Quantitatively managed Optimizing 34 34

Software Quality Assurance International Organization for Standardization (ISO) Many firms seek assurance that software systems will meet rigid quality standards In 1991: ISO established a set of guidelines called ISO 9000-3 ISO requires a specific development plan 35 35

Overview of Application Development The process of constructing the programs and code modules that serve as building blocks of the information system. Objective: to translate the design into program and code modules that will function properly In the previous lecture we studied the tasks involved in the creation of System Design. These tasks produced an overall design and a plan for physical implementation Methods: Structured analysis or O-O analysis 36 36

Overview of Application Development Application Development Tasks Traditional methods Start by reviewing documentation from prior SDLC phases and creating a set of program designs At this point, coding and testing tasks begin Agile Methods Intense communication and collaboration between the IT team and the users or customers Objective: to create the system through an iterative process 37 37

Application Development System Development Tools Entity-relationship diagrams Flowcharts Pseudocode Decision tables and decision trees 38 38

Overview of Application Development Project Management Even a modest-sized project might have hundreds or even thousands of modules Important to set realistic schedules, meet project deadlines, control costs, and maintain quality Should use project management tools and techniques 39 39

Structured Application Development Partitioning: Modular design breaks the system into subsystems and modules Structure Charts Control module (higher level module) Subordinate modules Module (rectangle) Data Couple (shows data passing to another module) Control Couple (shows message passing to another module) Condition (diamond) Loop (curved arrow) 40 40

Structured Application Development Cohesion and Coupling: Cohesion measures a module’s scope and processing characteristics. Single task: high degree of cohesion If you need to make a module more cohesive, you can split it into separate units, each with a single function. Coupling describes the relationship and interdependence among modules. Loosely coupled Tightly coupled 41 41

Structured Application Development Drawing a Structure Chart Step 1: Review the DFDs Review all DFDs for accuracy and completeness Step 2: Identify Modules and Relationships Transform functional primitives or object methods into program modules Three-level structure charts relate to the three DFD levels 42 42

Structured Application Development Steps in Drawing a Structure Chart Step 3: Add Couples, Loops, and Conditions Identify the data elements that pass from one module to another Step 4: Analyze the Structure Chart and the Data Dictionary Ensure that the chart reflects all previous documentation and that the logic is correct 43 43

Object-Oriented Application Development Object-oriented development (OOD) Characteristics of Object-Oriented Application Development The application's structure is represented by the object model itself 44 44

Object-Oriented Application Development Implementation of Object-Oriented Designs Main objective: to translate object methods into program code modules and determine what event or message will trigger the execution of each module Object-Oriented Cohesion and Coupling Classes – loosely coupled Methods – loosely coupled and highly cohesive 45 45

Agile Application Development Agile Application Development: a distinctly different systems development method Development team is in constant communication with the customer Focuses on small teams, intense communication, and rapid development iterations Extreme Programming (XP): one of the newest agile methods 46 46

Agile Application Development An extreme programming (XP) Example User story Release plan Iteration cycle Iteration planning meeting Parallel programming Test-driven design 47 47

Agile Application Development The Future of Agile Development Critics claim it lacks discipline and produces systems of questionable quality Before implementing agile development, the proposed system and development methods should be examined carefully A one-size-fits-all solution does not exist 48 48

Coding Coding: the process of turning program logic into specific instructions Programming Environments Integrated development environment (IDE) Microsoft’s .NET IBM’s Websphere Generating Code Some CASE Tools can generate editable program code directly from macros, keystrokes, or mouse actions 49 49

Testing the System Unit Testing: Integration Testing: System Testing: Testing of individual program or module Integration Testing: Testing two or more programs. System Testing: Testing entire system. You should regard thorough testing as a cost-effective means of providing a quality product. 50 50

Documentation Program Documentation: System Documentation: Describes the inputs, outputs, and processing logic for all program modules. Defect tracking software (bug tracking software) documents and tracks program defects, code changes, and replacement code (patches). System Documentation: Describes the system’s functions and how they’re implemented. Operations Documentation: Contains all the information needed for processing and distributing online (forms) and printed output (scheduling info). User Documentation: Consists of instructions and information to users who will interact with the system. Systems analysts usually are responsible for preparing documentation to help users learn the system 51 51

Documentation User Documentation Effective online documentation is an important productivity tool Written documentation material also is valuable 52 52

Management Approval After system testing is complete, you present the results to management. If system testing produced no technical, economical, or operational problems, management determines a schedule for system installation and evaluation. 53 53

System Installation and Evaluation Remaining steps in systems implementation: Prepare a separate operational and test environment Provide training for users, managers, and IT staff Perform data conversion and system changeover Carry out post-implementation evaluation of the system Present a final report to management 54 54

Operational and Test Environments Operational environment: The environment for the actual system operation Test environment: The environment that analysts use to develop and maintain programs 55 55

Operational and Test Environments The operational environment includes hardware and software configurations and settings, system utilities, telecommunications resources, and any other components that might affect system performance If you have to build or upgrade network resources to support the new system, you must test the platform rigorously before system installation begins 56 56

Training Training Plan Vendor-supplied Training The three main groups for training are users, managers, and IT staff You must determine how the company will provide training Vendor-supplied Training Often gives the best return on your training dollars 57 57

Training Web-based training providing an interactive experience: Webinars (online seminar), Podcasts, (web-based broadcast via multimedia) Tutorials Webcast (prerecorded webinar session) Subscribers As technology continues to advance, other wireless devices such as PDAs and cell phones will be able to receive podcasts Tutorials can be developed by software vendors, or by a company’s IT team 58 58

Training Outside Training Resources In-House Training Many training consultants, institutes, and firms are available that provide either standardized or customized training packages In-House Training The IT staff and user departments often share responsibility 59 59

Data Conversion Data Conversion Strategies The old system might be capable of exporting data in an acceptable format for the new system or in a standard format such as ASCII or ODBC (Open Database Connectivity) If a standard format is not available, you must develop a program to extract the data and convert it Often requires additional data items, which might require manual entry 60 60

Data Conversion Data Conversion Security and Controls You must ensure that all system control measures are in place and operational to protect data from unauthorized access and to help prevent erroneous input Some errors will occur It is essential that the new system be loaded with accurate, error-free data 61 61

System Changeover The process of putting the new information system online and retiring the old system 62 62

System Changeover Direct Cutover Involves more risk than other changeover methods Companies often choose the direct cutover method for implementing commercial software packages Cyclical information systems usually are converted using the direct cutover method at the beginning of a quarter, calendar year, or fiscal year 63 63

System Changeover Parallel Operation Easier to verify that the new system is working properly under parallel operation than under direct cutover Running both systems might place a burden on the operating environment and cause processing delay Is not practical if the old and new systems are incompatible technically Also is inappropriate when the two systems perform different functions 64 64

System Changeover Pilot Operation The group that uses the new system first is called the pilot site The old system continues to operate for the entire organization After the system proves successful at the pilot site, it is implemented in the rest of the organization, usually using the direct cutover method Is a combination of parallel operation and direct cutover methods 65 65

System Changeover Phased Operation You give a part of the system to all users The risk of errors or failures is limited to the implemented module only Is less expensive than full parallel operation Is not possible, however, if the system cannot be separated easily into logical modules or segments 66 66

System Changeover 67 67

Post-Implementation Tasks Post-Implementation Evaluation Assesses the overall quality of the information system A post-implementation evaluation should examine all aspects of the development effort and the end product — the developed information system You can apply the same fact-finding techniques in a post-implementation evaluation that you used to determine the system requirements during the systems analysis phase 68 68

Post-Implementation Tasks Final Report to Management Your report should include the following: Final versions of all system documentation Planned modifications and enhancements to the system that have been identified Recap of all systems development costs and schedules Comparison of actual costs and schedules to the original estimates Post-implementation evaluation, if it has been performed Marks the end of systems development work 69 69

Chapter Summary The systems implementation phase consists of application development, testing, installation, and evaluation of the new system Analysts and technical writers also prepare operations documentation and user documentation Develop a training program A post-implementation evaluation assesses and reports on the quality of the new system and the work done by the project team 70 70

Chapter Summary The final report to management includes the final system documentation, describes any future system enhancements that already have been identified, and details the project costs The report represents the end of the development effort and the beginning of the new system’s operational life 71 71