1. http://www.csun.edu/~dn58412/IS531/IS531_SP15.html Lecture 2 Systems Development Process

2. Learning Objectives 1.Systems Development Life Cycle vs. Systems Development Process 2.Zachman Framework and Stakehoders’ Perspectives in Systems Development 3.Classic Phases in Systems Development Process IS 531 : Lecture 22

3. Systems Development Life Cycle (SDLC) Systems Development Life Cycle (SDLC) :the factoring of the lifetime of an information system into two stages, (1) systems development and (2) systems operation and maintenance. Systems Development Process :a standardized methodology defines a set of activities, methods, best practices, deliverables, and tools for system developers and project managers to develop and continuously improve information systems and software. IS 531 : Lecture 23

4. Systems development life cycle (SDLC) – The overall process for developing information systems from planning and analysis through implementation and maintenance IS 531 : Lecture 24 Systems Development Life Cycle (SDLC)

5. IS 531 : Lecture 25 Systems Development Life Cycle (SDLC)

6. Where Do Systems Development Projects Come From? Problem – an actual undesirable situation that prevents the organization from fully achieving its purpose, goals, and/or objectives. Opportunity – a chance to improve the organization even in the absence of an identified problem (using PIECES framework). Directive - a new requirement that is imposed by management, government, or some external influence/parties. IS 531 : Lecture 26

7. PIECES Framework for Systems Improvement P the need to improve performance I the need to improve information (and data) E the need to improve economics, control costs, or increase profits C the need to improve control or security E the need to improve efficiency of people and processes S the need to improve service to customers, suppliers, partners, employees, etc. IS 531 : Lecture 27

8. Where Do Systems Development Projects Come From? Planned Projects – An information systems strategy plan has examined the business as a whole to identify those system development projects that will return the greatest strategic (long-term) value to the business – A business process redesign has thoroughly analyzed a series of business processes to eliminate redundancy and bureaucracy and to improve efficiency and value added. Now it is time to design/redesign the supporting information system for those redesigned business processes. IS 531 : Lecture 28

9. Where Do Systems Development Projects Come From? Unplanned projects – Triggered by a specific problem, opportunity, or directive that occurs in the course of doing business. – Steering committee – an administrative body of system owners and information technology executives that prioritizes and approves candidate system development projects. – Backlog – a repository of project proposals that cannot be funded or staffed because they are a lower priority than those that have been approved for system development. IS 531 : Lecture 29

10. Problem-Solving What “problems” to solve: (Project Definition) – True problem situations, either real or anticipated, that require corrective action – Opportunities to improve a situation despite the absence of complaints – Directives to change a situation regardless of whether anyone has complained about the current situation IS 531 : Lecture 210

11. Problem-Solving … Why: (Project Justification) – Effective: Do right thing – Efficient: Do thing right – Competitive: Do thing differently IS 531 : Lecture 211

12. Zachman Framework IS 531 : Lecture 212

13. Perspectives on an Information System IS 531 : Lecture 213

14. System Stakeholders System owners System users System analysts System designer System builder IS 531 : Lecture 214

15. System Owners System owners – an information system’s sponsors and executives advocate, usually responsible for funding the project of developing, operating, and maintaining the information system. They define the SCOPE of a system: what business problem to be solved – They view the system in term of cost/benefit to solve a business problem IS 531 : Lecture 215

16. System Users System Users System users – use or are affected by an information system on a regular basis – capturing, validating, entering, responding to, storing, and exchanging data and information. They define the REQUIREMENTS of the system. – Internal users – External users IS 531 : Lecture 216

17. System designers translate system users’ business requirements and constraints into technical solution: computer databases, inputs, outputs, networks, and software meeting the system users’ requirements. Their activities relate to the DESIGN of a system System Designers IS 531 : Lecture 217

18. System builders constructs information systems based on the design specifications from the system designers. Their activities relate to building the COMPONENTS of the system. System Builders IS 531 : Lecture 218

19. Systems Analysts Systems analysts study the problems and needs of an organization to determine how people, data, processes, and information technology can best accomplish improvements for the business. They are FACILITATORS of the system development project. A programmer-analyst A business analyst / consultant IS 531 : Lecture 219

20. HIS Professional Involvement in Systems Development User Analyst Purchaser Implementer Consultant Internal Auditor External Auditor IS 531 : Lecture 220

21. Focuses for Information Systems KNOWLEDGE (Data) — the raw material used to create useful information. PROCESSES — the activities (including management) that carry out the mission of the business. COMMUNICATION (Interfaces) — how the system interfaces with its users and other information systems. IS 531 : Lecture 221

22. KNOWLEDGE Focus System owners’ view – Interested not in raw data but in information that adds new business knowledge and information that help managers make intelligent decisions. – Data entities and business rules. IS 531 : Lecture 222

23. KNOWLEDGE Focus... System users’ view – Something recorded on forms, stored in file cabinets, recorded in books and binders, organized into spreadsheets, or stored in computer files and databases. – Focus on the business issues as they pertain to the data. – Data requirement – a representation of users’ data in terms of entities, attributes, relationships, and rules independent of data technology. IS 531 : Lecture 223

24. KNOWLEDGE Focus... System designers’ view – Data structures, database schemas, fields, indexes, and constraints of particular database management system (DBMS). System builders’ view – Coding – DBMS or other data technologies IS 531 : Lecture 224

25. PROCESS Focus System owners’ view – concerned with high-level process – Business function – a group of related processes that support the business. Functions can be decomposed into other sub-functions, activities, tasks. – A cross-functional information system – a system that supports relevant business processes from several functions within organizational boundaries. IS 531 : Lecture 225

26. PROCESS Focus... System users’ view – concerned with work that must be performed to provide the appropriate responses to business events. – Business processes – activities that respond to business events. – Process requirements – a user’s expectation of the processing requirements for a business process and its information systems. – Policy – a set of rules that govern a business process. – Procedure – a step-by-step set of instructions and logic for accomplishing a business process. – Work flow – the flow of transactions through business processes to ensure appropriate checks and approvals are implemented. IS 531 : Lecture 226

27. System designers’ view – Concerned with which processes to automate and how to automate them – Constrained by limitations of application development technologies being used – Software specifications – the technical design of business processes to be automated or supported by computer programs (off-shelf, in- house) to be written by system builders. PROCESS Focus... IS 531 : Lecture 227

28. System builders’ view – Concerned with programming logic that implements automated processes – Application program – a language-based, machine-readable representation of what a software process is supposed to do, or how a software process is supposed to accomplish its task. – Prototyping – a technique for quickly building a functioning, but incomplete model of the information system using rapid application development tools. PROCESS Focus... IS 531 : Lecture 228

29. COMMUNICATION Focus System owners’ view – Concerned with communications scope of an information system. Who (which business units, employees, customers, and partners) must interact with the system? Where are these business units, employees, customers, and partners located? What other information systems will the system have to interface with? System users’ view – Concerned with the information system’s inputs and outputs (Interface Requirements). IS 531 : Lecture 229

30. System designers’ view – Concerned with the technical design of both the user and the system-to-system communication interfaces. – Interface specifications – technical designs that document how system users are to interact with a system and how a system interacts with other systems. – User dialogue – a specification of how the user moves from window to window or page to page, interacting with the application programs to perform useful work. COMMUNICATION Focus... IS 531 : Lecture 230

31. System builders’ view – Concerned with the construction, installation, testing and implementation of user and system- to-system interface solutions. – Middleware – utility software that allows application software and systems software that utilize differing technologies to interoperate. COMMUNICATION Focus... IS 531 : Lecture 231

32. Systems Development Objectives To ensure the information system satisfies an organization’s informational and operational needs (product-oriented objective). To develop/acquire an information system in an efficient and effective manner (process- oriented objective). IS 531 : Lecture 232

33. Characteristics of a Systems Development Methodology Divide project into identifiable processes, each having a starting and ending point. Produce deliverables to monitor process. Require signoffs. Test system before implementation. Conduct training. Use program change controls. Conduct post-implementation review. IS 531 : Lecture 233

34. Classic Systems Development Process IS 531 : Lecture 234

35. Systems Development Process Phases Systems Development Process Phases Scope Definition Phase Problem Analysis Phase Requirement Analysis Phase Logical Design Decision Analysis Phase Design Phase Construction Phase Implementation Phase IS 531 : Lecture 235

36. 1. Scope Definition Purpose: define perceived problems, opportunities, and directives ; assess the risk of project; establish scope, preliminary requirements and constraints, participants, budget and schedule (preliminary study) Issues: Is the project worthwhile? (using PIECES framework) Define the scope of project Deliverable: Project charter/plan Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification IS 531 : Lecture 236

37. 2. Problem Analysis Purpose: to study and analyze the existing system from the users’ perspectives as they see Data, Processes, and Interfaces Issue: Cost/benefits of building new system to solve these problems Deliverable: system improvement objectives (business criteria to evaluate the new system) Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification IS 531 : Lecture 237

38. 3. Requirement Analysis Purpose: discover users’ needs or expectations out of the new system in terms of Data, Processes, and Interfaces Issue: Specify requirements for the new system (WHAT TO BE DONE) without prematurely expressing technical details (HOW) Errors and omissions in requirement analysis result in user dissatisfaction of final system and costly modifications Deliverable: business requirements statement IS 531 : Lecture 238

39. 4. Logical Design Purpose: translating business user requirements into a system model that depicts only WHAT TO DO without specifying any possible technical design or implementation of those requirements (conceptual design). Issue: using graphical model of a system to represent user requirements in terms of Data, Processes and Interfaces, and to facilitate improved communication between system stakeholders. IS 531 : Lecture 239

40. 5. Decision Analysis Purpose: identify all candidate solutions, analyze the feasibility of each candidate, recommend a candidate system as the target solution Issue: Feasibility analysis in terms of technical, operational, economic, schedule (TOES), and risk Deliverable: approved system proposal Feasibility check: Cancel project / Approve system proposal with budget and schedule modification / Reduce the scope of proposed solution with budget and schedule modification IS 531 : Lecture 240

41. 6. Physical Design Purpose: to transform business requirements into technical design specifications for construction Issue: HOW technology will be used to build the system in terms of Data, Processes, and Interfaces Design by Specifications vs. Design by Prototyping Deliverable: System design specifications (blueprints) Feasibility check: Continue/ Reduce or expanse the scope with budget and schedule modification IS 531 : Lecture 241

42. 7. Construction Phase Purpose: to build and test a system that fulfill business requirements and design specs; implement interfaces between new and existing systems Issue: Construct database, application programs, user/system interfaces, implement purchased or leased software Deliverable: proposed system within budget and schedule IS 531 : Lecture 242

43. 8. Implementation Phase Purpose: deliver the production system into operation Issue: Train users, write manuals, load files, populate database, final test Conversion plan: parallel systems, switch point Deliverable: system up and running IS 531 : Lecture 243

44. Operation and Support Ongoing system support would be provided until the system becomes obsolete and is replaced by a new one Issues: technical support for user, fixing bugs, recovering plan, adapt to emerging requirements When a system has reached entropy, new project for new system should be initiated IS 531 : Lecture 244

45. Summary: Systems Development Process Scope Definition Phase: What Business Problem Problem Analysis Phase: What System Issues (Info/Data, Processes, Communications/Interfaces) Requirement Analysis Phase: What User Needs Logical Design: Conceptual Model – What to Do Decision Analysis Phase: What Solution Design Phase: (Physical Model) - How IT Can Do Construction Phase: Do It Implementation Phase: Use It IS 531 : Lecture 245

46. IS 531 : Lecture 246 Systems Development as Problem Solving

47. Feasibility Analysis Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise. Operational feasibility is a measure of how well the solution will work in the organization. It is also a measure of how people feel about the system/project. Economic feasibility is a measure of the cost- effectiveness of a project or solution. Schedule feasibility is a measure of how reasonable the project timetable is. Risk feasibility – What is the probability of a successful implementation using the technology and approach? (Risk Management) IS 531 : Lecture 247

48. Costs and Benefits Direct costs (benefits): directly attributable to the system or the system change. – Direct costs include equipment purchased, personnel salaries, site preparation, and materials and supplies. – Direct benefits include items such as reduced personnel and hardware costs, and improved data reliability. IS 531 : Lecture 248

49. Costs and Benefits... Indirect costs (benefits): not directly attributable to the system or the system change. – Indirect costs are those associate with overhead expenses, such as personnel fringe benefits and utilities. – Indirect benefits are most difficult to quantify. Ex: an indirect benefit is increased revenue resulting from improved customer support IS 531 : Lecture 249

50. Costs and Benefits... Tangible costs (benefits): can be reasonably quantified. – Costs include software purchases and insurance – Benefits include reduced equipment costs and increased revenue. Intangible cost (benefit): cannot be reasonably quantified. – Costs include productivity loss caused by low employee morale. – Benefits may accrue from improved information. IS 531 : Lecture 250

51. Costs and Benefits... Nonrecurring costs, such as those for systems development, are incurred only once to get the system operational (development costs). Recurring costs, such as those for equipment rental, occur throughout all or most of the system’s life (operational costs). IS 531 : Lecture 251

52. Economic Feasibility Payback Analysis – Payback analysis is to determine if and when an investment will pay for itself. – Payback period is the period of time that will lapse before accrued benefits overtake accrued and continuing costs. Net Present Value – a dollar today is worth more than a dollar one year from now – Discount rate : a percentage that the business earns on investing money in other projects or investments: opportunity cost IS 531 : Lecture 252

53. Economic Feasibility … Return-on-Investment (ROI) Analysis – Lifetime ROI =(estimated lifetime benefits – estimated lifetime costs) / estimated lifetime costs – Annual ROI = lifetime ROI / lifetime of the system IS 531 : Lecture 253

54. Scheduling Strategies Forward Scheduling – a project scheduling approach that establishes a project start date and then schedules forward from that date. Reverse Scheduling – a project scheduling strategy that establishes a project deadline and then schedules backward from that date. IS 531 : Lecture 254

55. PERT Chart 5-3-20015-12-2001 5-3-20015-11-2001 Preliminary Investigation 5-12-20016-12-2001 5-12-20016-14-2001 Problem Analysis 5-28-20017-15-2001 5-30-20017-18-2001 Requirements Analysis 6-13-20017-30-2001 6-13-20018-3-2001 Decision Analysis 9-10-200112-14-2001 TBD Implementation 7-19-200111-13-2001 7-20-2001In Progress Construction 7-3-20019-25-2001 7-5-200110-9-2001 Design 5-3-2001N/A 5-3-2001N/A Project Initiation Scheduled Start Scheduled Finish Actual Start Actual Finish Task Scheduled Start Scheduled Finish Actual Start Actual Finish Task intertask dependency Legend IS 531 : Lecture 255

56. Critical Path IS 531 : Lecture 256

57. Gantt Chart Incomplete Task Complete Task Legend ID 1 2 3 4 5 6 7 Preliminary investigation Problem analysis Requirements analysis Decision analysis Design Construction Implementation MayJunJulAugSepOctNovDec 2001 Task Name Today IS 531 : Lecture 257

58. In-Sourcing Vs. Outsourcing In-sourcing (Build) –Uses professional expertise within an organization to develop and maintain its information technology systems Outsourcing (Buy) – Obtains services from a software developer IS 531 : Lecture 258

59. Design the Application Architecture – Defines technologies to be used and used to build Design the System Databases – Database schema Design the System Interface – User Interfaces: Input, output, and dialogue specifications Package Design Specifications – Specifications for programmers Tasks for “Build” Option IS 531 : Lecture 259

60. Tasks for “Buy” Option Research Technical Criteria and Options Solicit Proposals/Quotes from Vendors Validate Vendor Claims and Performances Evaluate and Rank Vendor Proposals: Gap Analysis on the differences between proposed and desired features. Also Cost/Benefit Analysis. Contract “Winning” Vendor and Debrief “Losing” Vendors IS 531 : Lecture 260

61. Systems Acceptance Test Systems Acceptance Test – a test performed on the final system wherein users conduct a verification, validation, and audit test. – Uses real data over an extended time period – Extensive test that addresses: verification testing, validation testing, and audit testing. Verification Testing runs the system in a simulated environment using simulated data. – Checks for errors and omissions regarding end-use and design specifications IS 531 : Lecture 261

62. Systems Acceptance Test … Validation testing runs the system in a live environment using real data. – Testing: Systems performance (throughput and response time) Peak workload performance Human engineering Methods and procedures Backup and recovery Audit testing certifies that the system is free of errors and is ready to be placed into operation. IS 531 : Lecture 262

63. Conduct System Test Prepare Conversion Plan Install Databases Train Users Convert to New System Tasks in Implementation Phase IS 531 : Lecture 263

64. System Conversion IS 531 : Lecture 264

65. Installation/Conversion Approaches RiskRisk Cost Abrupt Cutover Location Conversion Staged Conversion Parallel Conversion IS 531 : Lecture 265

66. Post-Implementation Review Post-implementation review: examination of a working information system, conducted soon after that system’s implementation, to determine if: – user’s requirements have been satisfied – development effort was efficient and conducted in accordance with the organization’s systems development standards. IS 531 : Lecture 266

67. Post Implementation Review… Determine if the user is satisfied with the new system. Identify how well the system’s achieved performance corresponds to the performance requirements, recommending improvements if necessary. Evaluate the quality of the new system’s documentation, training programs, and data conversions. IS 531 : Lecture 267

68. Post Implementation Review… Ascertain that the organization’s project management framework and SDLC were followed during development. Recommend improvements to the systems development/acquisition standards manual if necessary. Improve the cost/effectiveness analysis process by reviewing cost projections and benefit estimations and determining the degree to which these were achieved. IS 531 : Lecture 268

69. System Support Activities Program Maintenance corrects “bugs” or errors that slipped through the system development process. System Recovery is the restoration of the system and data after a system failure. Technical Support is any assistance provided to users in response to inexperience or unanticipated situations. System Enhancement is the improvement of the system to handle new business problems, new technical problems, or new technology requirements. IS 531 : Lecture 2 69

70. System Maintenance Objectives To make predictable changes to existing programs to correct errors. To preserve those aspects of the programs that were correct, and to avoid “ripple effects” of changes that may adversely affect the correctly functioning aspects. To avoid, as much as possible, the degradation of system performance. To complete the task as quickly as possible without sacrificing quality and reliability of the system. IS 531 : Lecture 270

71. System Obsolescence All systems degrade over time (entropy) At some point, not cost-effective to support and maintain Leads to a new systems development project New cycle of SDLC IS 531 : Lecture 271

72. Typical Contents of a Systems Proposal IS 531 : Lecture 272

73. The resulting information system is acceptable to the user. The system was delivered “on time.” The system was delivered “within budget.” The system development process had a minimal impact on ongoing organizational operations. Measures of Project Success IS 531 : Lecture 273