I’ve been writing software for a number of years now, most of my experience has involved developing for large corporate and government entities. In each of the positions that I have been employed I have grown to expect different answers to the question: “what software engineering strategies do you adopt?“.
Experience has taught me that each of the project managers that I have worked under have a different idea of what software engineering is and how it supposed to work. Most development managers have read a text book or two and understand the basics of different development methodologies and design models. Many of them know the buzz words – UML, Waterfall, Spiral, XP (paired programming), Rational etc. However, I’ve yet to work for a PM who follows any one of the different methodologies closely enough to make it work well. Sure, I’ve been told that we’re using waterfall and modeling in UML or a subset of CMM, and I’ve then been given a copy of several documents written to backup the claim, but when it comes to practicing what is preached the software engineering principles are thrown out of the window in favor of vague requirements and general ad-hoc development.
Let’s take a project I once worked on – a number of developers on my team and myself had been set on the task of replacing a legacy system. The legacy system was large, had very little documentation accompanying it and the original developers of the system had long gone. The legacy system was being used exclusively in day-to-day business, but had to be replaced because of it’s unfriendly interface and aging use of technology. I was told that the requirements for the new system were to be delivered sometime soon by a group of business analysts who had been busy with requirements gathering. Meanwhile my team and I had to replace components of the legacy system by analyzing thousands of lines of code, having never seen the legacy system in action and without the requirements. Does anyone else see the problem? Without seeing the legacy system working, no technical documentation describing it, or any requirements for the replacement, the team was left out in limbo wondering what they needed to develop.
So, what should a developer expect from a project manager before embarking on and during the development of a well structured software engineering project?
- A brief – a good description of the problem goes a long way. Simply, a brief tells the developer what the software should system should do from a high level perspective.
- Documentation about existing practices and legacy systems – a developer should be able to satisfy the needs of the user by implementing everything that the old system did. The requirements document should indicate additional features, changed features and dropped features in the new system.
- Concise Requirements – Requirements for a software project consisting of more than one developer and more than 40 hours of work should not fit on one page of letter sized paper (no matter how small the font). A good requirements document will break down the proposed solution into manageable sections, each section containing explicit usability details with a breakdown of the user interface and features, screen shots, special cases and considerations to be met by the developer. The requirements document is a contract for the software, if a feature is not listed clearly in the requirements document without ambiguity then the developer will unlikely implement it.
- A list of milestones if the project is large and cannot be completed in one development cycle.
- A road map or WBS (Work Breakdown Schedule) – Some idea of how much time is allotted to the development of each milestone, typically represented as a Gantt chart in MS Project.
- Test plans – the QA people should be busy coming up with a proposed plan on how they plan to test the finished product. Sometimes the test plan can resolve developer ambiguity, if a test plan can illustrate how an aspect of the software is supposed to work then the developer can code to the QA guidelines. When following the XP methodology the test plans should be completed before implementation begins.
- A deployment plan – if the developers responsible for deploying the software and any form of migration is required, then a documented plan is required.
- Continued update and how the project is evolving should be documented. Previously written documents should be updated to reflect the current state of the project.
- A conclusion document – Documenting problems during development, concluding findings and suggestions for future changes will assist the maintenance team in later project life cycles.