Process Review
Process Review
Software Development Life Cycle
In every situation where a business requirement is converted to a software solution there will be a set of controls to manage each stage of the process. In virtually all of those cases there will be scope for improvement and refinement that can potentially offer quicker, cheaper and/or higher quality deliverables.
The intention is to identify opportunities for improvement and create a realistic plan for their implementation.
"Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning."
Albert Einstein
The Software Development Life Cycle rarely benefits from having a rigid set of rules and processes that impose a static set of controls and restrictions on the way that developers work.
There are areas where standards and consistency are important but the overall process will ideally be a support, rather than a constraint, and will include enough flexibility to allow it to evolve with the needs of all users.
One of the ironies of many implementations of Agile based solutions is that they rigidly follow a prescribed set of rules when Agile itself strongly promotes flexibility. Equally, a common fallacy of Waterfall development is that it's rigid and unchanging. In either case you decide how you want your processes to work and the only limit is your appetite for change.
"You can mass-produce hardware; you cannot mass-produce software; you cannot mass-produce the human mind."
Michio Kaku
The processes that you implement, and the way that you implement them, should be heavily influenced by the actual humans involved in your software development. Failing to factor this in can demotivate staff and lead to reduced productivity.
What you end up with should be as unique as the individuals themselves and capable of growing in the same way that they do.
Some approaches will advocate a more vertically integrated team structure, with developers, testers, users and business people freely communicating. The downside of this is that it can lead to more insular teams with less communication between developers on separate teams. There's a need to take a more holistic view in these cases to ensure ongoing knowledge transfer and maintain a consistent application architecture.
"Walking on water and developing software from a specification are easy if both are frozen."
Edward V Berard
The key to defining an effective process for managing the software development life cycle is compromise. From a purely academic perspective it can appear that a constantly flowing and iterative requirement definition process will lead to an improved software deliverable.
The counterpoint to this is that good developers will create a design based on the initial requirement and start to code based on that. A dramatic change in requirements mid way through can compromise development, leading to either badly structured code or a delay in delivery.
The reality is that the early crystallisation of requirements should be encouraged, but there should be scope for further refinement and qualification. The level to which this is needed will differ from site to site and project to project. A purely commercial restructuring of a visual customer interface may need regular revision whilst a statutory change for a purely back-end transaction will likely need no further review at all.
"The best way to get a project done faster is to start sooner."
Jim Highsmith
There's much talk of the need to get code changes completed quickly due to the pressures of modern, dynamic business environments. This can be true but won't apply to every project. The key here is to have a flexible schedule that can change priorities as required without compromising the overall development effort.
The morale here is to think better rather than work faster. Rather than speed we need to think of timeliness so that we can get what we want when we need it rather than trying to get everything right now.
