Saturday, March 3, 2007

Software Development Process

I haven't considered that there are different methods to develop software, especially if it is done in collaboration.

I have five interesting Wikipedia entries I should read and digest (entry summaries taken from Wikipedia):

Software development process
A software development process is a structure imposed on the development of a software product. Synonyms include software lifecycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
Waterfall model
The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The origin of the term "waterfall" is often cited to be an article published in 1970 by W. W. Royce; ironically, Royce himself advocated an iterative approach to software development and did not even use the term "waterfall". Royce originally described what is now known as the waterfall model as an example of a method that he argued "is risky and invites failure".
Iterative and incremental development
Iterative and Incremental development is a software development process developed in response to the weaknesses of the more traditional waterfall model. The two most well known iterative development frameworks are the Rational Unified Process and the Dynamic Systems Development Method. Iterative and incremental development is also an essential part of Extreme Programming and all other agile software development frameworks.
Agile software development
Agile software development is a conceptual framework for undertaking software engineering projects.

There are a number of agile software development methods, such as those espoused by The Agile Alliance. Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. In many cases, software is released at the end of each iteration. This is particuarly true when the software is web-based and can be released easily. Regardless, at the end of each iteration, the team reevaluates project priorities.

Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers" (customers are the people who define the product; they may be product managers, business analysts, or actual customers). The bullpen may also include testers, interaction designers, technical writers, and managers.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.
Formal methods
In computer science and software engineering, formal methods are mathematically-based techniques for the specification, development and verification of software and hardware systems. The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analyses can contribute to the reliability and robustness of a design. However, the high cost of using formal methods means that they are usually only used in the development of high-integrity systems, where safety or security is important.

Of course, there are many more articles to read on this subject. There is a list on Wikipedia of all entries about the Software Development Process.

After listening to the Cincon Smalltalk podcast series (of which most episodes have Industry Misinterpretations in their title), episode Industry Misinterpretations Episode 23: Retrospective Coherence (MP3 file), I came to the conclusion that this topic, the software development process, is a really interesting.

Some fun and interesting paraphrases from that podcast episode:

Most people hear to listen, not to understand, like they have read-only memory
in order for a complex system to have resilience, it has to have some degree of inefficiency
process and code optimization should always be the last step in development, otherwise the system loses it's flexibility and ultimately breaks down
the purpose of most meetings is to keep people from taking responsibility

And then there are many more profound notions in this episode. Be sure to listen, but be warned that the audio quality is a bit poor.

No comments: