710 Foundations of Information Systems Chapter 8 Information

710: Foundations of Information Systems Chapter 8: Information Systems Development

Spectacular Software • Baggage handling at Denver International – Delayed the opening of the airport for months causing billions of dollars in lost revenue • Space Shuttle – Runs on 5 computers from the 1970 s. Modified for every mission. Last error recorded 10 years ago. • Ariane 5 – Exploded because software was reused in new context • Linux/Apache/Mozilla (and other open source products) – Developed by people who never see each other 2 © Jakob Iversen, 2003

Characteristics of Software • Software is developed – not produced • Software doesn’t wear out (but still requires maintenance) • Most software is developed for specific purposes – not based on standardized components Price of changes 100 • Changes/mistakes can be costly 1 © Jakob Iversen, 2003 Definition 10 Development Maintenance 3

Wait a minute… • I’m not going into IT, why should I care about how systems are developed? This is never going to be my job! – True, but most projects involve users and business managers need to understand the process. – You may be a customer of a project – Most businesses depend on their IS for survival (remember strategic systems? ) – You will likely be involved in at least one systems development project in your career (grab the chance if you get it). 5 © Jakob Iversen, 2003

Participants in Systems Development 6 © Jakob Iversen, 2003

The Information Systems Planning Process • Purpose: Look at the entire company before deciding on specific systems to be developed • Overall strategy determines what types of systems are developed 7 © Jakob Iversen, 2003

Steps in IS Planning 8 © Jakob Iversen, 2003

Classical Approach: The Waterfall Model • Advantages Systems Investigation Analysis / Req. Spec. Design Generate Code Test • Disadvantages – – – Easy to understand – Easy to start using – Known from other disciplines – Can be used for controlling – Curbs featuritis (scope creep) Maintenance Highly inflexible No iteration possible No changes to requirements Results come late More effort in some phases 9 © Jakob Iversen, 2003

Systems Development Life Cycle 10 © Jakob Iversen, 2003

Phase: Systems Investigation • Purpose: Determine probability of success of proposed system’s development project • Feasibility Analysis 11 © Jakob Iversen, 2003

Phase: Systems Analysis • Purpose: Examine the business context, and define the problem. • Major activity: – Collect data about current system(s), desired new system • Deliverable: Systems Requirements – What is the system supposed to do? • Problem: Communication between users and developers 12 © Jakob Iversen, 2003

Sources of Data 13 © Jakob Iversen, 2003

Request for Proposal (RFP) • One of the most important documents generated during systems development. • Results in a formal bid that is used to determine who gets a contract for new or modified systems. • Specifies required resources in detail. 14 © Jakob Iversen, 2003

Phase: Testing • Purpose: Making sure the system does what it is intended to do (adheres to specification) • Not just done at the end! • Test specification is ideally developed with req. spec. (V-model) 15 © Jakob Iversen, 2003

Phase: Systems Design • Analysis: WHAT will the system do? • Design: HOW will it do it? • Deliverable: Design Specification – Final documentation before programming starts • Issue: Control Scope creep (featuritis/gold plating) • Elements of Design – Interface design • What does it look like? Standards? – Data design • How are the data structured? – Process design • What does it do? Rules? – Object design • How are objects defined and structured? – Physical design • Which hardware? 16 © Jakob Iversen, 2003

Phase: Programming • Purpose: Use programming language to code the design specification • Typically the most resource-demanding phase (but not the most critical in terms of project success) • Deliverable: A running system 17 © Jakob Iversen, 2003

Implementing New Systems Strategy Direct conversion Description Old system replaced overnight Time Req. Cost Risk Minimal Low Pilot start-up New system used in Moderate Phased implementation Components of system introduced one at a time High Moderate Low to high Parallel implementation Old and new system used simultaneously for some time High a few parts of organization High Low 18 © Jakob Iversen, 2003

Start-Up Options (implementation) 19 © Jakob Iversen, 2003

Maintaining and Reviewing Systems • Maintenance – Improvements, modifications, corrections, updates, etc. – New needs may come up – New uses of existing systems – Most of the cost is in this phase! • Post Implementation Review – Some months after system delivery – What was learned from the effort? – Involves both customers and developers – Facilitates learning from experiences – Is often ‘forgotten’ 20 © Jakob Iversen, 2003

NOT E: N ot in clud Incremental Model 1 ed i n th e bo ok! Increment 1 Analyze Design Code Test 2 Analyze Design Code Test 3 Analyze Design Code Increment 2 Test Increment 3 • Total system is developed in increments • First increment: Basic functions implemented – 80/20 rule: 80% of needs covered in 20% of functionality • • Change requests are pooled and implemented in later increments A large system can be developed by fewer people (over longer time) This model is used for most consumer software (PC software) Can be more expensive than waterfall model (but may give better results) 21 © Jakob Iversen, 2003

Prototyping, JAD, RAD • Characteristics Listen to Customer Build/Revise Model – Involves customers/users – Build-and-discard – Iterative • Advantages – System meets needs – Handles uncertainty – Short turn-around time Customer Tests Model © Jakob Iversen, 2003 • Disadvantages – Prototype looks finished: customer won’t wait – Quick-and dirty development forgotten along the way 22

Extreme Programming (XP) • Take good software engineering practices and take them to the extreme • Becoming a very popular method • Focuses on delivering results very quickly • An example of an ”agile methodology” • Learn more – www. xprogramming. org – www. extremeprogramming. org • Peer review is good – Extreme: Pair programming • Customer involvement is good – Extreme: Customer is part of team • Communication is good – Extreme: Everybody in the same room – Very little written documentation • Fast results are good – Release system every 2 -4 weeks • Testing is good – Extreme: Test before writing the code 23 © Jakob Iversen, 2003

Capability Maturity Model for Software (CMM) • Becoming very popular for software process improvement (SPI) • Takes a long time (5 -10 yrs to L 5) • Pervades all aspects of SWdevelopment © Jakob Iversen, 2003 24

The Make-or-buy decision • Do-it-yourself – Meets all needs, but expensive and possibly low quality • Buy packaged software – Cheap, but may not meet all needs – Usually high quality • Customize packages – Problems when upgrading – Possibly low quality of customizations 25 © Jakob Iversen, 2003

26 © Jakob Iversen, 2003

Outsourcing of SW development • Hiring a consultant or software house • Advantages – Better expertise, Fines for delays, Clear division of responsibility, Larger projects can be handled • Problems – Difficult communications, Problems stay hidden, More expensive, Loss of expertise/knowledge, • Can also be international (e. g. India) – Raises a host of new issues – Companies getting more experienced with this – A very hot topic as IT jobs are lost in the US © Jakob Iversen, 2003 27

Outsourcing of IT Operations • Focus on core competencies – “Do what you do best, outsource the rest” • Common for large companies to outsource IT operations – Often billions of dollars over 10+ years • Major players – EDS, IBM, AT&T, CSC • Advantages – No need to worry about day-to-day operations of network, PCs etc. • Disadvantages – Difficult to get out of contract © Jakob Iversen, 2003 28

Next Week • Lecture – Chapter 9 • Group Presentations – Team 7 and 8 • Student Opinion Surveys • Exam – Blackboard – Friday – Sunday – Two hours available – Multiple choice and short answer questions 29 © Jakob Iversen, 2003