Evolving the Development Process? 19
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."
Abstract to invarients (Score:2)
This won't be perfect, but it should fit within the amount of churn that youyr development model already accomodates.
absurd, isn't it? (Score:2)
Re:absurd, isn't it? (Score:1, Offtopic)
Design Reviews (Score:4, Insightful)
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.
Re:Design Reviews (Score:3, Insightful)
It sounds as if they are thinking of moving into the area of on-site support and integration while keeping the development effort going. It makes sense (to me) to have specialists in the code, and specialists in integration. Both departments can play off one another and improve the quality of the software as a byproduct of their interaction.
Also, having people in the field who are solely focused on solving immediate customer problems will gain quite a bit of insight into future products that might be profitable for the company to develop.
JMHO,
Dancin Santa
Re:Design Reviews (Score:2)
Re:Design Reviews (Score:2, Insightful)
I'm sure they've already got a few developers who trek out to customer sites to implement their current product. Why don't they simply build a team around these engineers and label them the "Product Integration" team. It would free them up from having to develop the product and let them focus on customer issues. Not only would this allow for quite a bit of specialization within the company, it would allow both divisions to grow independently of each other making it possible for the company to branch out into other profitable markets.
The benefits of having the separate teams is pretty clear. Better customer service, more forward-looking ideas, and more expertise among the engineers of each division are only a few of the ones that pop into my head straight away.
I'm sure there are a few engineers who are already interested in doing something besides crunching code all day long. Grab 10 or so of them and make them the Integration team. As these guys get better, the quality of their work and their implementation schedules will improve immensely.
IMHO, of course.
Dancin Santa
Re:Design Reviews (Score:1)
There aint no such thing.
Common error situation: they think they know the application domain, but they have no idea what the computer solution can and can't actually do within reasonable resources. They keep changing their mind, you keep changing the code, it never quite gets finished and it tangles into an unusable mess.
Your approach would by contrast play out like this: do lots of pretty drawings and requirements capture. Do lots of design. Get it set in stone, and send it to the coders. A while later they turn up with a finished product that does exactly what they were told to, and DOES NOT DO WHAT THE USERS NOW WANT.
Managers will simply not allow this to happen, they will come down on you with whips and enforce the first approach. They are not paying you to sit on your ass designing academic boondoggles.
The only viable REAL fix is: short repeated iterations that deliver a known fixed subset of real functionality (eg: "this iteration, build use cases 1, 2, and 3"). The iteration boundaries are frequent enough to cope with changed minds, and most importantly, YOU DO NOT END UP REDESIGNING NONWORKING CODE. This is the most important. If you redesign, you need unit tests there to show it worked before, it worked after, and everybody's happy. Not, compounding of bugs upon bugs.
Mythical Man Month (Score:2, Informative)
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
ideas (Score:1)
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.
XP (Score:4, Insightful)
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.
Re:XP (Score:1)
This all fits into the old saying:
How do you eat an elephant? One bite at a time.
Same thing with a big development effort. Split the effort up into small ediable bits and then run each of these through the entire process.