I am an Oracle Forms developer with 4 years of experience in developing applications using Oracle Forms & Reports (i.e. 10g Forms). Now, for the 1st time, I have been assigned to lead a project to build a Guest House Management System. My problem is that I have been asked to prepare a project plan and for that I have to give the time it takes to develop the forms and reports.
Problem is, I have no idea of how long each form and report is going to take. So, my questions to the experts who have lead teams to develop forms applications is, “How do you calculate the time it takes to complete a form and report”? How do you answer this question if you were leading the project (as technical lead) and your PM asked you this question? Do you do “Function Point Analysis”?
Problem is, you cannot say a form is low, medium or high in complexity just by looking at the screens since you can have a form with only 2 or 3 items, but has 100s of lines of PL/SQL code, in the form and in the DB (as stored procedures).
We have the System Design Document (SDS) with all the forms designed using MS Visio. So, the exact look of the form will be drawn using MS Visio diagrams. For each form, we also have the processing that should happen for each item, described in English. For example, if a form has a “process” button, we have what the processing should be, in pseudo code style English.
So, how do you get about this?? Are there any guidelines anybody can give us (because there are lots of other Forms developers who are facing this same problem)? Can we assume that it will take a fixed amount of time to create LOVs, alerts, windows, etc.???
What is the biggest problem is finding the time it takes to create a form or report?
Thanks in advance
There are no hard and fast rules on this and it always depends on factors unique to each project. I can share with you how I would do it, should my boss ask for such an estimate. I assume you already planned for the requirements gathering, design, testing and implementation and here only focus on estimating the development work of forms/reports.
Some other considerations: In my shop, the practice is to only use the forms programs as the front-end UI and keep complex processing in the database as PL/SQL stored procedures (functions, procedures, packages) rather than embedded into the forms and reports. It will make complex processing logic easier to test and modify. For one thing, not having to resort to using the forms debugger is already a plus.
....and then once somebody in the management stratosphere looks at the effort estimate and decides its too much and cuts it by half and tells you the good news later that he has already committed you to the slashed effort.
Hi, your baseline effort is not that clear. Can you please elaborate?
Are you saying that for each form you classify whether it is a simple, moderate, complex form depending on the number of tables the form uses?
i.e. simple: form uses 0-3 tables,
moderate: form uses 4-9 tables
complex: form uses 10 or more tables.
Same for reports and SPs??
This method is based on an assumption that on average the more tables are involved in a form/report, the complexity rises. Of course it isn't true 100% some simple screens will use dozens of tables and some complex screens will use just a single table. For a large system it is assumed it will average out - that is why it is an estimate, a method to get a ballpark figure quickly for a large system which you can then fine tune to get your final estimate. It works for me, whether it works for you only you can decide. Don't be afraid to adjust or come up with your own method if you feel it is closer to what is applicable for your project.
For a small system (or you have a lot of time), you can get closer to the effort required if you cost each form/report individually by evaluating the functionality required. There is no magic in this, just listing down the functionality required from each screen/report and asking yourself: how long would it take an average developer from my team to code this? What problems could occur (add more time)? New technologies nobody in the team has used before (add more time)? If you are looking for a magic formula that you can just plug in your requirements to get the numbers, I am afraid there is none.
In my experience it is nigh impossible to estimate software development effort accurately, especially for new systems - there are so many variables and exceptions that can affect the effort, and not under your control. The requirements may will change. The developers may leave. You may encounter an unexpected problem that costs a ton of effort to fix. Don't be afraid to err on the side of caution if you expect issues.