1 / 23

Application Development in the Business Environment David Cohen sente

Application Development in the Business Environment David Cohen sente Institute of Computing Technology Chinese Academy of Sciences Beijing October 2001. Introduction to sente. sente means competitive initiative in the game “Go” Our focus is on productivity

naeva
Download Presentation

Application Development in the Business Environment David Cohen sente

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application Development in the Business Environment David Cohen sente Institute of Computing Technology Chinese Academy of Sciences Beijing October 2001

  2. Introduction tosente • sentemeans competitive initiative in the game “Go” • Our focus is on productivity • enhancements through Faster: • • delivery of customer solutions • • delivery of information to users • • implementation of organizational changes

  3. Solution Examples

  4. Software Business Insights • • Must develop new areas of expertise at an ever increasing rate • - Opportunities to contribute directly tied to insight • • Three observations Software Pollution Effective Methods to Reduce Pollution The Value of the Pollution Fighter

  5. Features Built 100% - 90% Features Deployed 10% Level 1 - Software Manufacturing Process - 20% Features Bought 8% - 80% Level 2 - Feature Utilization Process 1.6% Features Used (N) - 13% 1.4% Features Used (1) Software PollutionTM (1/3)Feature Manufacturing and Utilization Analysis • • Software scrap • • Pollution levels • - Project size and complexity • - Project schedule • - Development team • Typically less than 20% • Pollution higher in regulated businesses

  6. Features Built 100% Features Deployed - 90% 10% Level 1 - Software Manufacturing Process - 20% Features Bought 8% - 80% 1.6% Features Used (N) Level 2 - Feature Utilization Process - 13% 1.4% Features Used (1) Software PollutionTM (2/3) Feature Manufacturing and Utilization Analysis • IncompleteRequirements that • do not capture customer needs • Customer knowledge is evolving • during the program • Development Team likes • long delivery programs • Development Team uses • “bleeding edge” technology • Users’ ability to absorb • features is limited • Features do not fit into • any useful process • Late delivered features, • no longer needed

  7. Software PollutionTM (3/3)Pollution Sources and Combat Strategies • 1. System engineering cannot capture and effectively transfer the customer need to the development organization • The human barrier for information transfer • Requirements capture less than 20 percent of the capabilities that end up in the product • 2. Lack of sufficient input • Requirements need to be validated before they are implemented; customer knowledge is evolving during the specification process • Need a faster - cost effective process to facilitate the learning • 3. The development organization attempts to implement a system capable of supporting a large customer base in a long, single step which is irrelevant to the business • The market/customer needs evolved well beyond the requirements • 4. The development organization attempts utilization of “bleeding-edge” technology • Unknowingly, the project turns into a job training program • The primary objective is to deliver a solution and NOT to champion technology

  8. Person B Knowledge Person A Knowledge Information Exchange Introduces Software Pollution IEX A B • Effectiveness of the information exchange is directly related to the shared knowledge • Shared knowledge is measured by the distance between Person A and Person B Shared Knowledge

  9. The Distance Level Between Two Persons • 1. Age • - Gender, Family Status • 2. Education • - Degree, Specialty • 3. Work Experience • - Military, Business Function, Size of Organization • 4. Physical Distance • - Building, City, Country • - Time Zones • - Organization (shared mgmt. level) • 5. Cultural • - Ethnic Background, Born U.S., Religion • 6. Hobbies, Sports, Special Interests • - Gardening, Stamp Collecting, Chess, Tennis, Golf

  10. 1. Name Nickname Title 2. Home Address/Community 3. Birth Date and Place Hometown 4. Height/Weight 5. High School and Year Graduated College Graduated/Degrees 6. College Honors Advanced Degrees 7. College Fraternity or Sorority Sports 8. Military Service Discharge Rank 9. Marital Status Spouse's Name Spouse's Education 10. Children, if any, Names and Ages Personal Attributes (1/2)

  11. 11. Children's Education 12. Children's Interests (hobbies, problems, etc.) 13. Previous Employment: (most recent first) Company Location 14. Membership in Professional Trade Associations 15. What is His/Her Immediate Business Objective 16. Favorite Places for Lunch Dinner 17. Favorite Items on Menu 18. Hobbies and Recreational Interests 19. Vacation Habits 20. Sports Interests (teams) Personal Attributes (2/2)

  12. 10 Relative Value of Contribution 4 2 1 Code Solution Revenue Profit Individual Delivers Business Decision Analysis The Value of the Pollution Fighter

  13. Define the Test so Everybody Gets an “A”Business Development Model Business Decision Analysis New SVC Proto- type Trial LIMITED Deployment Wide Deployment Niche Market Idea Prototype SVC Revenue Growth Prototype Trial LDEP WDEP Idea Success Criteria Sales Process - Invest, Participate

  14. SVC Service N P T LDEP WDEP Distribution Channel DC 50 500 5000 Operations Support OS Business Decision Analysis Concurrent Evolution of CapabilitiesService, Distribution Channel and Operations

  15. Existing Software Development Process Y Continue Investment N ROI Good Y N Software Investment (1/3) The Requirement Driven Paradigm Fails to Deliver ROI Business Needs Transformed into Requirements RequirementsBy Release The Problem is Here • Requirements Track Record: • Incomplete, Inaccurate, Incorrect • Ad Hoc Validation • 5 - 8%of Program Cost Meets Need Y Programs Cancelled Before Deployment N • More Releases (e.g., 6months; $5M) • Architecture, User Interface, BRs, Processes, Reports, Flow-Through, and Training • Unstable Operations • More Time and Investments • Never Meets Objectives 1st Time • Over 90% of Investment We Try to Fix It Here Most Programs Fail to Deliver ROI Because Business Irrelevance It Takes Too Long to Get It Right

  16. Y Continue Investment N Needs Met? Y ROI Good N Y N Software Investment (2/3)Improve Requirements Quality through Validation Business Needs Transformed into Requirements Requirements By Release Requirements Validation Process Attack Problem at the Source Validated Requirements • Provide Toolkit to Planners: • Validate Relevance, Accuracy, Correctness, Completeness • Confirm Usability and Productivity • Maintain Faster Cycle Time • 10 times faster and, • 10 times cheaper • Expand Validation Coverage in Line with Need Existing Software Development Process Relevant to the Business First Time Reduces the Demand for Enhancements Slow Irrelevant Late

  17. Business Needs Validation Development Software Investment (3/3)Supports Validation Capabilities in Six Key Areas Architecture Configuration Management Web Based UI Business Rules eccmToolkit Release V.24 Operational Processes Center Productivity Management The Electronic Customer Contact Management(eccm) Toolkit Delivers Cost Effectively Validated Requirements

  18. 10 Business Needs Transformed into Requirements Requirements By Release Requirements Validation Process Attack Problem at the Source 4 Y Validated Requirements Continue Investment 2 1 Existing Software Development Process N Needs Met? Y ROI Good N Y N Code Solution Revenue Profit Relevant to the Business First Time Reduces Need for Enhancements SummaryImprove Applications’ Quality and ROI through Validation Better Application Solutions Through Requirements Validation

  19. Backup Slides Backup Slides

  20. Code Reuse

  21. Evolution of a Service :-D

  22. August 1982 April 1997 Re-engineering Project Definition A re-engineering project attempts to replace an existing mature system with one or more systems • Starting the “RACE” with • Better Technology • 10-15 Years Later • must have all old system features • and, all new promised features

  23. Re-engineering ProjectsSuccessful Alternatives Re-engineering Projects have Four Possible Outcomes: 1. The new project is stopped • survive with the old system • will try again in a couple of years 2. Deploy within 6-12 months a pilot using an existing product 3. Deploy within one year a new system • supports only subset of features • software pollution based guidance • reuse toolkit functionality 4. Build adjuncts to the old system • migrate old system functions incrementally

More Related