Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright RCI, 20051 The Role of Business Case Analysis in Software Engineering Lecture #1 Based on Donald J. Reifer’s lecture Supannika Koolmanojwong.

Similar presentations

Presentation on theme: "Copyright RCI, 20051 The Role of Business Case Analysis in Software Engineering Lecture #1 Based on Donald J. Reifer’s lecture Supannika Koolmanojwong."— Presentation transcript:

1 Copyright RCI, 20051 The Role of Business Case Analysis in Software Engineering Lecture #1 Based on Donald J. Reifer’s lecture Supannika Koolmanojwong

2 Copyright RCI, 20052

3 3 For Software, Change is Constant Agile methods Streamlined processes Best engineering practices Metrics-based management COTS-based systems Architecture-first Process paradigms Component-based composition Reuse/patterns Product-linesExtreme programming Experience factory Searching for ways to do the job faster, better and cheaper Other silver bullets

4 Copyright RCI, 20054 Business Cases Quantify the Impact of Such Changes As understood by most, engineering decisions involve many options and difficult tradeoffs –May be several technical solutions for the problem –The best technical solution is determined by evaluating the tradeoffs using a variety of criteria selected for that purpose Software engineering provides you the methods and tools to understand the tradeoffs and select the best answer (typically under constraints) –Management rejects many of these recommendations because the business benefits are not quantified

5 Copyright RCI, 20055 Pervasive Issues When Developing Business Justifications Common definition of costs and benefits not widely accepted across the industry Productivity, cost and quality data considered highly confidential and kept secret Common definition of the justification processes involved lacking within the engineering community Difficult to attribute resulting numbers to one cause or another Hard to communicate results - engineers talk technical, decision-makers talk business Goal of the lecture is to help you communicate better

6 Copyright RCI, 20056 Justifying Improvement Initiatives to Address Change Time to Market Cost Productivity Quality ReduceAvoid/Cut IncreaseImprove There needs to be some compelling business reason for making an improvement, else it won’t be approved Improve Customer Satisfaction

7 So now, you want to make some improvement. How can we introduce the changes / improvement to the organization ? Will they believe my idea? Are they going to listen to me? 7

8 8

9 Technology Adoption Life Cycle Model Stage in Life CycleOrganizations’ Characteristics InnovatorsRisk takers Develop new technology Push the envelope Early adoptersTrend setters Advance technology Will take high risks when justified Early majorityInnovators Take moderate risks Late majorityFollowers Exploit technology Take limited risks LaggardsCritics Use proven technology Risk averse Copyright RCI, 20059

10 10 Example: CMMI Level 5 - Technology Innovation Seven-Step Process 1.Establish improvement objectives 2.Improvement proposal collection & analysis 3.Identify innovations 4.Perform cost/benefit analysis 5.Perform pilot 6.Select candidate improvements 7.Provide feedback Source: Ahern, CMMI Distilled

11 Copyright RCI, 200511 Challenges Associated with Making Organizational Changes Lack of incentives “Good of the firm” versus “Good of the project” Infrastructure shortfalls Few meaningful metrics Limited cash available Reward system must be altered Reward system must be altered to emphasize “good of firm” Policies, processes and decision making structure changes Must collect data to quantify impact of changes To get funded, must make compelling business case

12 Copyright RCI, 200512 Why Change - Five Good Reasons? Keeping up with the competition –Playing catch-up is always a motivation for change Achieving economic benefits –Having a compelling business reason also works Supporting new product needs –Tying change to a product need justifies investment Avoiding legal entanglements –Sometimes changes are needed to comply with the law Achieving efficiencies –Streamlining/simplifying process also justifies change


14 Copyright RCI, 200514 Are You Ready for Change? Examine the following: –Consistency with business goals/cycle –Compatibility with level of process maturity –Consistency with corporate culture –Compatibility with investment strategies –Achievability within desired timetable If warranted, be willing to take the risk –The opportunity should be justifiable in terms of the risk/returns

15 Copyright RCI, 200515 Changing Corporate Cultures Seeks opportunity for improvement Action-oriented and willing to take risks Team-oriented Rewards innovation Learns from failure Creative, imaginative, pliant and flexible Prefers the status quo Avoids change and risk Territorial by nature Rewards followers, not innovators Penalizes failure Persistent, authoritative and rigid Entrepreneurial Culture Old-Fashioned Culture

16 Copyright RCI, 200516 Making Changes: Eight Lessons Learned the Hard Way 1.Tie improvement to organizational goals 2.Emphasize making product-oriented improvements 3.Demonstrate value that justifies improvements 4.Make your new processes the way you do business 5.Recognize major barriers to change are primarily political and psychological 6.Change your culture to one that rewards risk- taking 7.If you don’t have the talent, buy it 8.Use numbers to overcome post-decision dissonance

17 Copyright RCI, 200517 Success is a Numbers Game Will this proposal save money, cut costs, increase productivity, speed development or improve quality? Have you looked at the financial and tax implications of the proposal? What’s the impact of the proposal on the bottom line? Are our competitors doing this? If so, what are the results they are achieving? + Many more tough questionsWho are the stakeholders and are they supportive of the proposal? + Many more tough questions Answer Basic Business-Related Questions

18 Copyright RCI, 200518 Business Cases Supply You with the Winning Numbers Business CaseBusiness Case = the materials prepared for decision- makers to show that the proposed idea is a good one and that the numbers that surround it make sound financial sense –Most software engineers prepare detailed technical rather than business justifications –Many of their worthwhile proposals are rejected by management as a consequence –Use of business cases to complement the technical case can greatly increase their chances of success

19 Copyright RCI, 200519 Business Versus Technical Cases Factors (5 is best) Java C/C++ - Core language features24 - Degree of standardization & portability34 - Object-oriented support35 - Reuse facilities (library, browser, etc.)34 - Web programming support52 - Optimizing compilers available45 - Bindings available55 - Rich libraries available44 - Compiler support tools available45 - Inexpensive visual tools available53 - Oriented toward your products53 Score 43 44

20 Copyright RCI, 200520 Business Versus Technical Cases Factors (5 is best)JavaC++ - Popularity - improve resumes 5 5 - Training opportunities available 5 4 - Literature and books available 5 5 - Consultants & subcontractors available 5 5 with language skills - Staff maintains competency in language/tools 2 4 - Retooling and retraining costs 1 5 - Transition costs associated with learning 1 5 curve (bring staff up to speed)______ Subtotal2433 Combined Score6777

21 Copyright RCI, 200521 The Business Planning Process 1. Prepare white paper 2. Demonstrate technical feasibility 3. Conduct market survey 4. Develop business plan 5. Prepare business case 6. Sell the idea and develop support base 7. Get ready to execute GQM Results Idea or proposal Proof of Concept Approval to go-ahead

22 Copyright RCI, 200522 Aligning with Goals - Your First Step Goal - successful technology transition Q1 - ready for use? Q2 - benefits quantified?Q3 - costs of use understood? M1 - availability of tools M1 - cost avoidance in $ M1 - startup costs M2 - availability of M2 - time-to-market deltaM2 - operational training M3 - quality delta costs M3 - availability of M3 - opportunity methods costs M4 - availability of infrastructure Use the G-Q-M Paradigm

23 Copyright RCI, 200523 Stepping Through the Process 1.Prepare white paper –State what you are trying to do crisply 2.Demonstrate technical feasibility -Let’s you prove the idea’s value -Provide management with early evidence that you can deliver what you promised them 3.Conduct market survey –Determine the market need for your idea –Understand what the competition is doing and what your customers want –Focus on market creation, not sharing –Get to market first, be agile and take risks that allow you to seize the opportunity

24 Copyright RCI, 200524 More on the Process 4.Develop business plan –Needed before idea will be funded –Such plans summarize how you will make or save money, not how you’ll get the job done 5.Prepare business case –Convince sponsor idea makes both good technical and business sense and provides value 6.Sell the idea –Package for sales/champion 7.Get ready to execute –Plan the project thoroughly (your project plan) –Start recruiting key staff –Work communications and outreach up front –Search out facilities to co- locate team and for conducting demos –Prepare your operational concepts (support, etc.)

25 Copyright RCI, 200525 Business Process Framework Business Planning Process Tradeoff and Analysis Processes Software Development Process Analytical Methods ModelsGuidelines for Decision-Making Process The business planning process proceeds in parallel Framework and interfaces with the software development process “Principles, Rules and Tools for Business Case Development”

26 Assume you are moving towards java, but no one knows java You need to improve their skills What are the choices do we have here? Copyright RCI, 200526

27 Let say you are thinking about running a seminar. How can you make a business case on this? Copyright RCI, 200527

28 Copyright RCI, 200528 Nine Business Case Principles 1.Decisions should be made relative to alternatives 2.If possible, use money as the common denominator 3.Sunk costs are irrelevant (Engineering Econ 101) 4.Investment decisions should recognize the time value of money 5.Separable decisions must be considered separately 6.Decisions should consider both quantitative and qualitative factors 7.The risks associated with the decision should be quantified if possible 8.The timing associated with making decisions is critical 9.Decision processes should be periodically assessed and continuously improved 1.Do nothing, learn by themselves 2.On-the-job training 3.Bring in seminar / hands-on training 1.Do nothing, learn by themselves 2.On-the-job training 3.Bring in seminar / hands-on training How can a training seminar save costs / save time / improve quality ? Calculate that in $$ How can a training seminar save costs / save time / improve quality ? Calculate that in $$ thinking about running a seminar. What happened in the past, stay in the past. Already ran a java seminar last year ? it does not matter. New staff What happened in the past, stay in the past. Already ran a java seminar last year ? it does not matter. New staff $10 today = $8 next year Save in the bank, %6 interest Any better option ? $10 today = $8 next year Save in the bank, %6 interest Any better option ? If you need select a training firm, use different criteria, don’t mix them up.

29 Copyright RCI, 200529 Nine Business Case Principles 6.Decisions should consider both quantitative and qualitative factors 7.The risks associated with the decision should be quantified if possible 8.The timing associated with making decisions is critical 9.Decision processes should be periodically assessed and continuously improved Training seminar might improve image and morale. What if no trainer available, any back up plan ? What is the extra cost? thinking about running a seminar. Time your decision carefully. Any budget cycle ? Propose when there is money available. Time your decision carefully. Any budget cycle ? Propose when there is money available. Keep your eyes open, look for possible improvement.

30 Copyright RCI, 200530 Success Tactics Address the cultural issues first - they’re the hardest Keep senior management informed of your progress Build alliances with both projects and people Publicize successes and spread the word widely Mix it with the middle managers and critics Don’t be afraid to change horses in mid-stream Deliver something that you can brag about Be perceived as successful by others (perception is reality) Work continuously to improve the infrastructure you’ve set up to manage the initiative and transfer the technology

31 Copyright RCI, 200531 Use Engineering Economics as its Analytical Basis Takes cost of money into account –A $$ today is worth more than tomorrow due to inflation Takes compounding into account Normalizes future expenditures using current year dollars as a basis for comparison Lets you establish a minimum attractive rate of return FW = P (1 + i) N PV = FW/(1 + i) N Future Worth Present Value

32 Present Value Calculation for Training Example YearTraining CostBenefitsNet Benefits1/(1+i) N Present Value 1$25K$35K$10K0.9259$9259 2$25K$35K$10K0.8573$8753 3$25K$35K$10K0.7938$7938 4$25K$35K$10K0.7350$7350 $40K$33120 Copyright RCI, 200532 Cost of Money or Interest rate = 8% Assuming that the training will reduce the personnel turnover by from 6% to 3% Reduce lost in productivity $35K a year

33 Then calculate ROI ROI = net benefit / investment = $40,000 / $100,000 = 40% or 10% annually Copyright RCI, 200533 YearTraining CostBenefitsNet Benefits1/(1+i) N Present Value 1$25K$35K$10K0.9259$9259 2$25K$35K$10K0.8573$8753 3$25K$35K$10K0.7938$7938 4$25K$35K$10K0.7350$7350 $40K$33120 Good choice ? 10% annually for manager – may not be a good idea Put in the bank, no risks – get 8% What can we do ?

34 Copyright RCI, 200534 Use Other Available Techniques Balanced scorecard Break-even analysis Cause and effect analysis Cost/benefit analysis Opportunity tress Pareto analysis Payback analysis Portfolio analysis Real options theory Return-on-Investment/Capital Risk analysis (exposure) Sensitivity analysis Trend analysis Value chains Analysis Techniques Source: Boehm, Software Engineering Economics

35 Balanced Score Card 35 Used by managers to keep track of the execution of activities by the staff within their control and to monitor the consequences arising from these actions

36 Breakeven Analysis 36

37 Payback Analysis To determine the number of periods required to recover one’s investment Payment period = investment /net savings =($25K) / ($10K/year) = 2.5 years = the payback period for the first year’s investment is 2.5 years Copyright RCI, 200537 YearTraining CostBenefitsNet Benefits1/(1+i) N Present Value 1$25K$35K$10K0.9259$9259 2$25K$35K$10K0.8573$8753 3$25K$35K$10K0.7938$7938 4$25K$35K$10K0.7350$7350 $40K$33120

38 Copyright RCI, 200538 Example – Cost/Benefit Analysis Want to bring in training to support PSP/TSP initiative How would you justify the investment? –Should you use cost/benefits, quality improvement or some other approach? How would you pay for the training? –Is this a capital, project or customer expense? What are the windows of opportunity and how would you take advantage of them? –Can you influence next year’s training budget? –Is there State funds available? Can we partner? Is there mid-year or year-end funds available?

39 Copyright RCI, 200539 Doing a Cost/Benefit Analysis Non-recurring costs –Course acquisition ____ –Course conduct ____ Recurring costs –Course maintenance ____ –Continuing education ____ Tangible savings –Cost avoidance ____ –Cost savings ____ Intangible savings –Reduced turnover ____ –Less risk exposure____ Total ____ Total Costs ____ Total ____ Total Benefits ____ Total ____ PV$)$) Cost/Benefit Ratio = PV (Total costs ($)/Total Benefits ($))

40 Copyright RCI, 200540 Quantifying Avoidance: Software Dependability Opportunity Tree Decrease Defect Risk Exposure Continuous Improvement Decrease Defect Impact, Size (Loss) Decrease Defect Prob (Loss) Defect Prevention Defect Detection and Removal Value/Risk - Based Defect Reduction Graceful Degradation CI Methods and Metrics Process, Product, People Technology Source: Boehm

41 Copyright RCI, 200541 - Loss due to unacceptable dependability Time to Ship (Amount of Testing) Risk Exposure (RE) Many defects: high P(L) Critical defects: high S(L) Few defects: low P(L) Minor defects: low S(L) Quantifying Risk Exposure (RE) via a Profile: Time to Ship Source: Boehm

42 Copyright RCI, 200542 - Loss due to unacceptable dependability - Loss due to market share erosion Time to Ship (Amount of Testing) RE Few rivals: low P(L) Weak rivals: low S(L) Many rivals: high P(L) Strong rivals: high S(L) Many defects: high P(L) Critical defects: high S(L) Few defects: low P(L) Minor defects: low S(L) Example RE Profile: Time to Ship Source: Boehm

43 Copyright RCI, 200543 Example RE Profile: Time to Ship Time to Ship (Amount of Testing) RE Few rivals: low P(L) Weak rivals: low S(L) Many rivals: high P(L) Strong rivals: high S(L) Sweet Spot Many defects: high P(L) Critical defects: high S(L) Few defects: low P(L) Minor defects: low S(L) - Sum of Risk Exposures Source: Boehm

44 Copyright RCI, 200544 Getting Management Approval Why should they invest in training instead of other alternatives? –There needs to be a compelling business reason, else why make the effort –This must be the most attractive option examined Why invest now instead of some later time? –Need to show opportunity is knocking & funds are available What do I have to do if I say “yes” to the proposal? –Must show them that their efforts will be minimal; you’ve done all of the leg work and all they have to do is sign

45 Copyright RCI, 200545 Many Supportive Tools Decision support systems –Tax planning and schedules –Trade studies and analysis Spreadsheets –Comparative analysis –Trade studies and analysis Software cost models –Parametric analysis –Trade studies and analysis Software packages

46 Copyright RCI, 200546 Including Estimating Models like COCOMO II - Of Course Sizing Model Estimating Model Risk Model * Benchmark analysis* Parametric analysis * Comparative analysis* Trade studies * Life cycle cost analysis* “What-if” analysis

47 Copyright RCI, 200547 Business Case Information Needs Business cases –Recurring costs –Non-recurring costs –Tangible benefits –Intangible benefits Benchmarks –Competitive comparisons –Industry norms Metrics –Management measures Financial data –Inflated labor costs –Labor categories/rates –Overhead/G&A rates –Past costs/performance –Tax rates/legalities Marketing information –Demographic data –Market position –Sales forecast

48 Copyright RCI, 200548 Emphasize Cost Avoidance Justify using cost avoidance not reduction Keep cost & productivity considerations separate Tap money when it becomes available Know what cost you can control and who controls the others Package numbers for consumption by seniors Don’t assume the numbers won’t be scrutinized Don’t assume you know what your current costs are and how they are allocated to cost centers Don’t confuse management by combining cost and profit in same proposal Don’t mix cost accounts when justifying ideas Things to Do Things Not to Do

49 Copyright RCI, 200549 Packaging Business Cases for Management Consumption Convincingly summarize the numbers at the start Define your terms precisely - communicate meaning using examples Be conservative with your numbers Quantify tangible benefits in monetary terms Don’t mix capital expenditures with project budgets Use ranges for cost/benefits whenever possible Portray the PV of your benefits in this year’s dollars Focus attention on the business, not technical issues

50 Copyright RCI, 200550 When Communicating with Senior Managers, Remember They are like elephants, they never forget a number once uttered They will hear only what they want to hear Simple is better - package charts with at most five bullets

51 Copyright RCI, 200551 Final Points So Far Numbers can be your ally when asking for money When talking money, speak your management’s language not your own Don’t be casual about numbers, be precise To be successful, be perceived as successful

52 Copyright RCI, 200552 Chapter 5 - Justifying Process Improvement Purpose of case –Justify investments in process improvement Goals of effort –Develop numbers that get management to buy into near- and long-term investment tactics Constraints –Deal with the firm’s related process improvement folklore, biases and history

53 Copyright RCI, 200553 Organizational Structure Senior Management EngineeringField SupportManufacturingProgram Mgmt Process Group QA Group Senior Staff * Systems * Fabrication * Field service * Software * Assembly * Training * Digital design * Production * Test & evaluation Project A Line of Business Management * Fund functional groups * Coordinate * Facilitate Your home Aerospace firm

54 Copyright RCI, 200554 History of Process Improvement Maturity Level 19851987198919911993199519971999Now Level 3 - a customer requirement Reach Level 3 - corporate goal 5432154321 Process budget axed Acquisition falls through Firm positioned to be acquired Process group reformed Seniors get serious about process Aim- Reach Level 4 in 2 years

55 Copyright RCI, 200555 The SEI Software CMMI Used by many to characterize the maturity of the processes used to develop software Important because: –Employed as a means to benchmark firms –Acts as a framework for structuring improvements –Shown to have positive effect on productivity, quality and cost –Makes it easier to tackle a big software job like the one you are working on

56 Copyright RCI, 200556 The Software CMMI - Requirements management - Software project planning - Software project tracking and oversight - Software subcontract management - Software qualify assurance - Software configuration management - Organization process focus - Organization process definition - Training program - Integrated software management - Software product engineering - Inter-group coordination - Peer reviews - Quantitative process management - Software quality management - Defect prevention - Technology change management - Process change management 3 2 4 5 Contains: - 5 Maturity Levels - 18 Key Process Areas - 318 Key Practices

57 Copyright RCI, 200557 CMMI Lessons Learned Takes 18 to 30 months to move a maturity level –From Level 1 to 2 - average of 23 months –From Level 2 to 3 - average of 21 months –From Level 3 to 4 - average of 28 months Average investment to move up a maturity level is several million The gains attributable to early error detection and correction are substantial (20X cheaper) The average increase in productivity attributable to process improvement is 10 percent

58 Copyright RCI, 200558 Software Improvement Strategy Strategy Discipline the Software Process Standardize Products Professional workforce Quicken use of new technology * Proactive, not * Architecture- * Career paths * Project sponsors reactive based * Skill-based for IR&D * Optimizing * Massive reuse education and * Good idea * CMM-based * Open systems training programs * ISO-certified * Product lines * Distance * Technology * Components learning roadmap

59 Copyright RCI, 200559 More Background Information Overall experience –Workforce averages 20 years experience Staff capabilities and morale –Good - newcomers more open to change Education & training –Myriad of training opportunities available World-class facilities and environment –Undercapitalized, but making improvements primarily to reduce personnel turnover Technology adoption –IR&D for software tripled after major client criticized management

60 Copyright RCI, 200560 Rules of Engagement Let the numbers do the talking Don’t assume that Program Managers understand software (they are clue-less) Justifications must be made at the project level You must address past experience, both pro & con Your plan must focus on near-term results Any software processes must be compatible with your existing management infrastructure You must track/demonstrate accomplishment of goals

61 Copyright RCI, 200561 Process Group Organization Manager (New) Process Developer (Vacant) Process Developer (Vacant) Metrics Analyst (New) Project Liaison (Consultant) Project Liaison (Consultant) Curriculum Developer (Part-Timer) Curriculum Developer (Part-Timer)

62 Copyright RCI, 200562 Start - Why Focus on Process? Why (Goal): Questions: Metrics: Models: Increase Productivity and Meet Customer Requirements MeasuredWhat Why this how? option? option? SLOC/hour Do Process Other ROI Nil improvement approach COCOMO SEI Maturity Non-discounted Model ROI

63 Copyright RCI, 200563 Recommended Process 1. Involve the Stakeholders 2. Develop a vision and strategy 3. Define the work to be performed 4. Build partnerships 5. Promote the results * Expectations * Measures of success Vision statement * WBS dictionary * Game plan Positive public relations Pilot results

64 Copyright RCI, 200564 Work Breakdown Structure Process development Education & training Process roll-out/project support Process assessment Promotion & outreach Support environment 1.1 Write processes/practices 1.2 Review processes/practices 1.3 Improve process/practices 2.1 Develop/update courseware 2.2 Conduct courses 3.1 Pilot processes/gather feedback 3.2 Provide support to projects 3.3 Deploy metrics/statistical controls 3.4 Perform statistical analysis 4.1 Conduct periodic assessments 5.1 Promote results 5.2 Publish newsletter, articles, and so on 6.1 Establish web site 6.2 Establish process asset library

65 Copyright RCI, 200565 Process Group Budget = $2.4M/year Process development –4 employees ($700K) Education & training –2 part-timers ($200K) –$250K for seminars Process roll-out/project support –2 consultants ($450K) –Retirees with credibility Process assessment –$200K for outside facilitator Promotion and outreach –$250K to prepare news- letter, work with clients and attend conferences Support environment –$350K for web site development

66 Copyright RCI, 200566 Proposed Operational Concepts Process development Transition Deployment CM QA Distribution management User support Exploit industry experience by hiring outside assessment firm Pilot to demo feasibility, do things middle managers think important E&T JIT; dedicated project liaisons Steering group CCB; shared/reused assets distinction Use process to assure processes Access via web site FAQ; metrics; dedicated support for users

67 Copyright RCI, 200567 Your Justification Approach Justify process budget by: –Showing the impact of accelerating productivity improvement from 10% to 20% annually –Looking at impact of early error detection/correction –Assessing the impact of COTS usage strategy –Evaluating the impact of moving to an architecture-based reuse strategy Show intangibles as added value

68 Copyright RCI, 200568 Accelerating Productivity from 10 to 20 Percent Annually Conservative estimate of savings is $4 million/year

69 Copyright RCI, 200569 Productivity Versus Cost Cost and productivity are related, but are influenced by different factors To increase your productivity, you should address: –Staff skills/expertise, process maturity and tools To reduce cost, you should attack: –Overhead, scope of the job and efficiencies There are cases where improvements in your productivity result in increased costs

70 Copyright RCI, 200570 Early Error Detection/Correction Benefit of achieving Level 4 is a reduction in errors by a factor of between 20 and 25% –Majority caught early in requirements and design phases Cost avoidance associated with early defect removal is $20/defect For the 12 major programs in your firm, you compute cost avoidance is 1.2 million calculated as follows: (12 jobs/year)(10 defects 1 /KSLOC)(500KSLOC/job) = 60Kdefects/year (60K defects/year)($20/defect (avoidance)) = $1.2 million/year 1 As jobs enter test and evaluation; goal is 0.1 defect/KSLOC on delivery

71 Copyright RCI, 200571 Exploitation of COTS Benefits of enterprise-wide licensing can be substantial –At the corporate level, this includes major software packages like DBMS –At the project level, this includes software tools and specialized software like operating systems As part of your Level 4 initiative, you plan to put in a licensing process that allows you to lever your buying power and save $1 million/year

72 Copyright RCI, 200572 COTS Pluses and Minuses Cheaper; but does not come for free Available immediately Known quality (+ or -) Vendor responsible for evolution/maintenance –Don’t have to pay for it Can use critical staff resources elsewhere License costs can be high COTS products are not designed to plug & play Vendor behavior varies Performance often poor Vendor responsible for evolution/maintenance –Have no control over the product’s evolution Pluses Minuses

73 Copyright RCI, 200573 COTS Critical Success Factors Successful firms: –Make COTS-based system tradeoffs early –Try before they buy –Avoid modifying COTS at all costs –Reconcile products with their architectures –Emphasize use of standards and open interfaces –Understand that COTS doesn’t come for free –Plan to manage parts/technology obsolescence –Make the vendor a part of the team, whenever possible –Negotiate enterprise-wide licenses for COTS products –Influence future paths the vendor will take –Address the cultural and process issues

74 Copyright RCI, 200574 COTS Success Strategies Process –Merge COTS life cycle into your organizational framework –Make needed tradeoffs –Think both technical and business issues Products –Fit COTS components into product line strategies –Maintain open interfaces –Manage technology refresh People –Make COTS vendors a part of your team –Increase awareness of COTS experience –Provide workforce with structure and information Institutional –Improve purchasing and licensing processes –Maintain market watch –Capture past performance

75 Copyright RCI, 200575 Architecture-Based Reuse Architectures are the framework you use to pull your product lines together –They are domain-specific and standards-based –They encapsulate generality and variability They guide selection and use of high-leverage assets –The 20% responsible for 80% of the reuse They allow you to take full advantage of both COTS components and reusable assets –Cost to build for reuse must be factored into analysis –Benefits of reuse adhere to the 3 times rule

76 Copyright RCI, 200576 Three Views of an Architecture Technical Architecture - Information processing standards - Human-computer interface standards System Architecture - Components and topology - Networks and connectivity - Capacity/performance Operational Architecture - Information needs - User functions - Performance bounds

77 Copyright RCI, 200577 Radar Architecture Example Platform Posix kernelMulti-threading executive Activity Managers Measurement Functions Sensor Manager Libraries Mathematical libraries Inputs

78 Copyright RCI, 200578 Reuse-Based Development Paradigm Domain Analysis Domain Design Domain Model Asset Development Requirements Software Integration Operations & Analysis Development & Test Maintenance Software Reuse Library Architecture Project-specific deliverables Products for sale Scope Requirements Purchased products Domain Engineering Assets Applications Engineering

79 Copyright RCI, 200579 COCOMO II Reuse Model ESLOC = ASLOC [AA + AAF(1 + 0.02(SU)(UNFM))] AAF < 0.5 100 ESLOC = ASLOC [AA + AAF + (SU)(UNFM)] AAF > 0.5 100 Where: AAF = 0.4 (DM) + 0.3 (CM) + 0.3 (IM) SU = Software Understanding (zero when DM = 0 & CM = 0) UNFM = Programmer Unfamiliarity AA = Assessment and Assimilation ASLOC = Adapted SLOC ESLOC = Equivalent new SLOC

80 Copyright RCI, 200580 The Impact of Reuse Conservative estimate of savings is $10 million/year

81 Copyright RCI, 200581 Reuse Cost/Benefit Worksheet Non-Recurring Costs –Domain engineering - done on IR&D –Reusable assets - project funded –Infrastructure development - done by process group Recurring Costs (per year) –Architecture maintenance $200K –Asset maintenance 500K –Process updates 100K Tangible Benefits –Cost avoidance$10 million Intangible Benefits –Deliver 12 months earlier than the norm –10 times reduction in efforts at delivery –Architecture stable, proven and can be demonstrated to clients –Scheduling algorithms can be optimized and improved Total Costs$800KTotal Benefits $10 million

82 Copyright RCI, 200582 Strategy Yields Positive Returns Early Error Reduction Cost avoidance = $1.2M/year Increased customer satisfaction based on quality Exploitation of COTS Cost avoidance = $1M/year Improved maintenance and license leverage with vendors Productivity Improvement Cost avoidance = $4M/year Improved capabilities & capacity Systematic Reuse Cost avoidance = $10M/year Faster to market 10X quality Just starting – expect to reap benefits within 3 years Process can be built with reuse in mind

83 Copyright RCI, 200583 Return-On-Investment Is High Tangibles ROI = Annual Benefits Investment ROI = $6.2M $2.4M ROI > 250% per year Assumptions: cost avoidances on page 3 realized with exception of reuse which kicks in after we reach CMM level 4. Intangibles Better product quality Quicker to market Increased customer satisfaction Improved employee morale Responds directly to customer requirements

84 Copyright RCI, 200584 When Briefing Management - Always Ask For Help Reaching Level 4 will take 2 years assuming things go as planned The major challenge is to get those in the middle on our side (bonus is a good start) There are a number of operational challenges –Need help in staffing process group – getting requisitions through the system is tedious –Need help in licensing – buyer, legal and staff support Must keep the momentum moving

85 Copyright RCI, 200585 Case Study - Final Thoughts Process improvement is a good investment To get management support, a good action plan and solid business case is needed When justifying initiatives, cost avoidance is preferred to cost reduction When determining benefits, categorize them as tangibles and intangibles Be conservative, but make your case using the numbers to justify the investments

86 Copyright RCI, 200586 Final Points Before We Adjourn Numbers can be your ally when asking for money When asking for money, talk your management’s language not yours Don’t be casual about numbers, be precise To be successful, be perceived as successful

87 Copyright RCI, 200587 You Can Be Successful Change only if it makes good business sense Don’t become enamored with the technology Get everyone involved - but not too involved Focus changes on product developments Look to the future, not the past (sunk costs) Be patient and don’t reinvent the wheel Do the easy things first to establish credibility Be satisfied with a 90 percent solution The sum of many small successes is a big success Guidelines

88 Copyright RCI, 200588 Most Importantly – Talk and Think Like a Business-Person Talk like a business-person –Translate technical jargon into business goals Act as a business-person –Assess both the business and technical aspects of the proposal –Show your bosses you can run a business operation Be a business-person –Focus on the bottom-line using the numbers when you can to make decisions that are good for the firm

89 Copyright RCI, 200589 Lots of Available Web Resources

Download ppt "Copyright RCI, 20051 The Role of Business Case Analysis in Software Engineering Lecture #1 Based on Donald J. Reifer’s lecture Supannika Koolmanojwong."

Similar presentations

Ads by Google