Software Development Process
|
There are a large number of different software development processes, methods, and approaches. In recent years, the so-called agile processes have challenged the long initial analysis, and design phases of more traditional processes that produce large, detailed, beautifully formatted, requirements, analysis and design specification documents. Agile processes seek to minimize wasted effort especially early in a project, and better absorb the inevitable changes in requirements as they happen. They aim to do this without compromising the quality of the software produced or the ability to maintain it. Agile processes subscribe to a set of values and principles defined in the agile manifesto established in 2001. Over the years I have worked with all kinds of software development processes including, traditional waterfall, incremental waterfall, use case driven, RUP-like,Feature-Driven Development, eXtreme Programming, and Scrum. My personal favourite to date is Feature-Driven Development. Having said that, I firmly believe that assigning the right people to a project is far more important than the particular process used. More about People and Process... So, given a good team of people, what makes for a good process? The following mission statement for a process is adapted from brainstorming session in a meeting room of the Courtyard Marriott, Raleigh, NC, USA in 2000 with Jeff De Luca and Peter Coad: A good software development process enables and enforces the repeatable delivery of quality, working software in a timely and cost-effective manner, supplying accurate and meaningful information to all key roles inside and outside a project while imposing the minimum of administrative overhead on the development team members. When a process emphasizes only enforcement, it stifles creativity and innovation and causes frustration among developers. Conversely, when a process emphasizes only enabling, and creativity and innovation are not channeled to useful areas, then individual team members simply do as they think best. This can mean results do not integrate, or the software does not truly reflect the client's requirements, or the quality of the software is inconsistent. This can be highly frustrating for team leads and managers. A good process must balance enablement with enforcement. A good process also helps deliver high quality, working software in a timely and cost-effective manner. In the final assessment, repeated delivery of large Microsoft Word documents or PowerPoint slideshows describing the software being built is not what counts. Neither is repeated delivery of demonstration-only quality versions of the software. Even repeated delivery of software that is ready for production is not enough. If executing the process takes too long, costs too much, or delivers poor quality software, repeated delivery is of limited benefit. Of course, knowing what is meant by and when something is 'too long', 'too costly', or 'poor quality' is information needed by a development team's leadership and managers. To be able to intelligently steer a development team, its various levels of leadership need to know the status and progress of the development. If the appropriate information is not readily available when needed, is inaccurate, or is at the wrong level of detail, then the team's leadership may not be able to make appropriate decisions, or worse, may be persuaded to make inappropriate decisions about the development's future. More about Progress Reporting... Progress information is of importance to the headership of a development but other information needs to be available to other people on the team. Clarification of requirements, design decisions, coding standards and conventions, environment settings, etc, all need to be communicated effectively. A good process, therefore, supplys accurate and meaningful information to all key roles inside and outside a project. However, if supplying this information takes up large amounts of each team members' time then 'following the process' frequently becomes too expensive and team members are tempted to take short cuts undermining the quality of the information communicated. Therefore, the process needs to supply accurate and meaningful information to all key roles while imposing the minimum of administrative overhead on the development team members. Finally, to maintain its effectiveness, any process needs to be monitored, reviewed and modified when necessary to maintain its value to the organization. |
Complexity, Communication & QualityDeveloping software, like any other problem solving discipline, is essentially about:
What makes developing modern software systems so difficult is firstly the inherent complexity of the problems being addressed and the technical solutions required to solve them. Secondly, there is the communication required between people from different backgrounds and disciplines. Thirdly there is the Q word, quality, that is far more than the passing of sets of specific test cases.
More about complexity... Feature-Driven DevelopmentJeff De Luca's Feature-Driven Development (FDD) is agile, pragmatic, model-centric, client-valued-requirements-driven, and applicable for larger project teams than generally recommended for other agile processes. FDD also combines very nicely with Peter Coad's 'modeling in color' technique. In 2001, Peter Coad asked Mac Felsing and I to write a book for his Coad Series called A Practical Guide to Feature-Driven Development. Published in 2002 it remains the only book devoted to applying FDD. It was to be part of a set of three books including one called A Practical Guide to eXtreme Programming written by Randy Miller, Dave Astels, and Miro Novak, and similar titled one on the Unified Process that was never completed. As both a Certified Scrum Master and FDD Associate it is interesting to note where, more recently, Scrum practitioners have clearly been influenced by FDD. For example, an adaptation of the FDD Parking Lot chart appears in Mike Cohn's book, Agile Estimating and Planning. As agile grows up, I expect to see more and more of the ideas from the FDD gaining wider acceptance and use. IterationFrom Peter Coad's mantra of 'Deliver frequent, tangible, working results' to Scrum's month long 'sprints' and eXtreme Programming's two week iterations, the analysis, design, implementation, and testing of software in small, useful chunks has become more and more accepted as a best industry practice. Each of these small 'deliveries' provide an opportunity for the client to review the software built so far. This short feedback loop reduces the chance of misunderstanding and miscommunication of requirements resulting in large amounts of rework late in a development cycle or project. It also enables the client to adjust priorities of future work accordingly. Feature-Driven Development (FDD) delivers feature by feature where a feature is a small, piece of functionality of value to client paying for the software to be developed. DocumentationThe main mechanism for communication within the development team and between a development team and its client is often large documents. In a process that emphasizes the production of documents, care must be taken that the focus is not put on recording results at the cost of getting those results right; that emphasis is put on achieving quality results instead of quality formatting of poor results. |