OK, your project turns out to be one of the 25% or less that will need to build new software because nothing exists that you can re-use or buy.
5) Once a decision to build is recommended and accepted, detailed requirements must be defined to the level necessary to design and develop the system…and then design, development, testing and implementation follow.
As a concept, “Requirements” often seem to be the whipping-boy of the analysts or latest guru. The debate is not about Requirements as a ‘concept’ — everyone agrees you need to know what is supposed developed! — its about what is the best way to do it in such a way as to ensure that the delivered software does do what the business needs. Projects delivering software that doesn’t do what the business needs is still a common enough occurrence that a wide range of methods are being used in attempt to solve this problem. This range is usually described as veering from formal, detailed analysis and documentation, all the way to the most intense forms of Agile methods. I believe there are also other axes of interest in play, notably code-generation from models, including older CASE tools or newer MDA approaches using UML.
In step (5) above, I do not lightly combine “design, development, testing and implementation” into one phrase; here is where the hard work gets done, where teams of multiple people/roles are involved. As I have proposed above, such a team at a typical company will be made up of specialists doing the various types of work, with a project manager to guide and control the work. This is where most IT methodologies (like RUP ) provide the most detail and direction, and I do not intend to replicate that here or even recommend any one methodology; my only advice is use one that works for your company, and use it for a long time to maximize the return on your investment in that methodology; jumping from the latest hot thing to the next just costs too much in terms the change effort needed and the impact on your efforts.
Given all that, I do believe its been clear for a long time that building things in pieces and sticking them together is the way to develop systems; consider the idea of high Cohesion and low Coupling in the original Structured Analysis and Design methodologies. Actually doing it so that these pieces of software, components being the most common name, can be re-used later on when constructing/assembling a new system, that’s been harder to accomplish. Object-Oriented approaches were very big on this in ‘90s.
Can it be done? Is it being done? Object-Oriented was to deliver re-usable components, but the industry veered away from this goal as we moved from a CUA view of software to a web, browser-based view of systems. What the dozens of industry emails I get do tell me is that the new basis of re-use is Service-Oriented Architecture (SOA); instead of assembling software components into one whole system, you build a front-end (façade?) that invokes existing services, internal or external to your company. The services expose a public data interface and a description of its functions; you provide the data it requires, you get a result back. The travel industry was one of the first into external services, allowing systems to query different services in searches for flights, hotels and such that meet the provided criteria.
6) After the software is implemented, the original project is complete but the life of the software has just begun. Requests will be made to change or extend the system, and it may prove to have problems that are discovered after it has been in use for a period of time. This collection of changes and problems will likely lead to the initiation of that most common of IT projects, the Enhancement Release.
So, we have seen that many activities and steps in an IT project involve only one or two people, mainly the Business Analyst and sometimes a Project Manager.
Next time: let us consider what to do when multiple specialists work together.
