Ralph M. Stair George W. Reynolds Chapter 8 Systems Development
An Overview of Systems Development Managers and employees in all functional areas work together and use business information systems Corporations and nonprofit organizations use the systems development process to build information systems to achieve their goals 2
Participants in Systems Development The development team: Consists of stakeholders, users, managers, systems development specialists, and various support personnel Determines information system s objectives Delivers a system that meets objectives 3
Participants in Systems Development: the Development Team Project manager: the person assigned by the organization to do the work of the project and achieve the project objectives Stakeholders: people who ultimately will be affected (for better or worse) by the systems development project Users: people who will regularly interact with the system 4
Participants in Systems Development: the Development Team (cont d.) Systems analysts: specializes in analyzing and designing business systems Programmer: responsible for modifying or developing programs to satisfy user requirements 5
Role of the Project Manager 6
Systems Development: Others Directly Involved Steering team A small group of senior managers representing the business and IS organizations that provide guidance and support to the project Project sponsor A key member and leader of the steering team who plays such a critical role that lack of this essential individual raises the distinct probability of project failure 7
Information Systems Planning Identifies those information systems development initiatives needed to support organizational strategic goals Systems development projects are initiated to meet organizational goals outlined in the strategic plan 8
Information Systems Planning (cont d.) 9
Initiating Systems Development Systems development initiatives: Arise from all levels of an organization Can be planned or unplanned Can take advantage of new technologies Mergers and acquisitions can trigger many systems development projects 10
Traditional Systems Development Life Cycle Also called a systems development life cycle (SDLC) A sequential multistage process where work on the next stage cannot begin until the results of the previous stage are reviewed and approved or modified as necessary 11
Traditional Systems Development Life Cycle (cont d.) 12
Table 8.1 Advantages and Disadvantages of Traditional SDLC Advantages Formal review at the end of each phase allows maximum management control. This approach requires creation of considerable system documentation. Formal documentation ensures that system requirements can be traced back to stated business needs. Approach produces many intermediate products that can be reviewed to see whether they meet the users needs and conform to standards. Disadvantages Users get a system that meets the needs as understood by the developers; this might not be what the users really needed. Documentation is expensive and time consuming to create. It is also difficult to keep current. Often, user needs go unstated or are miscommunicated or misunderstood. Users can t easily review intermediate products and evaluate whether a particular product (e.g., a dataflow diagram) meets their business requirements. 13
SDLC: Systems Investigation The purpose of this phase of systems development is to gain a clear understanding of the specifics of the problem to be solved or the opportunity to be addressed Feasibility analysis: assessment of the technical, economic, legal, operational, and schedule feasibility of a project
SDLC: Systems Analysis This phase of systems development involves: Gathering data on the existing system Determining the requirements for the new system Considering alternatives within identified constraints Investigating the feasibility of alternative solutions
SDLC: Systems Design The stage of systems development that creates a complete set of technical specifications that can be used to construct the information system
SDLC: System Construction The phase of systems development that converts the system design into an operational system by: Acquiring and installing hardware and software Coding and testing software programs Creating and loading data into databases Performing initial program testing
SDLC: Integration Testing Also called integration and testing (I & T) Testing that involves linking all of the individual components together and testing them as a group to uncover any defects between individual components
Table 8.2 Tests Conducted on an Information System Form of Test What Is Tested Purpose of Test Who Does It User Acceptance Volume Test the complete, integrated system (hardware, software, databases, people, and procedures). Evaluate the performance of the information system under realistic and varying work volume and operating conditions. Verify the information system can complete required tasks in a real-world operating environment and do this according to the system design specifications. Determine the work load at which systems performance begins to degrade and identify and eliminate any issues that prevent the system from reaching its required service- level performance. Trained users of the system System development team and members of the operations organization 19
Table 8.2 Tests Conducted on an Information System (cont d.) Form of Test What Is Tested Purpose of Test Who Does It System Test the complete, integrated system (hardware, software, databases, people, and procedures). Validate that the information system meets all specified requirements. Independent test team separate from the software development team Integration Unit Test all of the individual units of the information system linked together. Test individual units of the system. Uncover any defects between individual components of the information system. Verify that each unit performs as designed. Software developers or independent software testers using black box testing measures Software developers 20
SDLC: Systems Implementation Successfully introducing an information system into an organization The major challenges to successful implementation of an information system are often more behavioral than technical Strong, effective leadership is required to overcome the behavioral resistance
SDLC: Systems Operation and Maintenance Systems operation: using a new or modified system under all kinds of operating conditions Systems maintenance: changing and enhancing the system to make it more useful in achieving user and organizational goals
SDLC: System Disposal Those activities that ensure the orderly dissolution of the system Activities include: Closing out any contracts in place Disposing of all equipment in an environmentally friendly manner Safely migrating information from the system to another system or archiving information in accord with records management policies
Useful Software Development Techniques Joint Application Development (JAD) Functional decomposition Data flow diagrams Request for proposal
Joint Application Development (JAD) A structured meeting process that can accelerate and improve the efficiency and effectiveness of the investigation, analysis, and design phases of a systems development project The success or failure of a JAD session depends on how well the JAD facilitator plans and manages the session
Table 8.3 JAD Participants and Their Role Role Responsibilities Qualifications Facilitator Determines JAD session objectives Plans JAD session to meet objectives Leads JAD session Encourages everyone to participate Excellent meeting facilitator Unbiased and does not take sides Decision makers Users Resolve conflicts Avoid gridlock Describe business as it is and as it should be Provide business expertise Define problems, identify potential benefits, analyze existing system, define requirements of a new system, and propose and evaluate possible solutions Stakeholders selected by project sponsor to make decisions Have the authority and willingness to make decisions Represent all major areas affected Expert in their area of the business 26
Table 8.3 JAD Participants and Their Role (cont d.) Role Responsibilities Qualifications System developers Observe carefully Offer technical opinion on cost or feasibility, if requested Gain deep understanding of customers Member of system development team Scribe needs and desires Participate in discussion to clarify points and capture them accurately Document key points, issues, next steps, and decisions throughout the JAD session Publish results of JAD session and solicit feedback Excellent listening skills Experience in using software engineering tools to document requirements and create system models 27
Functional Decomposition A technique used primarily during the investigation phase to define the business processes included within the scope of the system Create a functional decomposition chart Begin with the name of a system Identify the highest-level processes and assign a verb-subject name to each process Break down to three to four subprocess levels 28
Functional Decomposition Chart 29
Data Flow Diagram (DFD) A diagram used during both the analysis and design phases to document the processes of the current system or to provide a model of a proposed new system Includes four primary symbols: Data-flow line, process symbol, entity symbol, and data store
Data Flow Diagram 31
Relative Cost of Custom Software 32
Table 8.4 Comparison of Off-the-Shelf and Developed Software Factor Develop (Make) Off-the-Shelf (Buy) Cost Needs Process improvement Quality The cost to build the system can be difficult to estimate accurately and is frequently higher than off-the-shelf Custom software is more likely to satisfy your needs Tend to automate existing business processes even if they are poor Quality can vary depending on the development team The true cost to implement an off-the-shelf solution is also difficult to estimate accurately but is likely to be less than a custom software solution Might not get exactly what you need Adoption of a package may simplify or streamline a poor existing business process Can assess the quality before buying Speed Can take years to develop Can acquire it now Staffing and support Competitive advantage Requires in-house skilled resources to build and support a custom-built solution Can develop a competitive advantage with good software Requires paying the vendor for support Other organizations can have the same software and same advantage 33
Request for Proposal A formal document that outlines an organization s hardware or software needs and requests vendors to develop a detailed proposal of how they would meet those needs and at what cost
Recommended Table of Contents for a Request for Proposal 35
Alternate Systems Development Life Cycles and Approaches Alternate approaches include: Prototyping Agile Object-oriented Mobile End-user development 36
Prototyping Software prototype: a working model of a system developed to enable users to interact with it and provide feedback so developers can better understand what is needed Prototyping is an iterative software development approach 37
Prototyping: an Iterative Approach to Systems Development 38
Table 8.5 Advantages and Disadvantages of Prototyping Advantages Users can try the system and provide constructive feedback during development. A throw-away prototype can be produced in days. As solutions emerge, users become more positive about the process and the results. Prototyping enables early detection of errors and omissions. Disadvantages Each iteration builds on the previous one. The final solution might be only incrementally better than the initial solution. Formal end-of-phase reviews might not occur. Thus, it is very difficult to contain the scope of the prototype, and the project never seems to end. System documentation is often absent or incomplete because the primary focus is on development of the prototype. System backup and recovery, performance, and security issues can be overlooked in the haste to develop a prototype. 39
Prototyping (cont d.) A throw-away prototype: one that is used to help define the software A working prototype: evolves into the final software solution The Rational Unified Process (RUP): an iterative systems development approach developed by IBM RUP stresses quality as the software is changed and updated over time 40
Agile Development An iterative system development process that develops the system in sprint increments lasting from two weeks to two months Concentrates on maximizing the team s ability to deliver quickly and respond to emerging requirements 41
Agile Development (cont d.) Scrum: a method to keep the agile system development effort focused and moving quickly The scrum master coordinates all activities Extreme programming (XP) promotes incremental development of a system using short development cycles to: Improve productivity Accommodate new customer requirements 42
Agile System Development Life Cycle 43
Table 8.6 Advantages and Disadvantages of Agile Development Advantages For appropriate projects, this approach puts an application into production sooner than any other approach. Documentation is produced as a by-product of completing project tasks. Agile forces teamwork and lots of interaction between users and stakeholders. Disadvantages This intense SDLC can burn out systems developers and other project participants. This approach requires systems analysts and users to be skilled in agile systems development tools and agile techniques. Agile requires a larger percentage of stakeholders and users time than other approaches. 44
Table 8.7 Comparison of System Development Life Cycles Characteristic Description Basic assumption System Development Life Cycle Agile Prototype Traditional An iterative process that develops the system in sprint increments lasting 2 8 weeks; each increment focuses on implementing the highest priority requirements that can be completed in the allotted time System requirements cannot be fully defined at start of project An iterative process that constructs prototypes or uses application frameworks System requirements cannot be fully defined at start of project A sequential multistage process where work on the next stage cannot begin until the results of the previous stage are reviewed and approved or modified as necessary All critical system requirements can be fully defined at start of project How requirements and design are defined Users interacting with systems analysts and working software Users interacting with systems analysts and prototypes Users interacting with systems analysts and system documentation and/or models Associated processes Scrum Rapid application development Structured systems analysis and design 45
Object-Oriented Systems Development Frequently used in the investigation, analysis, and design phases of system development Systems analysis: examine problems or potential opportunities Design phase: used to design key objects and classes of objects in the new or updated system; also need to consider sequence of events 46
Use Case Diagram for a Kayak Rental Application 47
Generalization/Specialization Hierarchy Diagram 48
Sequence Diagram 49
Mobile Application Development How system development differs from development of traditional systems User interface is a touch user interface Development teams are smaller more flexible and agile The application must communicate with the Internet or corporate computers A method of handling phone calls while running an application needs to be resolved 50
Table 8.8 Application Development Tools for Mobile Environment Tool Alpha Anywhere App Press ibuildapp Mobile Chrome Development Kit Salesforce1 ViziApps Target Environment ios, Android, Windows Phone iphone, ipad, Android iphone, ipad, Android ios, Android, Chrome ios, Android ios, Android 51
User Systems Development End-user systems development The creation, modification, or extension of software by people who are nonprofessional software developers Most common example: creating spreadsheets Must be subjected to the same reliability, performance, and quality issues as software developed by professionals 52
Tips to Avoid Project Major reasons projects fail Failure of executives to provide leadership and direction Unclear project scope Poorly managed expectations Insufficient user involvement An organization s unpreparedness for change Poor planning 53
Project Failure 54
Table 8.9 Factors in Project Failure Factors Potential Reason(s) Countermeasures Business executives fail to provide leadership and direction to project team Project is not aligned with business strategy or addresses the wrong problem or opportunity. Correct business sponsor is not identified or recruited to provide leadership. System investigation team must work hard to ensure that the problem or opportunity is aligned with business strategy and worth working on. Project manager must insist that project steering team be appointed including the correct business sponsor. Scope of the project is unclear The root cause of the problem to be solved or opportunity to be addressed has not been well defined. System investigation team must work with stakeholders to correctly define scope of the project using techniques such as functional decomposition. Narrow the project focus to address only the most important business opportunities. 55
Table 8.9 Factors in Project Failure (cont d.) Factors Potential Reason(s) Countermeasures Expectations are poorly managed Insufficient user involvement Organization not prepared for change Poor planning Project manager incorrectly assumes that the initial statement of stakeholder and end-user expectations is complete and unchanging. Users are busy and do not see value in their participation. Project team focuses on technical aspects of project. Project team is unable to define schedule for complex project. Project manager must meet with stakeholders and end users on a regular basis to discuss expectations, document project success criteria, and share project results and status. Key users should be part of the project team and have an ongoing role in ensuring that their needs and the needs of the business are met. Use prototyping. Project steering team should assist in preparing organization to accept change. Use project management tools to determine and document who needs to do what and when. 56