|
My overall approach is to be thorough, but not pedantic. My ideal is to follow processes and methodologies closely enough to insure accomplishment of the tasks, but not to be so rigid that the tools themselves get in the way by becoming goals in their own right.
Requirements Ultimately either an application has a user, whether human or another application. Use cases and storyboarding are ways to capture an application's basic requirements. Existing documentation and interviews add other requirements. Examination of requirements may reveal dependent or derived requirements. Once captured and expanded, requirements must be tracked - to insure that the design meets the requirements, and to check that when priorities change requirements change with them. You don't want the team to waste time on a derived requirement if its ancestor has been put on hold. There are tracking applications; they can be useful - and expensive. For most applications in which I'm involved, a spreadsheet is an adequate way of tracking requirements. Software design I mostly use object oriented design techniques, and try to adhere to suitable patterns. Occasionally I find that structured analysis/structured design is useful. Some problems are more amenable to OOD, some beg to be treated with SA/SD. Sometimes either approach can be made to work, but usually the OO approach is more natural. I generally find that the CRC approach, with some class diagrams and sequence diagrams provide enough of a visual framework to work with. Project planning and management What I've found most productive overall is some variation of Rational's Unified Software Development Process (USDP). This basically is a formalization of the 'waterfall' model, but instead of one waterfall, it decomposes development into a series of smaller specify-design-code-test steps which are executed iteratively.Agile development / extreme programming are basically this process carried out with less reliance on documentation and much more granular iterations. I believe the key in project planning is to keep a balance between no planning and too much planning. I've seen both extremes. Fail, that is. A project plan should be a guide, not an obsession. It also requires solid management buy-in, should be as realistic as practical, and checked and updated regularly. Usually team members have multiple responsibilities. This is one reason why project plans must be flexible, and managers must be ready to assess priorities. It's rare that a team member will not be pulled off task at some point in any project of substance. That may have an impact on the plan, or it may not - the impact has to be assessed, and possibly the plan - or the distracting task - changed at the discretion of management. Finally, at project's end, the project plan should be reviewed. It is an opportunity for the organization to learn to do better. |