Slashdot Mirror
Evolving the Development Process?
cabbage queries: "I
just joined a medium sized firm with a development
department of approx. 250 people. They primary product
is a client-server based solution delivering realtime
market data to the desktop in large financial institutions.
They currently use SCO Unix for the servers, but a move to
Red Hat Linux is definately in the cards. But this isn't
the only change thats happening: they are also considering
integrating their data with the client's enterprise delivery
systems, and proprietary applcations.
Currently they use a 'pragmatic' version of the Unified
Process utilizing UML. The process is well organized and
reasonably well documents and seems to serve well as a
development process. However, it doesnt address the
requirements of systems integration where the requirements
are ill-defined, require extensive R&D, may only be tested
on site, and may not be complete until the client
determines that the solution does what they thought they
wanted.
Do any slashdotters have any suggestion as to how to move
from a well organized application development process to
one that addresses systems integration without destroying
the application development process. We really don't want to
set up a seperate department if at all possible."
However, it doesnt address the requirements of systems integration where the requirements are ill-defined, require extensive R&D, may only be tested on site, and may not be complete until the client determines that the solution does what they thought they wanted.
Unfortunately, if you can't eliminate that last bit (until the client determines that the solution does what they thought they wanted) then, to put it nicely, you're pretty much going to be stuck in an endless "stepwise refinement" process. Making changes to a mostly-complete application can be a nightmare; the key thing here is to do all of the "stepwise refinement" in the design phase, before you start doing any coding.
This is just Software Engineering 101. If you don't want projects to turn into a death march, you have to get firm requirements. Then you design your solution, and have design reviews with the client until both of you are satisfied that what you are designing is what they will want. Do not start coding anything until you've reached that point. Prototyping is fine, but starting to build a project before the client has signed off on the final design is a great way to shoot yourself in the foot.
The "extensive R&D" part and the "testing on site" part are just more work, that's life. But you have to get a commitment from clients that what you are building for them is what they need, and that once they've signed off on the design, change orders are going to be very expensive. If you know what you're building ahead of time, and the client knows what they're getting, you are going to have a lot fewer problems.
Instead of waiting for large releases to do integration testing or customer approval, you can "tighten the loop" and do faster iterations with the process you already have.
Once you have your use cases and UML and everything, then pick a couple of basic features and build them fast and release them (Don't forget to write automated tests). That way you get customer feedback and integration testing practice quickly and can fix things bit by bit instead of having to gut your system to add a trivial feature later in the process.
I have found the XP principles of rapid iteration and continuous integration to be life savers regardless of what other methodologies are being used.