1b6e9f2fc3dd13330d4bfc821d668baa.ppt
- Количество слайдов: 19
• IS 371 WEEK 8 Instructor Online Evaluations • Last and Final Assignment • Application Development • Alternatives to Application Development 1
Application Portfolio Management Mc. Farlan 2
The Traditional Life-cycle Approach · Program development is subdivided into phases · This makes complex activities easier to understand 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 3
Stages of the SDLC 4
Major Causes of System Failure l l l l 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 5
Risk Analysis l Client Activities l Programming and management skills l Application characteristics l Project importance and commitment l Hardware requirements l System software requirements 6
Risk Management Analysis Primer l A process for assessing ¡ threats and determining which ones to l l l ¡ l ignore, reduce, eliminate level of feasible support for efforts to reduce and eliminate Expected Loss = P 1 x P 2 x L where: P 1 = Probability of attack P 2 = Probability attack is successful L = loss occurring is attack is successful 7
Risk Management Analysis Primer l. A process for assessing ¡ threats and determining which ones to ignore, l reduce, l eliminate l ¡ level of feasible support for efforts to reduce and eliminate by comparing expected losses to prevention costs 8
Risk Management Analysis Primer l Expected Loss or EL = P 1 x P 2 x L where: P 1 = Probability of attack P 2 = 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 9
Risk Analysis Steps 10
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 11
Release 1 Requirements Analysis Design Code Test Release 2 Release Requirements Analysis Design Code Release 3 Test Release Requirements Analysis Design Code Test 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. Release 12
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 13
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. 14
Make or buy decision Decision Criteria Business strategy Pressure to “Make/Own” IT application or infrastructure provides proprietary competitive advantage Pressure to “Buy” IT application or infrastructure supports strategy or operations, but is not considered strategic in its own right Core competence Information/ process security and confidentiality Availability of suitable partners Availability of packaged software or solutions Cost/benefit analysis Time frame for implementation Evolution and complexity of the technology Ease of implementation 15
PACKAGED SOFTWARE EXTERNAL VENDOR IN-HOUSE DEVELOPMENT BUSINESS NEED STANDARD NON-STRATEGIC IN-HOUSE EXPERIENCE IN-HOURSE FUNCTIONAL AND TECHNICAL SKILLS EXIST NO IN-HOUSE EXPERIENCE IN-HOUSE FUNCTIONAL & TECHNICAL SKILLS EXIST PROJECT SKILLS ARE STANDARD OUTSOURCING IS A STRATEGIC DECISION IN-HOUSE ONGOING NEED PROJECT MANAGEMENT ABILITY TO COORDINATE WITH VENDOR ABILITY TO DEFINE OUTSOURCING TERMS IN-HOUSE MANAGEMENT AND TECHNOLOGY EXPERIENCE TIME SHORT FLEXIBLE 16
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. 17
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 18
Accounting for Information Technology Costs n. Allocated Method Description Advantage n. Unallocated cost ncenter n. All IS costs are considered n. Experiments with an organizational expense technology can occur n. User can request the development of new systems n. IS can develop systems regardless of economic benefit. n. Allocated cost ncenter n. IS department allocates costs to departments that use its services. n. Profit center n. IS charges internal and external users the same and attempts to get both kinds of business. Disadvantage n. Costs can get out of control. n. IS professionals cannot easily allocate their budget among conflicting requests. n. User request only beneficial services. n. It works well in organization where changes are made regularly to all internal customers n. IS can have problems determining allocation of costs n. Friction among user departments and between them and IS can occur n. IS has no reason to operate efficiently. n. Users can choose who will n. Outsourcing may become perform their IT service. more common. n. IS department has n. Fees may be higher than incentives to operate with other methods. efficiently. 19