Introduction

A software development methodology or system development methodology in software engineering is a framework

that is used to structure, plan, and control the process of developing an information system.
There are the following methodologies:
Agile Software Development
Crystal Methods
Dynamic Systems Development Model (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Joint Application Development (JAD)
Lean Development (LD)
Rapid Application Development (RAD)
Rational Unified Process (RUP)
Scrum
Spiral
Systems Development Life Cycle (SDLC)
Waterfall (a.k.a. Traditional)

Agile Software Development Methodology
Agile software development is a conceptual framework for undertaking software engineering projects. There are a
number of agile software development methodologies e.g. Crystal Methods, Dynamic Systems Development Model
(DSDM), and Scrum.

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 the tasks
necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing,
and documentation. While 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. 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 the software. At a minimum, this includes
programmers and the people who define the product such as product managers, business analysts, or actual
customers. The bullpen may also include testers, interface designers, technical writers, and management .

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.

Crystal Methods Methodology
Alistair Cockburn developed the Crystal Methods approach. His focus is on the people, interaction, community, skills,
talents, and communications with the belief that these are what have the first-order effect on performance. Process,
he says, is important, but secondary.

Cockburn's philosophy translate into a recognition that each team has a different set of talents and skills and
therefore each team should use a process uniquely tailored to it. And it means that the process should be minimized -
barely significant.

The use of the word crystal refers to the various facets of a gemstone - each a different face on an underlying core.
The underlying core represents values and principles, while each facet represents a specific set of elements such as
techniques, roles, tools, and standards. Cockburn also differentiates between methodology, techniques, and policies.
A methodology is a set of elements (practices, tools); techniques are skill areas such as developing use cases;
and policies dictate organizational musts.

Dynamic Systems Development Model Methodology
The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. It is the evolution of rapid
application development (RAD) practices. DSDM boasts the best-supported training and documentation of any of the
agile software development techniques, at least in Europe. DSDM favors the philosophy that nothing is built perfectly
the first time and looks tosoftware development as an exploratory endeavor.

The nine principles of DSDM are:
Active user involvement.
Empowered teams that the authority to can make decisions.
A focus on frequent delivery of products.
Using fitness for business purpose as the essential criterion for acceptance of deliverables.
Iterative and incremental development to ensure convergence on an accurate business solution.
Reversible changes during development.
Requirements that is baselined at a high level.
Integrated testing throughout the life cycle.
Collaboration and cooperation between all stakeholders.

Extreme Programming (XP) Methodology
XP is a methodology for creating software within a very unstable environment. It allows flexibility within the modelling
process.

The main goal of XP is to lower the cost of change in software requirements. With traditional system development
methodologies, like the Waterfall Methodology, the requirements for the system are determined and often frozen at
the beginning of the development project. This means that the cost of changing the requirements at a later stage in
the project - something that is very common in the real-world can be very high.

XP Core Practices
The core practices of Extreme Programming, as described in the first edition of Extreme Programming Explained
can be grouped into four areas (12 practices) as follows:

Fine scale feedback
Test driven development
Planning game
Whole team
Pair programming

Continuous process rather than batch
Continuous Integration
Design Improvement
Small Releases

Shared understanding
Simple design
System metaphor
Collective code ownership
Coding standards or coding conventions

Programmer welfare
Sustainable pace (i.e. forty hour week)

In the second edition of Extreme Erogramming Explained a set of corollary practices are listed in addition to the
primary practices.

The core practices are derived from generally accepted best practices, and are taken to extremes:
Interaction between developers and customers is good. Therefore, an XP team is supposed to have a
customer on site, who specifies and prioritizes work for the team, and who can answer questions as soon
as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual
needs at the present time in a project, and go to some lengths to reduce complexity and duplication in their
code.
If simple code is good, re-write code when it becomes complex.
Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard
(which also improves communication) so that all code is reviewed as it is written.
Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered
complete when it passes the tests (but then it needs refactoring to remove complexity). The system is
periodically, or immediately tested using all pre-existing automated tests to assure that it works. See test-
driven development.

It used to be thought that Extreme Programming could only work in small teams of fewer than 12 persons. However,
XP has been used successfully on teams of over a hundred developers.

Feature Driven Development Methodology
Jeff De Luca and Peter Coad were both greatly involved in developing the Feature Driven Development methodology.
Peter describes FDD as having just enough process to ensure scalability and repeatability while encouraging
creativity and innovation.

More specifically, Feature Driven Development asserts that:
A system for building systems is necessary in order to scale to larger projects.
A simple, but well-define process will work best.
Process steps should be logical and their worth immediately obvious to each team member.
Process pride can keep the real work from happening.
Good processes move to the background so team members can focus on results.
Short, iterative, feature-driven life cycles are best.

FDD proceeds to address the items above with this simple process (numbers in brackets indicate the project time
spent):

1. Develop an overall model (10 percent initial, 4 percent ongoing)
2. Build a features list (4 percent initial, 1 percent ongoing)
3. Plan by feature (2 percent initial, 2 percent ongoing)
4. Design by feature
5. Build by feature (77 percent for design and build combined)

Joint Application Development (JAD) Methodology
JAD is a requirements-definition and user-interface design methodology in which end-users, executives, and
developers attend intense off-site meetings to work out a system's details. So the Joint Application Development
(JAD) methodology aims to involve the client in the design and development of an application. This is accomplished
through a series of collaborative workshops called JAD sessions. Two employees of IBM, Chuck Morris and Tony
Crawford, developed the JAD methodology in the late 1970s and began teaching the approach in to the 1980s.

JAD focuses on the business problem rather than technical details. It is most applicable to the development of
business systems, but it can be used successfully for systems software. It produces its savings by shortening the
elapsed time required to gather a system's requirements and by gathering requirements better, thus reducing the
number of costly, downstream requirements changes. Its success depends on effective leadership of the JAD
sessions; on participation by key end-users, executives, and developers; and on achieving group synergy during JAD
sessions.

In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client
satisfaction, both of which stem from the constant involvement of the client throughout the development process. On
the other hand, with the traditional approach to systems development, the developer investigates the system
requirements and develops an application, with client input consisting of a series of interviews.

Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through
strategies that include fewer formal methodologies and reusing software components.

Lean Development (LD) Methodology
Lean Development focuses on the creation of change-tolerant software. This methodology embodies the notion of
dynamic stability which can be thought of as similar to how Scrum embraces controlled chaos. Bob Charette, the
originator, writes that the measurable goal of LD is to build software with one-third the human effort, one-third the
development hours and one-third the investment as compared to what SEI (Software Engineering Institute) CMM
Level 3 organization would achieve.

There are 12 principles of Lean Development:
1. Satisfying the customer is the highest priority.
2. Always provide the best value for the money.
3. Success depends on active customer participation.
4. Every LD project is a team effort.
5. Everything is changeable.
6. Domain, not point, solutions.
7. Complete, don't construct.
8. An 80 percent solution today instead of 100 percent solution tomorrow.
9. Minimalism is essential.
10. Needs determine technology.
11. Product growth is feature growth, not size growth.
12. Never push LD beyond its limits.

Rapid Application Development (RAD) Methodology
Rapid-development language is a general term that refers to any programming language that offers speedier
implementation than do traditional third-generation languages such as C/C++, Pascal, or Fortran. Rapid-Development
Languages (RDLs) produce their savings by reducing the amount of construction needed to build a product. Although
the savings are realized during construction, the ability to shorten the construction cycle has projectwide implications:
shorter construction cycles make incremental lifecycles such as Evolutionary Prototyping practical. Because RDLs
often lack first-rate performance, constrain flexibility, and are limited to specific kinds of problems, they are usually
better suited to the development of in-house business software and limited-distribution custom software than systems
software.

RAD (rapid application development) proposes that products can be developed faster and of higher quality by:
Using workshops or focus groups to gather requirements.
Prototyping and user testing of designs.
Re-using software components.
Following a schedule that defers design improvements to the next product version.
Keeping review meetings and other team communication informal.
There are commercial products that include requirements gathering tools, prototyping tools, software development
environments such as those for the Java platform, groupware for communication among development members, and
testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-
use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming
packages often described as providing rapid application development.

Rational Unified Process (RUP) Methodology
The Rational Unified Process attempts to capture many of modern software development's best practices in a form
suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach
can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall
approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle.
Problems found at this stage are very expense to fix.

By contrast, RUP represents an iterative approach that is superior for a number of reasons:
It lets you take into account changing requirements which despite the best efforts of all project managers are
still a reality on just about every project.
Integration is not one big bang at the end; instead, elements are integrated progressively.
Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate
risks earlier.
Iterative development provides management with a means of making tactical changes to the product. It
allows you to release a product early with reduced functionality to counter a move by a competitor, or to
adopt another vendor for a given technology.
Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented
than to recognize them during planning.
When you can correct errors over several iterations, the result is a more robust architecture. Performance
bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve
of delivery.
Developers can learn along the way, and their various abilities and specialties are more fully employed
during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
The development process itself can be improved and refined along the way. The assessment at the end of
iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes
what should be changed in the organization and in the process to make it perform better in the next
iteration.

Scrum Methodology
Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve
productivity in teams previously paralyzed by heavier, process-laden methodologies.

Scrum is characterized by:
A living backlog of prioritized work to be done.
Completion of a largely fixed set of backlog items in a series of short iterations or sprints.
A brief daily meeting (called a scrum), at which progress is explained, upcoming work is described, and
obstacles are raised.
A brief planning session in which the backlog items for the sprint will be defined.
A brief heartbeat retrospective, at which all team members reflect about the past sprint.
Scrum is facilitated by a scrum master, whose primary job is to remove impediments to the ability of the team to
deliver the sprint goal. The scrum master is not the leader of the team (as they are self-organizing) but acts as a
productivity buffer between the team and any destabilizing influences.

Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team members
and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally
empirical challenges cannot be addressed successfully in a traditional process control manner. As such, scrum
adopts an empirical approach - accepting that the problem cannot be fully understood or defined, focusing instead on
maximizing the team's ability to respond in an agile manner to emerging challenges.

Spiral Methodology
The Spiral Lifecycle Model is a sophisticated lifecycle model that focuses on early identification and reduction of
project risks. A spiral project starts on a small scale, explores risks, makes a plan to handle the risks, and then
decides whether to take the next step of the project - to do the next iteration of the spiral. It derives its
rapiddevelopment benefit not from an increase in project speed, but from continuously reducing the projects risk level
- which has an effect on the time required to deliver it. Success at using the Spiral Lifecycle Model depends on
conscientious, attentive, and knowledgeable management .It can be used on most kinds of projects, and its risk-
reduction focus is always beneficial.

The spiral methodology extends the waterfall model by introducing prototyping. It is generally chosen over the
waterfall approach for large, expensive, and complicated projects.

At a high-level, the steps in the spiral model are as follows:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a
number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down
system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved using four steps:
Evaluate the first prototype and identify its strengths, weaknesses, and risks.
Define the requirements of the second prototype.
Plan and design the second prototype.
Construct and test the second prototype.
5. At the project sponsor's option, the entire project can be aborted if the risk is deemed too great. Risk factors might
involve development cost overruns, operating-cost miscalculation, or any other factor that could result in a less-than-
satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another
prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final
product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to
prevent large-scale failures and to minimize downtime.

Systems Development Life Cycle (SDLC) Methodology
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the
stages involved in an information system development project, from an initial feasibility study through maintenance of
the completed application. Various SDLC methodologies have been developed to guide the processes involved,
including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint
application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize.

Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the
type of model chosen or devised for any application, and is usually done in parallel with the development process.
Some methods work better for specific types of projects, but in the final analysis, the most important factor for the
success of a project may be how closely the particular plan was followed.

In general, an SDLC methodology follows these steps:
1. If there is an existing system, its deficiencies are identified. This is accomplished by interviewing users and
consulting with support personnel.
2. The new system requirements are defined including addressing any deficiencies in the existing system with
specific proposals for improvement.
3. The proposed system is designed. Plans are created detailing the hardware, operating systems, programming, and
security issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the
system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be
made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to
application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut
down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept
up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and
procedures.

Waterfall (a.k.a. Traditional) Methodology
The waterfall model is a popular version of the systems development life cycle model for software engineering. Often
considered the classic approach to the systems development life cycle, the waterfall model describes a development
method that is rigid and linear. Waterfall development has distinct goals for each phase of development where each
phase is completed for the next one is started and there is no turning back.

The perceived advantages of the waterfall process are that it allows for departmentalization and managerial control. A
schedule is typically set with deadlines for each stage of development and a product can proceed through the
development process. In theory, this process leads to the project being delivered on time because each phase has
been planned in detail.

In practice, waterfall development often falls short of expectations as it does not embrace the inevitable changes and
revisions that become necessary with most projects. Once an application is in the testing stage, it is very difficult to
go back and change something that was not thought of in the concept stage. Alternatives to the waterfall model
include joint application development (JAD), rapid application development (RAD), sync and stabilize, build and fix,
and the spiral model.

Software development activities[edit]
Planning[edit]
Planning is an objective of each and every activity, where we want to discover things that belong to
the project. An important task in creating a software program is extracting
the requirements or requirements analysis.
[1]
Customers typically have an abstract idea of what they
want as an end result, but do not know what software should do. Skilled and experienced software
engineers recognize incomplete, ambiguous, or even contradictory requirements at this point.
Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of unclear
requirements at the start of development. If the development is done externally, this document can
be considered a legal document so that if there are ever disputes, any ambiguity of what was
promised to the client can be clarified.
Designing[edit]
Once the requirements are established, the design of the software can be established in a software
design document. This involves a preliminary, or high-level design of the main modules with an overall
picture (such as a block diagram) of how the parts fit together. The language, operating system, and
hardware components should all be known at this time. Then a detailed or low-level design is
created, perhaps with prototyping as proof-of-concept or to firm up requirements.
Implementation, testing and documenting[edit]
Implementation is the part of the process where software engineers actually program the code for the
project.
Software testing is an integral and important phase of the software development process. This part of
the process ensures that defects are recognized as soon as possible.
Documenting the internal design of software for the purpose of future maintenance and enhancement
is done throughout development. This may also include the writing of an API, be it external or
internal. The software engineering process chosen by the developing team will determine how much
internal documentation (if any) is necessary. Plan-driven models (e.g.,Waterfall) generally produce
more documentation than Agile models.
Deployment and maintenance[edit]
Deployment starts directly after the code is appropriately tested, approved for release, and sold or
otherwise distributed into a production environment. This may involve installation, customization
(such as by setting parameters to the customer's values), testing, and possibly an extended period
of evaluation.
[citation needed]

Software training and support is important, as software is only effective if it is used correctly.
[citation
needed]

Maintaining and enhancing software to cope with newly discovered faults or requirements can take
substantial time and effort, as missed requirements may force redesign of the software.
[citation needed]

Software development models[edit]
Several models exist to streamline the development process. Each one has its pros and cons, and it
is up to the development team to adopt the most appropriate one for the project. Sometimes a
combination of the models may be more suitable.
Waterfall model[edit]
Main article: Waterfall model


The activities of the software development process represented in the waterfall model. There are several other models
to represent this process.
The waterfall model shows a process, where developers have to follow these phases in order:
1. Requirements specification (Requirements analysis)
2. Software design
3. Implementation and Integration
4. Testing (or Validation)
5. Deployment (or Installation)
6. Maintenance
In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may
occur before moving to the next phase which allows for the possibility of changes (which may involve
a formal change control process). Reviews may also be employed to ensure that the phase is indeed
complete; the phase-completion criteria are often referred to as a "gate" that the project must pass
through to move to the next phase. Waterfall discourages revisiting and revising any prior phase
once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by
supporters of other more "flexible" models.
The Waterfall model is also commonly taught with the mnemonic A Dance in the Dark Every Monday,
representing Analysis, Design, Implementation, Testing, Documentation and Execution, and
Maintenance.
[citation needed]

Spiral model[edit]
Main article: Spiral model


Spiral model (Boehm, 1988)
The key characteristic of a Spiral model is risk management at regular stages in the development
cycle. In 1988, Barry Boehm published a formal software system development "spiral model," which
combines some key aspect of the waterfall modeland rapid prototyping methodologies, but provided
emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative
risk analysis, particularly suited to large-scale complex systems.
The Spiral is visualized as a process passing through some number of iterations, with the four
quadrant diagram representative of the following activities:
1. Formulate plans to: identify software targets, implement the program, clarify the project
development restrictions
2. Risk analysis: an analytical assessment of selected programs, to consider how to identify
and eliminate risk
3. Implementation of the project: the implementation of software development and verification
Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support
software reuse, software quality can help as a special goal of integration into the product
development. However, the spiral model has some restrictive conditions, as follows:
1. The spiral model emphasizes risk analysis, and thus requires customers to accept this
analysis and act on it. This requires both trust in the developer as well as the willingness to
spend more to fix the issues, which is the reason why this model is often used for large-
scale internal software development.
2. If the implementation of risk analysis will greatly affect the profits of the project, the spiral
model should not be used.
3. Software developers have to actively look for possible risks, and analyze it accurately for the
spiral model to work.
The first stage is to formulate a plan to achieve the objectives with these constraints, and then strive
to find and remove all potential risks through careful analysis and, if necessary, by constructing a
prototype. If some risks cannot be ruled out, the customer has to decide whether to terminate the
project or to ignore the risks and continue anyway. Finally, the results are evaluated and the design
of the next phase begins.
Iterative and incremental development[edit]
Main article: Iterative and incremental development
Iterative development
[2]
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.
Agile development[edit]
Main article: Agile software development
Agile software development uses iterative development as a basis but advocates a lighter and more
people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate
iteration and the continuous feedback that it provides to successively refine and deliver a software
system.
There are many variations of agile processes:
In extreme programming (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 programmers working in pairs, a technique known as "pair
programming"), 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 from refactoring, and come
after coding. The same people who do the coding do design. (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.
[3]

Dynamic systems development method
Scrum
Rapid application development[edit]


Rapid Application Development (RAD) Model
Rapid application development R.A.D is a software development methodology that uses minimal
planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved
with writing the software itself. The lack of extensive pre-planning generally allows software to be
written much faster, and makes it easier to change requirements. RAD involves methods like iterative
development and software prototyping. According to Whitten (2004), it is a merger of various structured
techniques, especially data-driven Information Engineering, with prototyping techniques to accelerate
software systems development.
[4]

In rapid application development, structured techniques and prototyping are especially used to
define users' requirements and to design the final system. The development process starts with the
development of preliminary data models and business process models using structured techniques. In
the next stage, requirements are verified using prototyping, eventually to refine the data and process
models. These stages are repeated iteratively; further development results in "a combined business
requirements and technical design statement to be used for constructing new systems".
[4]

Code and fix[edit]
"Code and fix" development is not so much a deliberate strategy as an artifact of navet and
schedule pressure on software developers.
[5]
Without much of a design in the
way, programmers immediately begin producing code. At some point, testingbegins (often late in the
development cycle), and the unavoidable bugs must then be fixed before the product can be shipped.
See also: Continuous integration and Cowboy coding.
Process improvement models[edit]
Capability Maturity Model Integration
The Capability Maturity Model Integration (CMMI) is one of the leading models and based on
best practice. Independent assessments grade organizations on how well they follow their
defined processes, not on the quality of those processes or the software produced. CMMI
has replaced CMM.
ISO 9000
ISO 9000 describes standards for a formally organized process to manufacture a product and
the methods of managing and monitoring progress. Although the standard was originally
created for the manufacturing sector, ISO 9000 standards have been applied to software
development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality
of the end result, only that formalized business processes have been followed.
ISO/IEC 15504
ISO/IEC 15504 Information technology Process assessment also known as Software
Process Improvement Capability Determination (SPICE), is a "framework for the assessment
of software processes". This standard is aimed at setting out a clear model for process
comparison. SPICE is used much like 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.
Formal methods[edit]
Formal methods are mathematical approaches to solving software (and hardware)
problems at the requirements, specification, and design levels. Formal methods are
most likely to be applied to safety-critical or security-critical software and systems, such
as avionics software. Software safety assurance standards, such as DO-178B, DO-178C,
and Common Criteria demand formal methods at the highest levels of categorization.
For sequential software, examples of formal methods include the B-Method, the
specification languages used in automated theorem proving, RAISE, and the Z notation.
Formalization of software development is creeping in, in other places, with the
application of Object Constraint Language(and specializations such as Java Modeling
Language) and especially with model-driven architecture allowing execution of designs, if
not specifications.
For concurrent software and systems, Petri nets, process algebra, and finite state
machines (which are based on automata theory - see also virtual finite state machine or event
driven finite state machine) allow executable software specification and can be used to
build up and validate application behavior.
Another emerging trend in software development is to write a specification in some form
of logicusually a variation of first-order logic (FOL)and then to directly execute the
logic as though it were a program. The OWL language, based onDescription Logic (DL),
is an example. There is also work on mapping some version of English (or another
natural language) automatically to and from logic, and executing the logic directly.
Examples are Attempto Controlled English, and Internet Business Logic, which do not
seek to control the vocabulary or syntax. A feature of systems that support bidirectional
English-logic mapping and direct execution of the logic is that they can be made to
explain their results, in English, at the business or scientific level.