• IS371 WEEK 8 • Last and Final Assignment • Application Development

1. • IS371 WEEK 8 • Last and Final Assignment • Application Development • Alternatives to Application Development Instructor Online Evaluations

2. Application Portfolio Management McFarlan

3. The Traditional Life-cycle Approach The Traditional Life-cycle Approach · Program development is subdivided into phases · This makes complex activities easier to understand and control · Skills vary over time and are more easily managed in phases · Interactions between developers and users are improved · Phases permit systematic management intervention Phases in Development Life Cycle 1. Initial investigation 4. Development 2. Requirements definition 5. Installation 3. General design 6. Post-installation

4. Stages of the SDLC

5. Major Causes of System Failure • Lack of project plan and bad project management • Inadequate definition of project scope • Lack of communication with end users • Insufficient personnel resources and associated training • Lack of communication with project team • Inaccurate estimate • Scope creep • Expectation Failure

6. Risk Analysis • Client Activities • Programming and management skills • Application characteristics • Project importance and commitment • Hardware requirements • System software requirements

7. Risk Management Analysis Primer • A process for assessing • threats and determining which ones to • ignore, • reduce, • eliminate • level of feasible support for efforts to reduce and eliminate • Expected Loss = P1 x P2 x L where: P1 = Probability of attack P2 = Probability attack is successful L = loss occurring is attack is successful

8. Risk Management Analysis Primer • A process for assessing • threats and determining which ones to • ignore, • reduce, • eliminate • level of feasible support for efforts to reduce and eliminate by comparing expected losses to prevention costs

9. Risk Management Analysis Primer • Expected Loss or EL = P1 x P2 x L where: P1 = Probability of attack P2 = Probability attack is successful L = Loss occurring is attack is successful PC = Prevention costs If EL < PC then ignore If EL > PC then investing in PC is reasonable

10. Risk Analysis Steps

11. The SPIRIAL MODEL Do a little bit of requirements gathering, then a little bit of analysis, design, coding, test and release, and then use that as the starting point for getting and clarifying the next small set of requirements

12. Release 1 Requirements Analysis Design Code Test Release Release 2 Requirements Analysis Design Code Release 3 Test Release Requirements Analysis Design Code Test Release The problem with a small amount of requirements is that when you get your next set of requirements, you find that you did something wrong, or asked the wrong question when getting the first set of requirements. By the final incremental iteration, your system is such a mess that no-one can understand how it got that way.

13. SYSTEM CONSTRUCTION GOOD DESIGN CHECKLIST 1. WORKS CORRECTLY 2. RELIABLE 3. MAINTAINABLE 4. EASY TO USE 5. EASY TO IMPLEMENT / TEST 6. EFFICIENT 7. ON TIME/ON BUDGET

14. MEASURES OF IT SUCCESS/FAILURE ON TIME/ON BUDGET SYSTEMS THAT DON’T RESULT IN AT LEAST A MINIMALLY FUNCTIONING SYSTEM OR HAVE MAJOR COST OR TIME OVER RUNS WILL BE CONSIDERED FAILURES CORRESPONDENCE SYSTEMS THAT ARE JUSTIFIED BASED ON PLANNED BENEFITS THAT ARE NOT REALIZED WILL BE CONSIDEED FAILURES EXPECTATION SUCCESS IS MEASURED BY THE ATTITUDE OF THE USER TOWARD THE SYSTEM. IF THE USER WILL NOT, OR CAN NOT, USE THE SYSTEM IT WILL BE CONSIDERED A FAILURE.

15. Make or buy decision Decision Criteria Pressure to “Make/Own” Pressure to “Buy”

17. Packaged software PROS Faster implementation Lower maintenance expense the organization need not redefine requirements for legal or other new requirements. Instead, this is the vendor’s job. Purchased software provides extensive documentation. CONS Has a tendency to evolve slowly. May use multiple programming languages. May be incompatible with users’ databases.

18. SYSTEM CONSTRUCTION TO BUILD OF BUY, THAT IS THE QUESTION 1. DEFINE YOUR REQUIREMENTS 2. IDENTIFY YOUR ALTERNATIVES 3. BUY IT IF YOU CAN CONSIDER: REPUTATION OF THE VENDOR LEVEL OF VENDOR SUPPORT CONTACT CURRENT CUSTOMERS VERIFY QUANTITIVE MEASURES OF PERFORMANCE EASE OF CUSTOMIZATION GOOD v. PERFECT FIT

19. Accounting for Information Technology Costs • Allocated Method Description Advantage Disadvantage • All IS costs are considered an organizational expense • Experiments with technology can occur • User can request the development of new systems • IS can develop systems regardless of economic benefit. • Costs can get out of control. • IS professionals cannot easily allocate their budget among conflicting requests. • Unallocated cost • center • IS department allocates costs to departments that use its services. • User request only beneficial services. • It works well in organization where changes are made regularly to all internal customers • IS can have problems determining allocation of costs • Friction among user departments and between them and IS can occur • IS has no reason to operate efficiently. • Allocated cost • center • IS charges internal and external users the same and attempts to get both kinds of business. • Users can choose who will perform their IT service. • IS department has incentives to operate efficiently. • Outsourcing may become more common. • Fees may be higher than with other methods. • Profit center