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

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

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

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

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

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

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

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

9. Tasks for Problem Analysis Phase
No additional notes

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

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

12. Sample Cause-and-Effect Analysis
No additional notes

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

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

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

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

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

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

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

20. Tasks for Logical Design Phase
No additional notes.

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

22. Tasks for Decision Analysis Phase
No additional notes.

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

24. Candidate Systems Matrix
No additional notes
(Continued)

25. Candidate Systems Matrix
No additional notes

26. Feasibility Matrix
No additional notes

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

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

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

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

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

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

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

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

35. 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
ISO requires a specific development plan 35 35

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

67. System Changeover 67 67

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

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

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

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