McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights Reserved CHAPTER 11 SYSTEMS DEVELOPMENT

11-2 Nike SCM Failure The US-based Nike Corporation announced that it had generated profits of $97.4 million, around $48 million below its earlier forecast for the third quarter ended February 28, The company said that the failure in the supply chain software installation by i2 Technologies was the cause of this revenue shortfall.

11-3 Nike SCM Failure This admission of failure also affected the company's reputation as an innovative user of technology. –The supply chain software implementation was the first part of a huge project to install an integrated ERP system from SAP, and customer relationship management (CRM) software from Siebel Systems –For over a year, Nike reeled as a result of this failure. i2 and Nike blamed each other in public, for the failure and this led to a further downslide in the share price of both the companies. –Analysts pointed to lapses in project management, too much customization and an over reliance on demand forecasting software. Nike insiders raised doubts about the Single Instance Strategy being followed by Nike. Single Instance Strategy refers to one ERP application with one data store that serves the entire company. Everything a company needs from financials, order entry, supply chain to CRM comes from a single vendor.

11-4 Nike SCM Failure However, the company remained firm and relentlessly pursued its Single Instance Strategy for SAP implementation. The guiding instruction as put across by Gordon Steele (Steele), CIO of Nike was that the "Single Instance was a decision not a discussion." By 2004, the company had successfully implemented its Nike Supply Chain (NSC) project, indicating that its centralized planning, production and delivery processes were right for the Single Instance Strategy. With this success, Nike's Single Instance Strategy became the desired approach for many companies implementing ERP software. Nike used SAP for 95% of its global business.

11-5 DEVLOPING SOFTWARE Software that is built correctly can transform as the organization and its business transforms Software that effectively meets employee needs will help an organization become more productive and enhance decision making Software that does not meet employee needs may have a damaging effect on productivity and can even cause a business to fail

11-6 DEVELOPING SOFTWARE As organizations’ reliance on software grows, so do the business-related consequences of software successes and failures including: –Increase or decrease revenue –Nike’s poorly designed SCM software delayed orders, increased excess inventories, and caused third quarter earnings to fall 24% below expectations –Repair or damage to brand reputation – H&R Block customers were furious when the company accidentally posted passwords and social security numbers to its Web site –Prevent or incur liabilities – FoxMeyer sued SAP for $500 million for an ERP failure –Increase or decrease productivity – Defective software accounts for 45% of computer downtime and cost U.S. businesses $100 billion in 2003

11-7 THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) Systems development life cycle (SDLC) – the overall process for developing information systems from planning and analysis through implementation and maintenance

11-8 THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) 1.Planning phase – involves establishing a high-level plan of the intended project and determining project goals 2.Analysis phase – involves analyzing end- user business requirements and refining project goals into defined functions and operations of the intended system Business requirement – detailed set of business requests that the system must meet in order to be successful

11-9 THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) ) 3.Design phase – involves describing the desired features and operations of the system including screen layouts, business rules, process diagrams, pseudo code, and other documentation 4.Development phase – involves taking all of the detailed design documents from the design phase and transforming them into the actual system

11-10 THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) 5.Testing phase – involves bringing all the project pieces together into a special testing environment to test for errors, bugs, and interoperability and verify that the system meets all of the business requirements defined in the analysis phase 6.Implementation phase – involves placing the system into production so users can begin to perform actual business operations with the system

11-11 THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) 7.Maintenance phase – involves performing changes, corrections, additions, and upgrades to ensure the system continues to meet the business goals

11-12 SOFTWARE DEVELOPMENT METHODOLOGIES There are a number of different software development methodologies including: –Waterfall methodology – a sequential, activity-based process in which each phase in the SDLC is performed sequentially from planning through implementation and maintenance –Rapid application development methodology (RAD) – emphasizes extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the systems development process –Extreme programming (XP) methodology – breaks a project into tiny phases, and developers cannot continue on to the next phase until the first phase is complete –Agile methodology – a form of XP, aims for customer satisfaction through early and continuous delivery of useful software components

11-13 Waterfall Methodology Waterfall methodology – a sequential, activity-based process in which each phase in the SDLC is performed sequentially from planning through implementation and maintenance

11-14 Waterfall Methodology The waterfall methodology is one of the oldest software development methods and has been around for over 30 years The success rate for software development projects that follow this approach is only about 10 percent, or 1 in 10 The biggest problem with the waterfall methodology is that it assumes users can specify all business requirements in advance –It also assumes that business requirements do not change over time If you ever find yourself on a software development project that is using the waterfall methodology, do everything possible to change the methodology

11-15 Rapid Application Development Methodology (RAD) Rapid application development methodology (RAD) – emphasizes extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the systems development process The prototype is an essential part of the analysis phase when using a RAD methodology –Prototype – a smaller-scale representation or working model of the users’ requirements or a proposed design for an information system

11-16 Rapid Application Development Methodology (RAD)

11-17 Extreme Programming Methodology Extreme programming (XP) methodology – breaks a project into tiny phases, and developers cannot continue on to the next phase until the first phase is complete –The primary difference between the waterfall and XP methodologies is that XP divides its phases into iterations with user feedback

11-18 Agile Methodology Agile methodology – a form of XP, aims for customer satisfaction through early and continuous delivery of useful software components –Agile is similar to XP but with less focus on team coding and more on limiting project scope –An agile project sets a minimum number of requirements and turns them into a deliverable product

11-19 Agile Methodology

11-20 Agile Methodology The Agile Alliance is a group of software developers whose mission is to improve software development processes and whose manifesto includes the following: –Satisfy the customer through early and continuous delivery of valuable software –Welcome changing requirements, even late in development –Business people and developers must work together daily throughout the project –Build projects around motivated individuals –The best architectures, requirements, and designs emerge from self-organizing teams –At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

11-21 DEVELOPING SUCCESSFUL SOFTWARE Primary principles for successful agile software development include: –Slash the budget – Small budgets force developers and users to focus on the essentials –If it doesn’t work, kill it – Bring all key stakeholders together to evaluate and assess the software –Keep requirements to a minimum – Start each project with what the software must absolutely do –Test and deliver frequently – As often as once a week, and not less than once a month, complete a part of the project or a piece of software –Assign non-IT executives to software projects – Non-IT executives should coordinate with the technical project manager, test iterations to make sure they are meeting user needs, and act as liaisons between executives and IT

11-22 SDLC Large, complex IT systems take teams of architects, analysts, developers, testers, and users many years to create The systems development life cycle is the foundation for many systems development methodologies such as RAD and agile –Systems development life cycle – the overall process for developing information systems from planning and analysis through implementation and maintenance

11-23 Learning From Failure Learning from failure is a hallmark of the technology business. Projects fail for a number of varied reasons. Nick Baker, a 37-year-old system architect at Microsoft, knows that well. A British transplant at the software giant's Silicon Valley campus, he went from failed project to failed project in his career. –He worked on such dogs as Apple Computer's defunct video card business, 3DO's failed game consoles, a chip startup that screwed up a deal with Nintendo, the never successful WebTV and Microsoft's canceled Ultimate TV satellite TV recorder. But Baker finally succeeded with the Xbox 360, Microsoft's video game console. –The adventure on which he embarked four years ago would ultimately prove that failure is often the best teacher. His new gig would once again provide copious evidence that flexibility and understanding of detailed customer needs will beat a rigid business model every time.

11-24 SDLC

11-25 PHASE 1: PLANNING Planning phase – involves establishing a high-level plan of the intended project and determining project goals Primary planning activities include 1.Identify and select the system for development 2.Assess project feasibility 3.Develop the project plan

11-26 Identify and Select the System for Development Organizations use different forms of evaluation criteria to determine which systems to develop –Critical success factor (CSF) – a factor that is critical to an organization’s success

11-27 Identify and Select the System for Development

11-28 Assess Project Feasibility Feasibility study – determines if the proposed solution is feasible and achievable from a financial, technical, and organizational standpoint Different types of feasibility studies –Economic feasibility study – (cost-benefit analysis) – identifies the financial benefits and costs associated with the systems development project –Operational feasibility study – examines the likelihood that the project will attain its desired objectives –Technical feasibility study – determines the organization’s ability to build and integrate the proposed system –Schedule feasibility study – assesses the likelihood that all potential time frames and completion dates will be met –Legal and contractual feasibility study – examines all potential legal and contractual ramifications of the proposed system

11-29 Develop the Project Plan Developing the project plan is a difficult and important activity The project plan is the guiding force behind on-time delivery of a complete and successful system Continuous updating of the project plan must be performed during every subsequent phase during the SDLC

11-30 PHASE 2: ANALYSIS Analysis phase – involves analyzing end- user business requirements and refining project goals into defined functions and operations of the intended system Primary analysis activities include: 1.Gather business requirements 2.Create process diagrams 3.Perform a buy vs. build analysis

11-31 Gather Business Requirements Business requirements – the detailed set of business requests that the system must meet in order to be successful –Gathering business requirements is the typically one of the hardest tasks to perform on any project and is the number one reason why projects fail “Bad Business Requirements” It takes many different people to perform organizational activities and they all have to be involved in writing the business requirements Writing detailed business requirements is difficult Business requirements continuously change

11-32 Gather Business Requirements Different ways to gather business requirements –Joint application development (JAD) session – where employees meet to define or review the business requirements for the system –Interviews –Questionnaires –Observations –Review business documents

11-33 Gather Business Requirements The system users review the requirements definition document and determine if they will sign-off on the business requirements –Requirements definition document – contains the final set of business requirements, prioritized in order of business importance –Sign-off – the system users’ actual signatures indicating they approve all of the business requirements When someone is asked to put their actual signature on something they take it much more seriously than just a verbal OK. For this reason, asking someone to sign-off helps to ensure they are actually reading the document, understanding the document, and most importantly, in agreement with the document.

11-34 Gather Business Requirements

11-35 Create Process Diagrams Process modeling – graphically representing the processes that capture, manipulate, store, and distribute information between a system and its environment Common process modeling diagrams include –Data flow diagram (DFD) – illustrates the movement of information between external entities and the processes and data stores within the system –Computer-aided software engineering (CASE) tools –automate systems analysis, design, and development

11-36 Create Process Diagrams Entities send data or requests to processes which then interact with the data stores

11-37 Perform a Buy vs. Build Analysis An organization faces two primary choices when deciding to develop an information system 1.Buy the information system from a vendor –Commercial off-the shelf (COTS) – software package or solution that is purchased to support one or more business functions and information systems –SCM, CRM, and ERP solutions are typically COTS 2.Build the information system itself

11-38 Perform a Buy vs. Build Analysis Organizations must consider the following when making a buy vs. build decision: –Are there any currently available products that fit the needs? –Are there features that are not available and important enough to warrant the expense of in- house development? –Can the organization customize or modify an existing COTS to fit its needs? –Is there a justification to purchase or develop based on the acquisition cost?

11-39 Perform a Buy vs. Build Analysis Other buy vs. build considerations: –Does the system support multi-currency and multi-language if the business expands globally? –Can the organization upgrade if it customizes its COTS application? –If the organization customizes its COTS application, will it be able to receive vendor support? –If the organization builds a system, will it be able to build all of the functionality it can find a COTS application?

11-40 Perform a Buy vs. Build Analysis Three key factors an organization should also consider when contemplating the buy vs. build decision 1.Time to market – if time to market is a priority, then purchasing a good base technology and potentially building onto it will likely yield results faster than starting from scratch 2.Availability of corporate resources – typically, the costs to an organization to buy systems such as SCM, CRM, and ERP are extremely high, in the multiple millions of dollars. This can make the entire concept economically unfeasible for some organizations that are resource constrained. Building these systems can also be extremely expensive, take indefinite amounts of time, and constrain resources. 3.Corporate core competencies – the more an organization wants to build a technical core competency, the less likely it will want to buy it

11-41 PHASE 3: DESIGN Design phase – involves describing the desired features and operations of the system including screen layouts, business rules, process diagrams, pseudo code, and other documentation Primary design activities include: 1.Design the IT infrastructure 2.Design system models Organizations need a solid IT infrastructure to support their IT systems –IT infrastructure must meet the organization’s needs in terms of time, cost, technical feasibility, and flexibility

11-42 Design the IT Infrastructure Sample IT infrastructure

11-43 Design System Models Modeling – the activity of drawing a graphical representation of a design (like the blueprint of house) Different modeling types include: –Graphical user interface (GUI) – the interface to an information system –GUI screen design – the ability to model the information system screens using icons, buttons, menus, and submenus –Data models – a formal way to express data relationships to a database management system (DBMS) –Entity relationship diagram (ERD) – a technique for documenting the relationships between entities in a database

11-44 Design System Models Sample entity relationship diagram (ERD)

11-45 PHASE 4: DEVELOPMENT Development phase – involves taking all of the detailed design documents from the design phase and transforming them into the actual system Primary development activities include: 1.Develop the IT infrastructure 2.Develop the database and programs

11-46 PHASE 4: DEVELOPMENT Development 1: Develop the IT Infrastructure –The platform upon which the system will operate must be built prior to building the actual system –In the development phase, the organization purchases and implements the required equipment to support the IT infrastructure Development 2: Develop the database and programs –Once the IT infrastructure is built, the organization can begin to create the database and write the programs required for the system –IT specialists perform the majority of the tasks associated with the development phase

11-47 PHASE 5: TESTING Testing phase – involves bringing all the project pieces together into a special testing environment to test for errors, bugs, and interoperability, in order to verify that the system meets all the business requirements defined in the analysis phase Primary testing activities include: 1.Write the test conditions 2.Perform the system testing

11-48 Write the Test Conditions Test condition – the detailed steps the system must perform along with the expected results of each step (can run into the tens of thousands of test conditions)

11-49 Perform the System Testing Different types of testing –Unit testing – tests each unit of code upon completion –Application (or system) testing – verifies that all units of code work together –Integration testing – exposes faults in the integration of software components or units –Backup and recovery testing – tests the ability of an application to be restarted after failure –Documentation testing – verifies instruction guides are helpful and accurate –User acceptance testing (UAT) – tests if a system satisfies its acceptance criteria

11-50 PHASE 6: IMPLEMENTATION Implementation phase – involves placing the system into production so users can begin to perform actual business operations with the system –Surprisingly, many projects fail during implementation –No matter how great the system is, if the users do not want the system or cannot use the system, it will fail Primary implementation activities include: 1.Write detailed user documentation 2.Determine implementation method 3.Provide training for the system users

11-51 Write Detailed User Documentation System users require user documentation that highlights how to use the system User documentation – highlights how to use the system –How often do you read product documentation or user guides? Why? –Is on-line help more useful?

11-52 Determine Implementation Method Four primary implementation methods 1.Parallel implementation – using both the old and the new system until it is evident that the new system performs correctly 2.Plunge implementation – discarding the old system completely and immediately starting to use the new system 3.Pilot implementation – having only a small group of people use the new system until it is evident that the new system performs correctly and then adding the remaining people 4.Phased implementation – implementing the new system in phases, and then implementing the remaining phases of the new system

11-53 Provide Training for the System Users Organizations must provide training for system users Two most popular types of training include: –Online training – runs over the Internet or off a CD-ROM –Workshop training – set in a classroom- type environment and led by an instructor –Any experience with either one?

11-54 PHASE 7: MAINTENANCE Maintenance phase – involves performing changes, corrections, additions, and upgrades to ensure the system continues to meet the business goals –Majority of the life of a system is spent in this phase Primary maintenance activities include: 1.Build a help desk to support the system users 2.Perform system maintenance 3.Provide an environment to support system changes

11-55 Build a Help Desk to Support the System Users Internal system users have a phone number for the help desk they call whenever they have issues or questions about the system –Help desk – a group of people who respond to internal system user questions Providing a help desk is an excellent way to provide comprehensive support for new system users –What have been your experiences with a help desk?

11-56 Perform System Maintenance Maintenance – fixing or enhancing an information system Different types of maintenance include: –Adaptive maintenance – increases system functionality –Corrective maintenance – repairs defective systems –Perfective maintenance – enhances systems –Preventative maintenance – reduces chances of system failure

11-57 Support System Changes An organization must modify its systems to support the business environment –Change occurs and an organization must plan for and support system changes –Without changes the organization could not change and grow It typically accomplishes this through change management systems and change control boards –Change management system – a collection of procedures to document a change request and define the steps necessary to consider the change based on the expected impact of the change –Change control board (CCB) – responsible for approving or rejecting all change requests

11-58 SOFTWARE PROBLEMS ARE BUSINESS PROBLEMS Primary reasons for project failure include –Unclear or missing business requirements –Skipping SDLC phases –Failure to manage project scope Scope creep – occurs when the scope increases –Add new type of discount to the marketing system Feature creep – occurs when extra features are added –new logo placed on the top corner of every screen and it should play a song when clicked –Failure to manage project plan –Changing technology

11-59 SOFTWARE PROBLEMS ARE BUSINESS PROBLEMS Find errors early: the later in the SDLC an error is found - the more expensive it is to fix

11-60 Denver International Airport The airport's computerized baggage system, which was supposed to reduce flight delays, shorten waiting times at luggage carousels, and save airlines in labor costs, turned into an unmitigated failure, and is widely given as a textbook example of a software engineering disastersoftware engineering An opening originally scheduled for October 31, 1993 with a single system for all three concourses turned into a February 28, 1995 opening with separate systems for each concourse, with varying degrees of automation.October February The system's $186 million in original construction costs grew by $1 million per day during months of modifications and repairs. Incoming flights never made use of the system, and only United, DIA's dominant airline, used it for outgoing flights. –The 40-year-old company responsible for the design of the automated system, BAE Automated Systems of Carrollton, Texas, at one time responsible for 90% of the baggage systems in the U.S., was acquired in 2002 by G&T Conveyor Company, Inc.Carrollton, TexasG&T Conveyor Company, Inc. The automated baggage system never worked well, and in August 2005, it became public knowledge that United would abandon the system, a decision that would save them $1 million in monthly maintenance costs.