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."
This won't be perfect, but it should fit within the amount of churn that youyr development model already accomodates.
You could've hired me.
The ironic thing is that I am not Jewish.
You could've hired me.
And he may not actually be anti-semitic, just doing the only thing his tiny mind can think of to get attention.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
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.
If you haven't already, try reading The Mythical Man Month by Frederick P. Brooks, Jr.
It is (as far as I know) the book on project management. It's over 20 years old and it's certainly stood the test of time. It's written in a nice, readable form... and it's an interesting read to boot.
-Dan
www.unixpunx.org - unix, punks, technology
Why don't you want to have a separate integration department? It sounds quite reasonable to have one department that develops the product and another that interacts with customers.
A little departmental shifting shouldn't hurt too much. You wouldn't have to hire anyone, really, you could just use some engineers from the development team who are interested in something new.
Tell ya what, since you're so lame as to not even be able to hurl an appropriate racial or religeous slur at me (funny, since I do have a photo on my public website that identifies me racially), I'll insult myself for ya:
God-damned agnostic honkey foriegners hogging all the first posts in this place! There ought to be a law!
Feel better?
However, it doesnt address the requirements of systems integration where the requirements are ill-defined
To paraphrase your problem, the development process is well defined and works, but when you go to deploy the application you run into difficulties because of the integration environment. In my own experience, part of the requirement at the beginning should be to build a close replica of the systems the application will live on. As other have stated it is good to have people who go back and forth between development and integration, but there are other good reasons for that practice.
From the perspective of building a replica of the final deployment environment, it is good to have some one who has extensive experience with the clients setup, so that you catch more of the gotchas earlier during development and it allows you to make your dev environment as close as possible. It's unlikely you can build a mirror of the deployment environment, but there are steps you can take to simulate those conditions. I can only guess at what that environment from my own experience. Financial institutions tend to have a mix of mainframe and high end unix servers from either Sun/IBM/HP/Compaq. For obvious reasons, your company probably can't afford to build a mainframe that mirrors the final system, but most of the other stuff you should be able to replicate fairly closely.
All those little differences in hardware, network architecture, and configuration oddities can be minimized by making your development environment similar. Sure it makes your development life more painful, but you don't have to do it all in one shot. You can do it slowly in phases and work it in so doesn't screw up the process or productivity. As far as making sure the application is what the client wanted, you may want to consider altering the development to include building flow mockups that allow the client to physically go through the steps with canned data. This way you reduce the time spent building features that won't integrate smoothly with their existing applications. Some or all of these suggestions might not help at all in your situation. Hopefully there's something you can use from other's suggestions.
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.
And what if you were? Would you take that mentally impaired child seriously?