On Thu, 2005-10-13 at 12:30 -0500, Mark Dalton wrote: > > CPRS would take too long for me alone to do in my spare time. (rarely > available) :) > Also I don't have/use Delphi, which is not standard in the HPC world > but then neither > is Java (yet). > > I was curious how much it would cost to have a company convert CPRS to > Java for us. It would be a 'off-shore' > > Since there are about 300 .pas files and more than 200 delphi forms, > they > estimated: > > Approximately, it requires about 6 months to complete the > transition. By applying our minimal rate, $20/hour, it will > cost: $20.400 = 6 months * 170 hours * $20 > > Or on a relaxed schedule to complete in 8-9 months they estimate > $18K. >
That is brutally optimistic. If I attempt to get the number of lines in just the .pas files (I know, relatively meaningless, but in all a generally good metric for how unbelievably huge this app really is), I get the following: [EMAIL PROTECTED] find . -name '*.pas' | xargs cat | wc -l 188574 And a sloccount returns: Total Physical Source Lines of Code (SLOC) = 165,989 Development Effort Estimate, Person-Years (Person-Months) = 42.87 (514.39) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 2.23 (26.81) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 19.19 Total Estimated Cost to Develop = $ 5,790,618 (average salary = $56,286/year, overhead = 2.40). Now, I dont know that I put a ton of faith into sloccount's numbers other than the physical source lines (which is accurate, doesnt include whitespace, and comments, etc). Without any regard to the sheer size of this application, porting it is basically an exercise in insanity. I am well aware of this, because at work, this is what we are doing, and we have been doing it for about the last 8 or so months. We are nearing a relative completion point with cprs functionality (some gaps we will not be filling immediately include some of the options dialog, etc), however, it has not been an easy task. Just getting a VistA environment setup that can *test* CPRS is not trivial, and to get actually useful testing with multiple user types, many different patients (as different pieces of the patient information cause CPRS to behave wildly different, like, inpatient or outpatient, or plenty of other things) is absolutely difficult. My experience has been generally one of "Holy crap, CPRS does what?!" I would expect some horribly nasty cost overruns on a project that involved tasking (what seems to be) 4 Indian developers with 6 months to work with a task something that a larger team at the VA (that has easier access to testing, and QA facilities) has been working on for 10+ years. So yeah, I'd say not for the faint of heart. --Todd ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
