Software development process

A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns.

The term covers a wide array of methodologies created for this purpose and range from the very informal to the highly structured and rigorous. When these address the entire scope of software design, creation, delivery, and maintenance, the processes are sometimes referred to as supporting software development life cycle management.

=Processes and meta-processes=

A growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a Rating based on Process models to obtain contracts.

The Capability Maturity Model (CMM) is one of the leading models. Independent assessments can be used to grade organizations on how well they create software according to how they define and execute their processes. ISO 9000 describes standards for formally organizing processes with documentation.

ISO 15504, also known as Software Process Improvement Capability Determination (SPICE). The software process life cycle is also gaining wide usage. This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMM and CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

Six Sigma is a methodology (software engineering) that uses data and statistical analysis to measure and improve a company s operational performance. It works by identifying and eliminating defects in manufacturing and service-related processes. The maximum permissible defects are 3.4 per million opportunities. However Six Sigma is manufacturing-oriented, not software development-oriented and needs further research to even apply to software development.

Agile software development methodologies, such as Extreme Programming and Lean manufacturing are full blown methods that take an incremental or evolutionary approach to software development.

Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine).

=Process and methodology=

A decades-long goal has been to find repeatable, predictable processes or methodologies (software engineering) that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management is proving difficult.

See also software development processes and methodology (software engineering).

==Process steps==

Software engineering requires performing many tasks, notably the following, some of which may not seem to directly produce software.

; 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. ; Specification : Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In reality, 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. ; Design and Architecture : Design and architecture refer to determining how software is to function in a general way without being involved in details. Usually this phase is divided into two sub-phases. ; Coding : Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. ; Testing : Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer. ; Documentation : An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces. ; Maintenance : Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time 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 by a software engineer. 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, which in many ways can be considered new work. Similarly, about 2/3 of all civil engineering, architecture, and construction work is maintenance in a similar way.

==Waterfall processes==

The best-known and oldest process is the waterfall model, where developers (roughly) follow these steps in order. They state requirements, analyze them, design a solution approach, architect a software framework for that solution, develop code, test (perhaps unit tests then system tests), deploy, and maintain. After each step is finished, the methodology proceeds to the next step, just as builders don t revise the foundation of a house after the framing has been erected. There is no provision in the methodology for correcting errors in early steps (for example, in the requirements), so the entire (expensive) engineering process may be executed to the end, resulting in unusable or unneeded software features, just as a house built on an incorrect foundation might be uninhabitable after it is handed over to the customer. The original description of the methodology did include for iteration, but that part of the methodology is usually overlooked.

One source of difficulty is that the number of dependencies among the artifacts (outputs) of the various steps is surprisingly high, much higher in a typical software project than in a typical building project.

In old style (CMM) processes, architecture and design preceded coding, usually by separate people in a separate process step.

Although the lesson that the waterfall model doesn t work very well is known among software engineers, that lesson seems lost on many managers or executives. Perhaps the waterfall model appeals to managers because it seems to allow one to plan and carry out a software project as predictably as one might plan and build a house.

==Iterative processes==

Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what he wants.

The method of payment for iterative modification of code is called a change order.

Hacking: A misuse of iterative development is hacking at the terminal , or mindlessly altering code without a defined goal.

==Agile processes==

Agile processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability. In essence, they say that they will provide the most bang for the buck, but won t say exactly what the bang will be.

Extreme Programming, XP, is the best-known agile process. In XP, the phases are carried out in extremely small (or continuous ) steps compared to the older, batch processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can t think of any more tests that are needed. Design and architecture emerge out of Refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.

==Formal methods==

Formal methods [[gopz]] are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri net, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behaviour by designing a system of finite state machines.

==Specification-driven development==

The goal of specifications is to state what the application should do, simply and precisely. Over time, the meaning has changed.

In the 1950s, Fortran was advertised as a language that eliminated the need for programming. Engineers could literally write down the equations that they needed. Fortran was originally viewed as a specification language.

The problem is that every time languages work at a higher level, specifications are expected to work at the next level, too.

Recent approaches try to merge the specification and code into one activity, as this seems to be the only honest way to ensure the specification and code match. While Agile software development methods propagate specification of all requirements in code, software engineering purists argue for executable specification, which can be achieved by methods like Virtual finite state machine, trying to avoid the coding activity at all.

=Lists=

Some software development methods: *Top-Down Model *Bottom Up *Waterfall model *V model *Spiral model *Chaos model *Prototyping *Evolutionary prototyping *Iterative and Incremental development *Extreme Programming *Rational Unified Process

Some paradigms for programming software: *Procedural programming *Structured programming *Imperative programming *Declarative programming *Functional programming *Literate programming *Object oriented programming *Aspect oriented programming *Concurrent programming *Software componentry *Interactive programming

There are also a variety of kinds of software documentation.

=See also=

*Free software development *Project lifecycle *Project *Process *programming tool *Model *Methodology (software engineering) *List of software engineering topics *Systems design

= External links =

*[http://www.projectinvision.com Project and Process Management Software] *[http://www.techbookreport.com/SoftwareIndex.html TechBookReport - Software Methodologies] Book reviews on software methodologies - including agile, RUP, design patterns etc