Methodology

Methodology is usually a guideline system for solving a problem, with specific components such as phases, tasks, methods, techniques and tools.[1] It can be defined also as follows: 1. "the analysis of the principles of methods, rules, and postulates employed by a discipline";[2] 2. "the systematic study of methods that are, can be, or have been applied within a discipline";[2] 3. "the study or description of methods".[3] A methodology can be considered to include multiple methods, each as applied to various facets of the whole scope of the methodology. The research can be divided between two parts, they are qualitative research and quantitative research.

Relation to methods and theories

Generally speaking, methodology does not describe specific methods despite the attention given to the nature and kinds of processes to be followed in a given procedure or in attaining an objective. When proper to a study of methodology, such processes constitute a constructive generic framework; thus they may be broken down in sub-processes, combined, or their sequence changed.[4] As such, methodology may entail a description of generic processes, philosophical concepts or theories related to a particular discipline or field of inquiry. Similarly methodology refers to the rationale and/or the philosophical assumptions that underlie a particular study or a particular methodology (for example, the scientific method). In scholarly literature a section on the methodology of the researchers is typically de rigueur.

Relation to paradigm and algorithm

In theoretical work, the development of paradigms[5] satisfies most or all of the criteria for methodology. A paradigm, like an algorithm, is a constructive framework, meaning that the socalled construction is a logical, rather than a physical, array of connected elements.
A software development process, also known as a software development life cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a life-cycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.

Overview

The large and 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 international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO/IEC 12207. A decades-long goal has been to find repeatable, predictable processes 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 appears to be lacking. Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.

Software development activities

The activities of the software development process represented in the waterfall model. There are several other models to represent this process. Planning

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 not 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.
Implementation, testing and documenting

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

Deployment starts 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

Several models exist to streamline the development process. Each one has its pros and cons, and it's 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 Main article: Waterfall model

The waterfall model shows a process, where developers are to follow these phases in order:
1. 2. 3. 4. 5. 6. Requirements specification (Requirements analysis) Software design Implementation and Integration Testing (or Validation) Deployment (or Installation) 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.
Spiral model Main article: Spiral model

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 model and 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, selected to 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. the 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 can not 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 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 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 use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. 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 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. 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] Scrum Dynamic systems development method

Code and fix

"Code and fix" development is not so much a deliberate strategy as an artifact of naivet and schedule pressure on software developers.[4] Without much of a design in the way, programmers immediately begin producing code. At some point, testing begins (often late in the development cycle), and the inevitable bugs must then be fixed before the product can be shipped. See also: Continuous integration and Cowboy coding.

Process improvement models

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
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, VDM, 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 logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, 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.

V-Model (software development)

From Wikipedia, the free encyclopedia Jump to: navigation, search This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
(October 2008)

The V-model of the Systems Engineering Process.[1]

Software development process

Activities and steps

Requirements Specification Architecture Design Testing Debugging Deployment Maintenance Implementation

Methodologies

Waterfall Incremental Iterative V-Model Spiral Scrum Cleanroom RAD DSDM RUP XP Agile Lean TDD

Prototype model

Dual Vee Model

Supporting disciplines

Configuration management

Documentation Project management

Quality assurance (SQA) User experience design

Tools

Compiler Debugger Profiler GUI designer IDE

Build automation

v t e

The V-model[2] represents a software development process (also applicable to hardware development) which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

Contents

1 Verification Phases o 1.1 Requirements analysis o 1.2 System Design o 1.3 Architecture Design o 1.4 Module Design 2 Validation Phases o 2.1 Unit Testing o 2.2 Integration Testing o 2.3 System Testing 2.3.1 Reasons for system test

2.4 User Acceptance Testing 2.4.1 Procedures o 2.5 Release Testing 3 Criticism 4 Current State 5 See also 6 References 7 Further reading 8 External links

Verification Phases
Requirements analysis

In the Requirements analysis phase, the first step in the verification process, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned with establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the systems functional, interface, performance, data, security, etc. requirements as expected by the user. It is used by business analysts to communicate their understanding of the system to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. See also Functional requirements. this is parallel processing There are different methods for gathering requirements of both soft and hard methodologies including; interviews, questionnaires, document analysis, observation, throw-away prototypes, use cases and status and dynamic views with users.
System Design

Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing are prepared in this phase.

Architecture Design

The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in the particular phase.
Module Design

The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:

database tables, with all elements, including their type and size all interface details with complete API references all dependency issues error message listings complete input and outputs for a module.

The unit test design is developed in this stage.

Validation Phases

The V-model detail Unit Testing Main article: Unit testing

In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Unit tests are created by programmers or occasionally by white box testers. The purpose is to verify the internal logic code by testing every possible branch within the function, also known as test coverage. Static analysis tools are used to facilitate in this process, where variations of input data are passed to the function to test every possible case of execution.
Integration Testing Main article: Integration testing

In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing Main article: System testing

System testing will compare the system specifications against the actual system. After the integration test is completed, the next test level is the system test. System testing checks if the integrated product meets the specified requirements. Why is this still necessary after the component and integration tests? The reasons for this are as follows:
Reasons for system test 1. In the lower test levels, the testing was done against technical specifications, i.e., from the technical perspective of the software producer. The system test, though, looks at the system from the perspective of the customer and the future user. The testers validate whether the requirements are completely and appropriately met. o Example: The customer (who has ordered and paid for the system) and the user (who uses the system) can be different groups of people or organizations with their own specific interests and requirements of the system. 2. Many functions and system characteristics result from the interaction of all system components, consequently, they are only visible on the level of the entire system and can only be observed and tested there. User Acceptance Testing Main article: Acceptance testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived

from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not. Acceptance testing helps

to determine whether a system satisfies its acceptance criteria or not. to enable the customer to determine whether to accept the system or not. to test the software in the "real world" by the intended audience.

Purpose of acceptance testing:

to verify the system or changes according to the original needs.

Procedures 1. Define the acceptance criteria: o Functionality requirements. o Performance requirements. o Interface quality requirements. o Overall software quality requirements. 2. Develop an acceptance plan: o Project description. o User responsibilities. o Acceptance description. Release Testing

Release testing is a phase that determines if the software is suitable for the organisation of the end-user.[3] How is compatibility with other systems ensured? Is the performance of the software optimized?

Criticism
The V-Model has been criticized by Agile advocates and others as an inadequate model of software development for numerous reasons[4]. Criticisms include:
1. It is too simple to accurately reflect the software development process, and can lead managers into a false sense of security. 2. It is inflexible; it has no ability to respond to change. 3. It produces inefficient testing methodologies.

Spiral model
From Wikipedia, the free encyclopedia Jump to: navigation, search

Spiral model (Boehm, 1988).

Software development process

Activities and steps

Requirements Specification Architecture Design Testing Debugging Deployment Maintenance Implementation

Methodologies

Waterfall Incremental Iterative

Prototype model

V-Model Spiral Scrum Cleanroom RAD DSDM RUP XP Agile Lean TDD

Dual Vee Model

Supporting disciplines

Configuration management

Documentation Project management

Quality assurance (SQA) User experience design

Tools

Compiler Debugger Profiler GUI designer IDE

Build automation

v t e

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.

Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping and the waterfall model. The spiral model is intended for large, expensive and complicated projects. This should not be confused with the Helical model of modern systems architecture that uses a dynamic programming approach in order to optimise the system's architecture before design decisions are made by coders that would cause problems.

Contents

1 History 2 The model 3 Applications 4 References

History
The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software Development and Enhancement".[1] This model was not the first model to discuss iterative development. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.[2]

The model
The spiral model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of the waterfall model. It allows for incremental releases of the product, or incremental refinement through each time around the spiral. The spiral model also explicitly includes risk management within software development. Identifying major risks, both technical and managerial, and determining how to lessen the risk helps keep the software development process under control.[3] The spiral model is based on continuous refinement of key products for requirements definition and analysis, system and software design, and implementation (the code). At each iteration around the cycle, the products are extensions of an earlier product. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations.[3] Documents are produced when they are required, and the content reflects the information necessary at that point in the process. All documents will not be created at the beginning of the

process, nor all at the end (hopefully). Like the product they define, the documents are works in progress. The idea is to have a continuous stream of products produced and available for user review.[3] The spiral lifecycle model allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design. This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort. For projects with heavy user interfacing, such as user application programs or instrument interface applications, such involvement is helpful.[3] Starting at the center, each turn around the spiral goes through several task regions [3]:

Determine the objectives, alternatives, and constraints on the new iteration. Evaluate alternatives and identify and resolve risk issues. Develop and verify the product for this iteration. Plan the next iteration.

Note that the requirements activity takes place in multiple sections and in multiple iterations, just as planning and risk analysis occur in multiple places. Final design, implementation, integration, and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using this method of development, some functionality can be delivered to the user faster than the waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly admitting that all of anything cannot be known before the subsequent activity starts.[3]

Applications
This article may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. (November
2011)

The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The military had adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (20032009), it had a two year iteration (spiral). The FCS should have resulted in three consecutive prototypes (one prototype per spiralevery two years). It was canceled in May 2009. The spiral model thus may suit small (up to $3 million) software applications and not a complicated ($3 billion) distributed, interoperable, system of systems. Also it is reasonable to use the spiral model in projects where business goals are unstable but the architecture must be realized well enough to provide high loading and stress ability. For example, the Spiral Architecture Driven Development is the spiral based Software Development Life Cycle (SDLC) which shows one possible way how to reduce the risk of non-effective

architecture with the help of a spiral model in conjunction with the best practices from other models.