Software Development Phases
Software development is achieved through a collection activities that lead to the building of a software product. Software development is traditionally divided into various phases, which we describe briefly in the following sections. For small projects, the phases are carried out in the order shown; for larger projects, the phases are interleaved or even applied repetitively with gradually increasing refinement (see incremental models). The strict definition and organization of these phases is called a software process.
Contents |
Requirements Analysis
Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Requirements analysis can itself be broken down in sub-activities. This phase is often the topic of processes itself, often refered to as the requirements process, or even requirements engineering process, the latter title being debatable. Requirements analysis methodologies have been created, one of the most popular being the use case driven methodology.
Specification
Specification is the task of precisely describing the problem description, often in a mathematically rigorous way, in most cases actually building a more or less complete model of the problem to be solved. A wide array of specification techniques exist, and many application areas rely on dedicated specification techniques. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed. Specifications are most important for external interfaces, that must remain stable. This is often refered to as software interface specifications. Note that internal software interfaces are generally established in the design phase of development, which makes this kind of specification a design artifact. However, some systems have external software interfaces with other existing systems. The specification of these interfaces then becomes something that is very important to specify in the early phases of development, and is thus really considered a specification artifact.
Design
Design refer to conceptually determining how the software is to function in a general way without being involved in low-level operational details. Usually this phase is divided into two sub-phases, such as architectural design, detailed design, or algorithmic design. Design can also be categorized into different focus such as graphical user interface (GUI) design, or database design, depending on the nature of the application. Design is anextremely important phase in the development of the software, as it permits the developers to think in relatively abstract terms about the solution. This is in contrast with the implementation phase, where the solution is approached from a very concrete and often short-sighted point of view. Approaching the problem from an abstract point of view permits to 'see the big picture', and develop abstract models of the solution that can be easily modified as details are grafted and the solution become more and more concrete. At a certain point, the designed solution will be concrete enough so that the implementation (i.e. coding) phase can start.
Implementation
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. A common fallacy in software development practice is that coding should be the main focus in software development. Such a misconception is a popular reason for low software quality or software project failure. Note that effective programmers have to deal with quality factors, and provide qualities such as code readability, maintainability, and often test the code as they are writing it.
Testing
Another common fallacy of software development is that tesing is mostly about executing the application and making sure that it does not crash before it is made operational. Testing is basically about verifying the quality of the product, and validate that it meets its requirements. In fact, "testing" is about the validation and verification of the various artifacts produced during the development of the software. Not only the code. For example, when requirements are established, one has to assess their quality in order to prevent that further phases be implementing a faulty or incomplete solution. The keyword "Testing" is most often refering to quality assurance of the code itself, but real software engineering will care about the quality of all artifacts produced, not only the code or the final application.
Documentation
An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Without documentation, software maintainers (who are in most cases the authors of the code they maintain) only have extremely low level design information, i.e. the code itself, to unserstand the software they have to change. For example, good software documentation presents the software in various levels of abstraction, permitting the reader to easily understand the functioning of the software and to assess the location and impact of the chages to be applied.
Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more effort than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort. About 2/3 of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, or adapti it to a new environment, which in many ways can be considered new work. Similarly, about 2/3 of all civil engineering, architecture, and construction work is maintenance.
