Estimating Oracle eBS App Portfolio Size in 3 Months for 1/2 Cost of FP Counting
•Download as PPT, PDF•
1 like•748 views
Frank Vogelezang presented a method for estimating the functional size of 400 applications in an Oracle eBS portfolio in 3 months with limited resources. The method involved estimating sizes based on application characteristics rather than documentation, allowing for imprecise results within 30% deviation. This functional size estimation approach was 50% cheaper than a traditional function point analysis and allowed sizing the entire portfolio in 5,300 hours compared to over 10 person-years for a traditional count. The results provided a functional size of 316,720 function points across 363 applications to help manage and control the portfolio.
Recommended
More Related Content
Similar to Estimating Oracle eBS App Portfolio Size in 3 Months for 1/2 Cost of FP Counting
Similar to Estimating Oracle eBS App Portfolio Size in 3 Months for 1/2 Cost of FP Counting (20)
More from Frank Vogelezang
More from Frank Vogelezang (20)
Estimating Oracle eBS App Portfolio Size in 3 Months for 1/2 Cost of FP Counting
- 1. Frank Vogelezang Estimating the functional size of an application portfolio with Oracle eBS applications
- 2. The challenge • Determine the size of about 400 applications in the portfolio in very different development environments • July through September 3 months to deliver result • Regular FP-count would cost up to 7 person-Year of counting effort
- 3. The option of regular FP-Count • Regular FP-count would require > 23 full-time trained analysts > Detailed documentation available > Management pressure > Strong coordination attention > About 10 person-Year budget • Regular FP-count was considered to be too expensive and too risky
- 4. Functional size estimation • Based on application characteristics instead of functional documentation • Little FPA experience required but good application knowledge • Less precise: 30% deviation • Less expensive: 50% cheaper
- 5. The imprecision of size estimation • An approximation of functional size • Based on technical implementation • Translating apples to oranges
- 6. Is it bad to be imprecise? • Sizing technique should serve the purpose of the project > Manage and control the portfolio > Serve as a basis for outsourcing contract • Deviation of 30% is acceptable • Spending extra money on precision would be a waste of resources
- 7. A special challenge : Oracle eBS A package containing already built functionality that can be tailored to customer requirements 4993 Cool Convertible 4993 Cool Convertible
- 8. What functional size do I measure • All the functionality that is available out-of-the box • A subset of functionality that is predefined for my business • Only the functions that I have picked to support my process
- 9. The chosen approach • Size the functionality that is used • Size estimation method > Query the different elements > Manually count some elements • Verify the result with expectations > Review of queries and query results > Rules of thumb > Other size estimations (order of magnitude)
- 10. Query principles 1. Establish what Oracle eBS elements should be queried for each category 2. Establish what elements are used 3. Establish what elements are used by the functionality that we are interested in
- 11. Results for Oracle eBS • 4 applications • 103,490 function points • Size estimation > 225 hours > Counting speed: 460 fp/hr • Regular FP-Count: 2 person-Year
- 12. Results of the portfolio estimation • 363 applications in 421 estimates • 316,720 function points • 67 staff involved • 5,300 hours spent: > Training 200 hr > Size estimates 4,000 hr > Review 600 hr > Management 500 hr • Counting speed: 69 fp/hr
- 13. Summary • FP-Size can be estimated when there is no need for high precision counts • Packaged applications can be estimated as well • Size estimation is a cheaper and fast alternative for regular FP-Counts
- 14. Frank Vogelezang frank.vogelezang@sogeti.nl Twitter: @FrankVogelezang metrieken.sogeti.nl
Editor's Notes
- Sogeti Nederland B.V. I am metrics consultant for Sogeti in the Netherlands. My main consulting is in the area of functional size measurement and estimation. In this presentation I want to share some experiences of the size estimation of a portfolio with a large portion of Oracle eBS applications at the Ministry of agriculture, nature and food quality.
- The management of the Ministry had a dual purpose with the functional size measurement of this application. First – to have a rough measure to charge the cost of application maintenance to the application owners. Second – to have a basis for negotiating the outsourcing of the maintenance of parts of the application portfolio. The time for the actual size measurements was very short for such an undertaking. Regular FP-count would require a huge out-of-pocket investment. Sogeti Nederland B.V.
- To make the out-of-pocket investment pay off a number of requirements had to be fullfilled. The chance that they all could be fullfilled was considered very limited. Regular FP-count was considered to be too risky, so a different approach was chosen. Sogeti Nederland B.V.
- The approach of functional size estimation comes from the benchmarking domain where there is a frequent need to count or estimate large amounts of functionality in a short period. It uses the application characteristics as a basis, since functional application documentation is often not available, incomplete or not up-to-date. The Sogeti approach is to let the maintenance staff make the first size estimate and to have that estimate reviewed by an experienced analyst. Details of this approach can be found in the paper we wrote for this conference. The method is a trade-off between precision, speed and costs. Sogeti Nederland B.V.
- The imprecision of this technique stems from the fact that with this technique we try to approximate a functional size measurement as close as possible. But we use the technical implementation as a basis in which also a number of non-functional requirements has been implemented. We intend to use this method in combination with regular function point counts and we don’t want to compare apples and oranges. So what we do is transform all the apples into something that very closely resembles an orange. For those of you with a long IFPUG experience: we transform an IFPUG version 2 count to IFPUG version 4. Sogeti Nederland B.V.
- Some people don’t understand that I work with a technique like this, being a member of the NESMA counting practices committee and the COSMIC measurement practices committee. They say I should be a guardian of the true methods. What I always ask them is whether the methods serve us or do we serve the methods? I sincerely believe that you should first look at the purpose of the measurement and then select the appropriate technique. In this case, using a pure method would have been a wrong choice from this methodical point of view. Sogeti Nederland B.V.
- About a third of the portfolio consisted of Oracle eBS applications. Here the regular approach of counting tables, screens and reports does not work, so we had to come up with something different. To be able to do that you first have to realise what a packaged application like Oracle eBS is. It is like one of the newer LEGO models like this one. Especially in a man’s world a cool convertible sells. This is what you might a call a standard solution, made of the building blocks that are in the package. But with the same building blocks two other standard solutions with different functionality are possible: a big truck or a working mini loader. Still boys toys, but for someone with the right development skills other designs are possible with the same set of building blocks. Sogeti Nederland B.V.
- All three choices are valid, the purpose of the measurement determines what is the right answer. Sogeti Nederland B.V.
- For this project we were interested in the functionality that has to be maintained or outsourced so we determined the functional size of the functionality that is actually used. We decided to automate the larger part of the size estimation process because this was the easiest way to determine which building blocks were actually used. Some elements were counted manually because they were either limited in number or hard to query. The results were verified in a number of ways. Sogeti Nederland B.V.
- The content of the actual query partly depends on individual implementations, so I won’t bore you with the technical query formula’s but tell you something about the query principles. Oracle eBS has a large number of different types of components and we had to select the components that represented the requested application characteristic the best. From each element a huge number is available, but we had to select only those elements that were actively used. Some elements are used in the setup of functionality and not by the functionality itself. We had to filter the correct elements based on resposibilities and in some cases the date of the last change to the element. Sogeti Nederland B.V.
- In the paper 5 subapplications are presented. If you look at the application level there are 4 applications with a size of over 100,000 function points. The 225 hours to estimate the functional size are including the devise of the queries. For the eBS a gigantic production leap has been established Capers Jones could be proud of. As you may know he has recently brought out an updated paper in which he suggests that FPA will only gain acceptance if counting can be done much cheaper. Sogeti Nederland B.V.
- The results of the whole project show a smaller speed difference with regular counting. But still double the speed of regular FP-counts. Sogeti Nederland B.V.
- Sogeti Nederland B.V.