Shared-Risk Pricing for Custom Software Development

In any custom software development project, there are well-known risks:

  • The scope may be underestimated at the start.
  • The scope may increase over time (not always a bad thing – often a client discovers that additional functionality would deliver additional business value).
  • The development firm may be unable to deliver any working solution at all.
  • The project may take more time than anticipated.
  • The project may take less time than anticipated.

In a time-and-materials pricing model, the client takes most of the risk, and this is generally accepted because the client will receive most of the benefits of a successful project. Many development firms (including many very good ones) only offer time-and-materials pricing.

They do this because of the problems with the other extreme – fixed-price contracts in which an attempt is made to fully describe the software project in advance, then specify a fixed price to build it. In this model, the development firm takes most of the risk, with some unfortunate side effects:

  1. The development firm is strongly motivated to interpret software requirement as narrowly as possible, rather than in a way which maximizes the business value of the software.
  2. The development firm and its client can end up in an adversarial relationship.
  3. Arriving at a project specification and price can be very expensive and time consuming, so much so that this model is often infeasible.
  4. It can result in an overly conservative approach to software development, estimation, and design. The client might be quoted a price which covers the highest amount of time than anyone can imagine the project taking, when then becomes a self-fulfilling prophecy.

However, a key merit in the development firm taking on some of the risk, is that the development firm is in a position to affect the outcome. This suggests a compromise.

One possible compromise between these two extremes is referred to here as Shared-Risk Pricing. It works like so: a small set of core software requirements is developed for a fixed price, then the remainder of the project is billed on a time-and-materials basis. That core set of requirement is intended to demonstrate that the developers can deliver working software, encompass the efforts needed to set up development environments, ensure familiarity with tools, and show progress on any unusual/key features of the software.

The client accepts some risks: The development firm accepts others:
Scope creep risk. Risk that the firm will be unable to deliver a working solution.
Risk that the work will go faster than expected getting basic features working. Risk that the firm will spend more time than expected getting basic features working.
Some of the risk of the project taking longer then expected. Some of the risk of the project taking longer then expected.

As we start out, Oasis Digital will perform most work on an hourly / T&M basis, while looking for projects where the shared-risk model fit.

 

Grid Components for Delphi

This list of Grid components available for Delphi. is originally from a Usenet post by Anthony Richardson (anthony_r at sageautomation.com). I’ve added more since then.

The following is a list of Third-Party Grid suppliers:

SpreadSheets:

TAdvSpreadGrid – http://www.tmssoftware.com/
TSpread – http://www.jt.w1.com/products.htm
TSpreadSheet – http://www.uniyar.ac.ru/~dimak/delphi/spread.shtml
THyperSpreadsheet – http://www.pablop.demon.co.uk/

Non-DataAware:

InfoPower – http://www.woll2woll.com/infopower/
Top Grid – http://www.objectsight.com/
TAdvStringGrid – http://www.tmssoftware.com/
TStringAlignGrid – http://www.hoerstemeier.com/
(Free)
TSMTableGrid – http://www.sunsoft.ru/
THyperGrid – http://www.pablop.demon.co.uk/
TCoolStringGrid – http://www.cooldev.com

Data Aware:

TDBAdvStringGrid – http://www.tmssoftware.com/
QuantumGrid – http://www.devexpress.com/
InfoPower – http://www.woll2woll.com/infopower/
TOPAZ – http://www.softsci.com/topazd.htm
Top Grid – http://www.objectsight.com/
DbAltGrid – http://www.dbaltgrid.com/
TIB_Grid – http://www.ibobjects.com/
TDBGridPro – http://vipper.downloadit.gr/
TSMDBTableGrid – http://www.sunsoft.ru/
X-DBGrid – http://republika.pl/kszyszka/x-files.html
TExDBGrid – http://www.gjl-software.co.uk/
TVizDbGrid – http://www.vizacc.com/i_prod_gexpert.php

Grid Print Engines:

PrintDAT – http://www.grebarsys.com/
ExpressPrinting System – http://www.devexpress.com/
My (Kyle’s) own grid print engine, developed just before these started coming out.

Header Footer Add-ons:

DbHdrCtrlGrid – http://www.dbaltgrid.com/
TSDBGridFooter – http://www.sedlan.com

Specialist Grids:

TIB_Ledger – http://www.ibobjects.com/

Delphi Resources

Pure Technologies offer open-source PureSOAP, which looks like a good way to use SOAP from Delphi, without require the Enterprise edition of Delphi 6. Another good approach for this is to use Microsoft’s SOAP support (ROPE, etc.) via COM.

DUnit is a Delphi version of the “xUnit” familt of unit test tools popularized by Extreme Programming adherents. I’ve found it quite useful even on projects that have nothing to do with XP. I tend to be skeptical of any significant body of code for which there is not a test suite.

Around the same time you automate your testing with DUnit, take a look at FinalBuilder for automating your build process in Delphi and other Windows IDE-based tools like help systems, installation systems, etc. I haven’t tried it myself yet it looks quite appealing.

Since the Kylix annoucement and arrival, there seems to be an abudance of people eager to use Delphi with non-Microsoft technolgoies, and I am pleased to see Delphi expand into the Linux world. We shouldn’t forget, though, that Delphi is superb for developing software using Microsoft technologies. For example, I have heard of companies doing all of their “heavy lifting” in COM objects written in Delphi, while using VB or ASP to put together overall applications. For more on Delphi with Microsoft technologies, see MSDelphi.com.

Windows Clients, Java Servers

Problem / Scenario:

You have server code in Java implementing business logic, or you want to have such code. Java is your strategic choice.

But… you have a need for a client application that will be a native Windows application, for whatever reason. Sample reasons: (1) they need to run quickly and smoothly on a factory floor full of Pentium 150 or slower machines with limited RAM. (2) they need to work in disconnected mode, or talk to local hardware, so a web application won’t work.

How do you write server code in Java (in EJBs, for example) but access it easily from a native Windows clients, for example a Delphi application?

Possible Solutions:

Solution #1: Talk JRMP from Delphi

Implement the Java RMI JRMP protocol in Delphi. This will be nearly impossible, since it is built on Java object serialization. So there are various approaches you could take.

Solution #2: Java on the Client, use JNI

Run Java on the client as well, and use JNI to communicate between Delphi and Java, then Java to do the client side RMI. This defeated the goal of keeping the client lean, though… a Delphi thin client can run well on an old, slow machine with 32 meg of RAM, Java can’t.

Solution #3: RMI-IIOP / CORBA

Some Java application servers can seamlessly (?) expose Java services (like EJBs) as CORBA objects. Borland has CORBA support available for Delphi. This will avoid the overhead of Java on the client, but is too vendor-specific for my tastes.

Solution #4: Your own Proxy on the server

Use a non-RMI way to communicate between the Delphi client and an extra "tier" at the server; this piece of middleware would communicate with Delphi using any of a number of methods, including DCOM. Then use JNI or other means to access the Java services on the same (server) machine.

Solution #5: ASTA-Java

ASTA has a product (though I don’t know if it’s in development, or ready to go) that provide an generic mechanism for invoking EJB operations, from a Delphi client. The challenge here is how to send and receive complex types, which are defined by Java classes.

Solution #6: Web Services with SOAP

Expose the server-side services as web services via SOAP. Choose an application server which will automatically expose your EJBs this way, if possible. Then use any available way to make a Delphi client talk SOAP. PureSOAP and Microsoft’s SOAP support are two possible ways. (This is really the most appealing choice to me, as of 2001.)

Solution #7: Homegrown web services

It’s really not all that hard to write wrapper code that exposes your server services via HTTP requests with parameters, via XML strings, etc. Such a thing would not be language specific, so the server could be on one language, the client in another. This solution has some appeal in cases where you want the pieces to be tightly "wrapped up" and not exposes in anything as standard as SOAP for some reason.

 

There many, many paths to use to get from point A to point B… if you have a different scenariou in mind, tell me about it and I will try to expand this page to cover it.

Need to do this for your own project? Consulting services are available.