Systems Development

Systems Development MIS 503Management Information Systems MBA Program

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY Systems development life cycle (SDLC) – a highly structured approach for development of new customized software applications Page 385

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY The SDLC Project Team • Usually temporary • Includes personnel from IS and business units • Has a project manager • Traditionally from IS • Can be from business unit • May be one from each • Responsible for success of project – delivering quality system on time and within budget Page 393

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY The SDLC Project Team • Includes systems analysts • Have critical roles • Work closely with business managers and end users • Have problem-solving skills, knowledge of IT capabilities, strong business understanding • Has a business sponsor and a champion Page 394

Managing Change • The ability to manage change is critical to the success of systems development. • The new or modified systems created during systems development will inevitably cause change. • Managing change requires the ability to recognize existing or potential problems.

Significant Quote There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new information system. For the initiator has the enmity of all who would profit from the preservation of the old system and merely luke warm defenders in those who would gain from the new one.

Establishing Objectives for Systems Development • Systems development objectives should be supportive of, and aligned with, organizational goals. • There are four kinds of objectives that should be considered: • Performance objectives. • Cost objectives. • Control objectives. • Complexity objectives.

Systems Development Methodologies • A key factor in completing a successful systems development project is to adopt a methodology. • A methodology is a way of doing things.

Systems Development Methodologies • A systems development methodology is an assortment of rules and standards that govern the approach taken to all tasks associated with systems development. • In structured systems development the systems development tasks are broken down into small, easily managed parts.

Systems Development Methodologies • Top-down design means the entire system can be viewed as a layered set of descriptions, each of which could be decomposed, or “peeled back,” to reveal more detailed specifications for smaller parts of the system.

Structured Walkthrough • A structured walkthrough is a planned and pre-announced review of the progress of a particular project deliverable--a specific project outcome, a structure chart, or a human procedure. • The walkthrough helps team members review and evaluate the program of components of a structured project.

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY The SDLC Steps Key characteristic is extensive formal reviews required at end of each major step Figure 10.1 The Systems Development Life Cycle Page 386

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY The SDLC Steps Hallmark of SDLC approach: extensive up-front time spent determining requirements to avoid expensive changes later Figure 10.2 Cost Breakdown for $1 Million SDLC Project Page 386

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY The SDLC Steps SDLC: • Most often requires a lot of documentation • Outputs from one step inputs to next • Often referred to as the “waterfall” model Page 386

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY Definition Phase – Feasibility Analysis • Types of feasibility – economic, operational, and technical • Deliverable – 10-20 page document: • Executive overview and recommendations • Description of what system would do and how it would operate • Analysis of costs and benefits • Development plan Page 387-388

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY Definition Phase – Requirements Definition • Focuses on logical design: processes, data flows, and data interrelationships – not specific physical implementation • Deliverable – system requirements document: • Detailed descriptions of inputs and outputs, processes used to convert input data to outputs • Formal diagrams and output layouts • Revised cost/benefit analysis • Revised plan for remainder of project Page 388

Significant Quote • Brook’s Law: • Adding manpower to a late software project makes it later! • (Frederick P Brooks Jr.) Hofstadter's Law: It always takes longer than you think, even when you take Hofstadter's Law into account. (Douglas Hofstadter)

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY Construction Phase • System Design • System Building • System Testing Documentation is a major mechanism of communication during development process Figure 10.3 Characteristics of High Quality Systems Page 389

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY Implementation Phase • Installation • Operations • Maintenance Page 390

Implementation Phase – Installation Parallel Strategy Parallel Strategy Parallel Strategy Parallel Strategy Page 391 Figure 10.4 Implementation Strategies

Implementation Phase – Maintenance Figure 10.5 Percent of Development Resources Devoted to Maintenance Page 392

Implementation Phase – Maintenance Figure 10.6 The Widening Gap Between Organization’s Needs and System’s Performance Page 392

Significant Quote • Bove’s Theorem: • The remaining work to finish in order to reach your goal increases as the deadline approaches. Walking on water and developing software from a specification are easy if both are frozen. (Edward V Berard)

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY SDLC Advantages and Disadvantages Figure 10.8 Advantages and Disadvantages of Traditional SDLC Approach Page 395

Significant Quote • Deadline Dan’s Demon: • Every task takes twice as long as you think it will take. If you double the time you think it will take, it will actually take four times as long. • Meskimens Law • There is never time to do it right, but there is always time to do it over

Causes of Maintenance • Some major causes of program maintenance are: • New requests from stakeholders, users, and managers. • Bugs or errors in the program. • Technical and hardware problems. • Corporate mergers and acquisitions. • Governmental regulations.

Significant Quote Nixons Law The man who can smile when things go wrong has thought of someone to blame. Flon's axiom There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs. (Lawrence Flon)

Trends in Systems Development

Operational and Rapid Prototyping • An operational prototype is a prototype that works. • A partially operational prototype has some components that are operational. • A rapid prototype allows system stakeholders and users to see a mockup of the subsystem much faster, which enables earlier changes.

PROTOTYPING METHODOLOGY • Prototyping approach: • Takes advantage of availability of fourth generation procedural languages and relational database management systems • Enables creation of system (or part of system) more quickly, then revise after users have tried it • Is a type of evolutionary development process Page 396

PROTOTYPING METHODOLOGY • Prototyping examples: • Input and output screens developed for users to test as part of requirements definition • “First-of-a-series” – a completely operational prototype used as a pilot • “Selected features” – only some essential features included in prototype, more added later • Prototyping used as a complete alternative to traditional SDLC methodology Page 396

PROTOTYPING METHODOLOGY • Prototyping used as a complete alternative to traditional SDLC methodology: • Good when requirements hard to define • Good when system needed quickly • Impractical for large, complex applications Page 396

The Prototyping Steps Page 397 Figure 10.9 The Prototyping Life Cycle

PROTOTYPING METHODOLOGY Prototyping Advantages and Disadvantages • Advantages: • Only basic requirements needed at front end • Used to develop systems that radically change how work is done, so users can evaluate • Allows firms to explore use of new technology • Working system available for testing more quickly • Less strong top-down commitment needed at front end • Costs and benefits can be derived after experience with initial prototype • Initial user acceptance likely higher Page 398-399

PROTOTYPING METHODOLOGY Prototyping Advantages and Disadvantages • Disadvantages: • End prototype often lacks security and control features • May not undergo as rigorous testing • Final documentation may be less complete • More difficult to manage user expectations Page 399

PROTOTYPING METHODOLOGY Prototyping within an SDLC Process Figure 10.10 SDLC with Prototyping to Define Requirements Page 399

PROTOTYPING METHODOLOGY Prototyping within an SDLC Process Figure 10.11 Prototyping/Piloting Replaces SDLC Definition Phase Page 399

NEWER APPROACHES Rapid Application Development (RAD) • Hybrid methodology – aspects of SDLC and prototyping • Goal is to produce a system in less than a year Page 400 Figure 10.12 Four-Step RAD Cycle

NEWER APPROACHES Rapid Application Development (RAD) Joint application design (JAD) – a technique in which a team of users and IS specialists engage in an intense and structured process in order to minimize the total time required for gathering information from multiple participants Page 400-401

NEWER APPROACHES Rapid Application Development (RAD) Joint application design (JAD) – a technique in which a team of users and IS specialists engage in an intense and structured process in order to minimize the total time required for gathering information from multiple participants Computer-aided software engineering (CASE) – any software tool used to automate one or more steps of a software development methodology Page 400-401

NEWER APPROACHES Rapid Application Development (RAD) (Adapted from Valacich, George, and Hoffer, 2001) Page 401 Figure 10.13 Types of CASE Tools

NEWER APPROACHES Rapid Application Development (RAD) Figure 10.14 RAD Advantages and Disadvantages Page 402

NEWER APPROACHES Agile Software Development Discipline • Alternative methodology for smaller projects • Based on four key values: • Simplicity • Communication • Feedback • Courage • One type: Extreme Programming (XP) • Programmers write code in pairs • Use simple design and frequent testing Page 402

THE MAKE-OR-BUY DECISION • Decision should be made jointly by business managers and IS professionals • Advantages of purchasing: • Cost savings • Faster speed of implementation • Disadvantages of purchasing: • Seldom exactly fits a company’s needs • Often forces trade-offs Page 406

PURCHASING METHODOLOGY The Purchasing Steps Page 407 Figure 11.1 The Purchasing Process

PURCHASING METHODOLOGY Initiating the Purchasing Process Figure 11.2 Comparison of Costs and Building vs. Purchasing a System Page 407

PURCHASING METHODOLOGY Establish Criteria for Selection Figure 11.3 Key Criteria for Software Package Selection Page 408

PURCHASING METHODOLOGY Develop and Distribute the RFP Request for proposal (RFP) – a formal document sent to potential vendors inviting them to submit a proposal describing their software package and how it would meet the company’s needs Page 409

PURCHASING METHODOLOGY Evaluate Vendor Responses to RFP and Choose Package • Evaluation steps: • Review vendors’ responses from RFPs • Request demonstrations of leading packages • Request references from users of software packages in other companies • Assess how well package capabilities satisfy company’s needs • Understand extent of any additional development efforts or costs to tailor software • Make decision Page 410-411

PURCHASING METHODOLOGY Evaluate Vendor Responses to RFP and Choose Package Figure 11.6 Matching Company Needs with Capabilities of the Package Page 411

Systems Development