Software systems appear and disappear through a number of passages that take into account their inception, initial development, productive operation, upkeep, and retirement in one generation to a different. This article categorizes and examines numerous methods for describing or modeling how software systems are developed. It starts with background and definitions of traditional software life-cycle models that dominate most textbook discussions and current software development practices.
This really is followed by a far more comprehensive overview of the alternative types of software evolution which are of current use because the basis for organizing software engineering projects and technologies.
Background
Explicit types of software evolution go as far back to the earliest projects developing large software systems within the 1950′s and 1960′s. Overall, the apparent reason for these early software life-cycle models ended up being to provide a conceptual scheme for rationally handling the development of software systems.
This type of scheme could therefore function as a basis for planning, organizing, staffing, coordinating, budgeting, and directing software development activities. Because the 1960′s, many descriptions from the classic software life-cycle have appeared (e.g., Hosier 1961, Royce 1970, Boehm 1976, Distaso 1980, Scacchi 1984, Somerville 1999). Royce originated the formulation from the software life-cycle using the now familiar “waterfall” chart, displayed in
These charts in many cases are employed during introductory presentations, for individuals (e.g., customers of custom software) who might be unfamiliar with the different technical problems and techniques that must be addressed when constructing large software systems .
These classic software life-cycle models usually include some version or subset from the following activities:
_ System Initiation/Planning: where do systems originate from? In most situations, new feasible systems replace or supplement existing information processing mechanisms whether or not they were previously automated, manual, or informal.
_ Requirement Analysis and Specification: identifies the issues a new software product is suppose to resolve, its operational capabilities, its desired performance characteristics, and also the resource infrastructure required to support system operation and maintenance.
_ Functional Specification or Prototyping: identifies and potentially formalizes the objects of computation, their attributes and relationships, the operations that transform these objects, the restrictions that restrict system behavior, and so on.
_ Partition and Selection (Build vs. Buy vs. Reuse): given requirements and functional specifications, divide the machine into manageable pieces that denote logical subsystems, then see whether new, existing, or reusable software systems match the needed pieces.
_ Architectural Design and Configuration Specification: defines the interconnection and resource interfaces between system subsystems, components, and modules with techniques suitable for their detailed design and overall configuration management.
_ Detailed Component Design Specification: defines the procedural methods by which the data resources inside the modules of the component are transformed from required inputs into provided outputs.
_ Component Implementation and Debugging: codifies the preceding specifications into operational source code implementations and validates their basic operation.
_ Software Integration and Testing: affirms and sustains the general integrity from the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resource interfaces and interconnections against their specifications, and validating the performance from the system and subsystems against their requirements.
_ Documentation Revision and System Delivery: packaging and rationalizing recorded system development descriptions into systematic documents and user guides, all inside a form ideal for dissemination and system support.
_ Deployment and Installation: providing directions for installing the delivered software in to the local computing environment, configuring os’s parameters and user access privileges, and running diagnostic test cases to make sure the viability of basic system operation.
_ Training and employ: providing system users with instructional aids and guidance for comprehending the system’s capabilities and limits to be able to effectively make use of the system.
_ Software Maintenance: sustaining the useful operation of the system in the host/target environment by giving requested functional enhancements, repairs, performance improvements, and conversions.
Exactly what is a software life-cycle model?
An application life cycle model will be an descriptive or prescriptive characterization of methods software is or ought to be developed. A descriptive model describes a brief history of how a specific software system was created. Descriptive models can be utilized as the grounds for understanding and improving software development processes, or building empirically grounded prescriptive models (Curtis, Krasner, Iscoe, 1988).
A prescriptive model prescribes the way a new software system ought to be developed. Prescriptive models are utilized as guidelines or frameworks to arrange and structure how software development activities ought to be performed, as well as in what order. Typically, it’s easier and much more common to articulate a prescriptive life-cycle model based on how software systems ought to be developed.
You could do since most such models are intuitive or well reasoned. Which means that many idiosyncratic details that describe the way a software systems is made in practice could be ignored, generalized, or deferred for later consideration. This, obviously, should raise concern for that relative validity and robustness of these life cycle models when developing different types of application systems, in various kinds of development settings, using different programming languages, with differentially skilled staff, etc.
However, prescriptive models will also be used to package the expansion tasks and methods for using confirmed set of software engineering tools or environment throughout a development project. Descriptive life-cycle models, however, characterize how particular software systems are in fact developed in specific settings.
As a result, they are less frequent and more hard to articulate to have an obvious reason: you have to observe or collect data through the life cycle of the software system, a time of elapsed time often measured in a long time. Also, descriptive models are specific towards the systems observed and just generalizable through systematic comparative analysis.
Therefore, this means that the prescriptive software life-cycle models will dominate attention until an adequate base of observational information is available to articulate empirically grounded descriptive life-cycle models. Both of these characterizations suggest that there are a number of purposes for articulating software life-cycle models.
These characterizations function as a _ Guideline to arrange, plan, staff, budget, schedule and manage software project work over organizational time, space, and computing environments.
_ Prescriptive outline for which documents to create for delivery to client.
_ Grounds for determining what software engineering tools and methodologies is going to be most appropriate to aid different life-cycle activities.
_ Framework for analyzing or estimating patterns of resource allocation and consumption throughout the software life-cycle (Boehm 1981)
_ Grounds for conducting empirical studies to determine which affects software productivity, cost, and overall quality.
Exactly what is a software process model?
As opposed to software life-cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody techniques for accomplishing software evolution. Such models may be used to develop more precise and formalized descriptions of software life-cycle activities.
Their ability emerges using their utilization of a sufficiently rich notation, syntax, or semantics, often ideal for computational processing. Software process networks may very well be representing multiple interconnected task chains (Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products.
Non-linearity signifies that the sequence of actions might be non-deterministic, iterative, accommodate multiple/parallel alternatives, in addition to partially ordered to take into account incremental progress.
Task actions consequently can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, like a user’s choice of a command or menu entry utilizing a mouse or keyboard. Winograd yet others have known these units of cooperative work between people and computers as “structured discourses of work” (Winograd 1986), while task chains have grown to be popularized as of “workflow” (Bolcer 1998).
Task chains can be used to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of the items actions ought to be accomplished, as well as in what order.
For instance, a task chain for that activity of object-oriented software design might range from the following task actions: Develop a casual narrative specification from the system with interim management. Identify the objects as well as their attributes. Identify the operations around the objects. Identify the interfaces between objects, attributes, or operations. Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations throughout incrementally progressing toward an object-oriented software design. Task chains join or split up into other task chains leading to an overall production network or web (Kling 1982).
The development web represents the “organizational production system” that transforms raw computational, cognitive, along with other organizational resources into assembled, integrated and usable software systems. The development lattice therefore structures the way a software product is developed, used, and maintained.
However, prescriptive task chains and actions can’t be formally certain to anticipate all possible circumstances or idiosyncratic foul-ups that may emerge in real life of software development (Bendifallah 1989, Mi 1990). Thus, any software production web will in some manner realize only approximately or incomplete description of software development. Articulation jobs are a kind of unanticipated task that’s performed whenever a planned task chain is inadequate or stops working.
It is work that is representative of an open-ended non-deterministic sequence of actions come to restore progress around the disarticulated task chain, otherwise to shift the flow of productive work onto another task chain (Bendifallah 1987, Grinter 1996, Mi 1990, Mi 1996, Scacchi and Mi 1997). Thus, descriptive task chains are widely-used to characterize the observed span of events and situations that emerge when individuals try to consume a planned task sequence.
Articulation operate in the context of software evolution includes actions people take that entail either their accommodation towards the contingent or anomalous behavior of the software system, or negotiation with other people who might be able to affect something modification or else alter current circumstances (Bendifallah 1987, Grinter 1996, Mi 1990, Mi 1996, Scacchi and Mi 1997). This perception of articulation work has additionally been referred to as software process dynamism.
Traditional Software Life-cycle Models
Traditional types of software evolution happen to be with us because the earliest times of software engineering. Within this section, we identify four. The classic software life-cycle (or “waterfall chart”) and stepwise refinement models are widely instantiated in only about all books on modern programming practices and software engineering. The incremental release model is closely associated with industrial practices where it usually occurs. Military standards based designs include also reified certain types of the classic life-cycle model into required practice for government contractors.
All these four models uses coarse-grain or macroscopic characterizations when describing software evolution. The progressive steps of software evolution in many cases are described as stages, for example requirements specification, preliminary design, and implementation; these will often have little or no further characterization apart from a list of attributes the product of these a stage should possess.
Further, these models are separate from any organizational development setting, selection of programming language, software program domain, etc. In a nutshell, the traditional models are context-free instead of context-sensitive. But as many of these life cycle designs include been in use for a while, we make reference to them because the traditional models, and characterize each consequently.
Classic Software Life-cycle
The classic software life-cycle is often represented like a simple prescriptive waterfall software phase model, where software evolution proceeds with an orderly sequence of transitions in one phase to another in order (Royce 1970). Such models resemble finite state machine descriptions of software evolution.
However, these designs include been perhaps best in helping to structure, staff, and manage large software development projects in complex organizational settings, that was one of the primary purposes (Royce 1970, Boehm 1976). Alternatively, these classic designs include been widely characterized as both poor descriptive and prescriptive types of how software development “in-the-small” or “in-the-large” can or should take place.
Stepwise Refinement
Within this approach, software systems are developed with the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili 1986). However, the option and order which steps to select and which refinements to use remain unstated. Instead, formalization is anticipated to emerge inside the heuristics and skills which are acquired and applied through increasingly competent practice.
This model continues to be most effective and widely applied in assisting to teach individual programmers how you can organize their software development work. Many interpretations from the classic software life-cycle thus subsume this method within their design and implementations.
Incremental Development and Release
Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and much more capable versions of the system at regular intervals (Basili 1975). This model combines the classic software life-cycle with iterative enhancement in the level of system development organization. Additionally, it supports a method to periodically distribute software maintenance updates and services to dispersed user communities.
Therefore accommodates the supply of standard software maintenance contracts. Therefore, it is a popular type of software evolution used by lots of commercial software firms and system vendors. This method has also been extended by using software prototyping tools and methods (described later), which more directly provide support for incremental development and iterative release for early and continuing user feedback and evaluation (Graham 1989).
Elsewhere, the Cleanroom software development method at use within IBM and NASA laboratories provides incremental discharge of software functions and/or subsystems (developed through stepwise refinement) to split up in-house quality assurance teams that apply statistical measures and analyses because the basis for certifying high-quality software systems (Selby 1987, Mills 1987).
Industrial and Military Standards, and Capability Models
Industrial firms often adopt some variation from the classic model because the basis for standardizing their software development practices (Royce 1970, Boehm 1976, Distaso 1980, Humphrey 1985, Scacchi 1984, Somerville 1999).
Such standardization is usually motivated by must simplify or eliminate complications that emerge during large software development or project management software. From the 1970′s with the present, many government contractors organized their software development activities based on succession of military software standards for example MIL-STD- 2167A, MIL-STD 498, and IEEE-STD-016. ISO12207 (Moore 1997) has become the standard that many such contractors now follow. These standards are an outgrowth from the classic life-cycle activities, with the documents essental to clients who procure either software systems or complex platforms with embedded software systems.
Military software system in many cases are constrained with techniques not present in industrial or academic practice, including: (1) required utilization of military standard computing equipment (that is technologically dated and has limited processing capabilities); (2) take root in larger systems (e.g., airplanes, submarines, missiles, command and control systems) that are mission-critical (i.e., those whose untimely failure could cause military disadvantage and/or life-threatening risks); (3) are developed under contract to personal firms through cumbersome procurement and acquisition procedures that may be subject to public scrutiny and legislative intervention; and (4) many embedded software systems for that military are probably the largest and many complex systems on the planet (Moore 1997). Finally, the introduction of custom software systems using commercial off-the-shelf (COTS) components or products is really a recent direction for government contractors, and therefore represents new challenges based on how to incorporate a component-based development in to the overall software life-cycle.
Accordingly, new software life-cycle models that exploit COTS components continues to appear within the next few years. In industrial settings, standard software development models represent often provide explicit detailed guidelines based on how to deploy, install, customize or tune a brand new software system release in the operating application environment. Additionally, these standards usually are meant to be suitable for provision of software quality assurance, configuration management, and independent verification and validation services inside a multi-contractor development project.
Early efforts in monitoring and measuring software process performance present in industrial practice come in (Humphrey 1985, Radice 1985, Basili 1988). These efforts consequently help create what many software development organizations now practice, or happen to be certified to rehearse, software process capability assessments, following a Capability Maturity Model produced by the Software Engineering Institute (Paulk 1995) (see Capability Maturity Model for Software).
Other options to a Traditional Software Life-cycle Models
You will find at least three alternative teams of models of software development. These models are other options to a traditional software life-cycle models. These three sets focus of focus on either these products, production processes, or production settings related to software development. Collectively, these alternative models are finer-grained, often detailed to begin computational formalization, more often empirically grounded, and perhaps address the role of recent automated technologies in facilitating software development. Because these models aren’t in widespread practice, we examine each group of models within the following sections.
Software Product Models
Software products represent the information-intensive artifacts which are incrementally constructed and iteratively revised via a software development effort. Such efforts could be modeled using software product life-cycle models. These product models represent an evolutionary revision towards the traditional software life-cycle models (MacCormack 2001). The revisions arose because of the availability of new software development technologies for example software prototyping languages and environments, reusable software, application generators, and documentation support environments. All these technologies seeks make it possible for the creation of executable software implementations either earlier within the software development effort or even more rapidly.
Therefore in connection with this, the types of software development might be implicit within the use of the technology, instead of explicitly articulated. You could do because such models become increasingly intuitive to people developers whose favorable experiences with one of these technologies substantiate their use. Thus, detailed study of these models is most suitable when such technology is available for use or experimentation.
Rapid Prototyping and Joint Database integration
Prototyping is a way of providing a lower functionality or perhaps a limited performance version of the software system at the start of its development (Balzer 1983, Budde 1984, Hekmatpour 1987). As opposed to the classic system life-cycle, prototyping is an approach whereby more emphasis, activity, and processing are forwarded to the early stages of software development (requirements analysis and functional specification). Consequently, prototyping can more directly accommodate early user participation in determining, shaping, or evaluating emerging system functionality. Therefore, these up-front concentrations of effort, with the use of prototyping technologies, seeks to trade-off or else reduce downstream software design activities and iterations, in addition to simplify the program implementation effort. (see Rapid Prototyping) Software prototypes are available in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes (Hekmatpour 1987).
Increasing functionality and subsequent evolvability is exactly what distinguishes the prototype forms about this list. Prototyping technologies usually try taking some form of software functional specifications his or her starting point or input, which is simulated, analyzed, or directly executed. These technologies makes it possible for developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations may then be incorporated as feedback to refine the emerging system specifications and fashions. Further, with respect to the prototyping technology, the entire working system could be developed via a continual revising/refining the input specifications. It has the advantage of always providing a functional version from the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches would be best suited for developing throwaway or demonstration systems, or building prototypes by reusing part/all of some existing software systems. Subsequently, it might be clear why modern types of software development such as the Spiral Model (described later) and also the ISO 12207 expect that prototyping is a common activity that facilitates the capture and refinement of software requirements, in addition to overall software development.
Joint Database integration (JAD)
This is a way of engaging an organization or team of software developers, testers, customers, and prospective end-users inside a collaborative requirements elicitation and prototyping effort (Wood and Silver 1995). JAD is quintessentially a method for facilitating group interaction and collaboration. Consultants often employ JAD or external software system vendors who’ve been engaged to construct a custom software system to be used in a particular organizational setting. The JAD process is dependant on four ideas: 1.Individuals who actually work on a job possess the best knowledge of that job. 2.Those who are trained in software development possess the best knowledge of the possibilities of this technology. 3. Software-based information systems and business processes rarely appear in isolation — they transcend the confines associated with a single system or office and effect operate in related departments. People employed in these related areas have valuable insight around the role of the system inside a larger community. 4.The very best information systems are made when many of these groups interact on a project as equal partners. Following these ideas, it ought to be possible for JAD to pay for the complete development life-cycle of a system.
The JAD is generally a 3 to 6 month well-defined project, when systems could be constructed from commercially accessible software items that do not require extensive coding or complex systems integration. For large-scale projects, our recommendation is that the project be organized being an incremental development effort, which separate JAD’s be utilized for each increment (Wood and Silver 1995). With all this formulation, you’ll be able to view open source development projects that depend on group email discussions among globally distributed users and developers, along with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), being an informal variant of JAD.
Assembling Reusable Components
The fundamental approach of reusability would be to configure and specialize pre-existing software components into viable application systems (Biggerstaff 1984, Neighbors 1984, Goguen 1986). Such source code components might curently have associated specifications and fashions associated with their implementations, in addition to have been tested and certified. However, it’s also clear that software domain models, system specifications, designs, test case suites, along with other software abstractions may themselves be treated as reusable software development components. These elements may have a greater possibility of favorable effect on reuse and semiautomated system generation or composition (Batory et al., 1994, Neighbors 1984). Therefore, assembling reusable software components is really a strategy for decreasing software development effort with techniques that are suitable for the traditional life-cycle models. The fundamental dilemmas encountered with reusable software componentry include (a) acquiring, analyzing and modeling an application application domain, (b) how you can define a suitable software part naming or classification scheme, (c) collecting or building reusable software components, (d) configuring or composing components right into a viable application, and (e) maintaining and looking out a components library.
Consequently, each of these dilemmas is mitigated or resolved used through the choice of software component granularity. The granularity from the components (i.e., size, complexity, and functional capability) varies across different approaches. Most approaches make an effort to utilize components much like common (textbook) data structures with algorithms for his or her manipulation: small-grain components. However, the use/reuse of small-grain components by itself does not constitute a definite approach to software development. Other approaches make an effort to utilize components resembling functionally complete systems or subsystems (e.g., interface management system): large-grain components.
The use/reuse of large-grain components guided by a credit card applicatoin domain analysis and subsequent mapping of attributed domain objects and processes onto interrelated components does seem to be an alternative method of developing software systems (Neighbors 1984), and therefore is an section of active research. There are lots of ways to utilize reusable software components in evolving software systems. However, the cited studies suggest their initial use during architectural or component design specification in an effort to speed implementation. They may also be used for prototyping purposes if your suitable software prototyping technology can be obtained.
Application Generation
Application generation is definitely an approach to software development much like reuse of parameterized, large-grain software source code components. Such components are configured and specialized for an application domain using a formalized specification language used as input towards the application generator. Common examples provide standardized interfaces to database management system applications, and can include generators for reports, graphics, user interfaces, and application-specific editors (Batory, et al. 1994, Horowitz 1985). Application generators produce a model of software development whereby traditional software design activities are generally all but eliminated, or reduced to some data base design problem. The program design activities are eliminated or reduced since the application generator embodies or supplies a generic software design that needs to be compatible with the applying domain. However, users of application generators are often expected to provide input specifications and application maintenance services. These capabilities are possible because the generators usually can only produce software systems specific to some small number of similar application domains, in most cases those that rely on a data base management system.
Software Documentation Support Environments
A lot of the focus on developing software products draws focus on the tangible software artifacts that result. Usually, these products go ahead and take form of documents: commented source code listings, structured design diagrams, unit development folders, etc. These documents characterize exactly what the developed product is suppose to complete, how it will it, how it was created, how it was come up with and validated, and the way to install, use, and keep it. Thus, an accumulation of software documents records the passage of the developed software system via a set of life-cycle stages. It appears reasonable there will be types of software development that focus focus on the systematic production, organization, and control over the software development documents. Further, as documents are tangible products, it’s quite common practice when software systems are developed under contract to some private firm, the delivery of those documents is really a contractual stipulation, along with the basis for getting money for development work already performed.
Thus, the necessity to support and validate conformance of those documents to software development and quality assurance standards emerges. However, software development documents in many cases are a primary medium for communication between developers, users, and maintainers that spans organizational space and time. Thus, all these groups can usually benefit from automated mechanisms that permit them to browse, query, retrieve, and selectively print documents (Garg and Scacchi, 1989, 1990). As a result, we should ‘t be surprise to determine construction and deployment of software environments that offer ever increasing automated support for engineering the program documentation life-cycle (e.g., Penedo 1985, Horowitz 1986, Garg and Scacchi, 1989, 1990), or how these capabilities have since end up part of the commonly available computeraided software engineering (CASE) tools suites like Rational Rose, yet others based on the utilisation of the Unified Modeling Language (UML).
Rapid Iteration, Incremental Evolution, and Evolutionary Delivery
There’s a growing quantity of technological, social and economic trends which are shaping the way a new generation of software systems are now being developed that exploit the web and Internet. These include the synchronize and stabilize techniques popularized by Microsoft and Netscape in the height from the fiercely competitive efforts to dominate the net browser market from the mid 1990′s (Cusumano and Yoffie, 1999, MacCormack 2001). Additionally they include the growth and development of open source software systems that depend on a decentralized community of volunteer software developers to collectively develop and test software systems which are incrementally enhanced, released, experienced, and debugged within an overall iterative and cyclic manner (DiBona 1999, Fogel 1999, Mockus 2000). The elapsed duration of these incremental development life cycles on some projects might be measured in weeks, days, or hours!
The centralized planning, management authority and coordination imposed through the traditional system life-cycle model continues to be discarded during these efforts, replaced instead with a more organic, participatory, reputation-based, and community oriented engineering practice. Software engineering within the style of rapid iteration and incremental evolution is a that concentrates on and celebrates the inevitability of constantly shifting system requirements, unanticipated situations useful and functional enhancement, and also the need for developers to collaborate together, even when they’ve never met (Truex 1999). As a result, we are prone to see more research and commercial development targeted at figuring out whether or how software process models can accommodate rapid iteration, incremental evolution, or synchronize and stabilize techniques whether put on closed, centrally developed systems, in order to open, de-centrally developed systems.
Program Evolution Models
As opposed to the preceding four prescriptive product models, Lehman and Belady sought to build up a descriptive type of software product evolution. They conducted a number of empirical studies from the evolution of huge software systems at IBM throughout the 1970′s (Lehman1985). (see Software Evolution) According to their investigations, they identify five properties that characterize the evolution of huge software systems. They are: 1. Continuing change: a sizable software system undergoes continuing change or becomes progressively less useful 2. Increasing complexity: like a software system evolves, its complexity increases unless jobs are done to maintain or reduce it 3. Fundamental law of program evolution: program evolution, the programming process, and global measures of project and system attributes are statistically self-regulating with determinable trends and invariances 4. Invariant work rate: the speed of global activity inside a large software project is statistically invariant 5. Incremental growth limit: throughout the active lifetime of a large program, the amount of modifications designed to successive releases is statistically invariant. However, you should observe that they are global properties of huge software systems, not causal mechanisms of software development. Newer advances within the study of program evolution are available elsewhere within the article by Lehman and Ramil (See Software Evolution chapter).
Software Production Process Models
There’s two kinds of software production process models: non-operational and operational. Both of them are software process models. The main difference between the two primarily comes from the fact that the operational models may very well be computational scripts or programs: programs that implement a specific regimen of software engineering and development. Non-operational models however denote conceptual approaches which have not yet been sufficiently articulated inside a form ideal for codification or automated processing.
Non-Operational Process Models
There’s two classes of non-operational software process types of the great interest. Fundamental essentials spiral model and also the continuous transformation models. There’s also a wide selection of other non-operational models, which for brevity we label as miscellaneous models. Are all examined consequently. The Spiral Model. The spiral type of software development and evolution represents a riskdriven method of software process analysis and structuring (Boehm 1987, Boehm et al, 1998). This method, developed by Barry Boehm, incorporates aspects of specification-driven, prototype-driven process methods, with the classic software life-cycle. It does so by representing iterative development cycles being an expanding spiral, with inner cycles denoting early system analysis and prototyping, and outer cycles denoting the classic software life-cycle. The radial dimension denotes cumulative development costs, and also the angular dimension denotes progress produced in accomplishing each development spiral.
Risk analysis, which seeks to recognize situations that may cause a development effort to fail or review budget/schedule, occurs during each spiral cycle. In each cycle, it represents roughly exactly the same amount of angular displacement, as the displaced sweep volume denotes increasing amounts of effort required for risk analysis. System rise in this model therefore spirals out only as far as needed based on the risk that must definitely be managed. Alternatively, the spiral model suggests that the classic software life-cycle model only need be followed when risks are greatest, and after early system prototyping as a means of reducing these risks, albeit at increased cost.
The insights the Spiral Model offered has in turned influenced the conventional software life-cycle process models, for example ISO12207 noted earlier. Finally, work is now happening to integrate computer-based support for stakeholder negotiations and capture of trade-off rationales into an operational type of the WinWin Spiral Model (Boehm et al, 1998). (see Risk Management in Software Development) Miscellaneous Process Models. Many variations from the non-operational life cycle and process designs include been proposed, and appearance in the proceedings from the international software process workshops sponsored through the ACM, IEEE, and Software Process Association. Included in this are fully interconnected life-cycle models that accommodate transitions between any two phases susceptible to satisfaction of the pre- and post-conditions, in addition to compound variations around the traditional life-cycle and continuous transformation models. However, reports indicate that generally most software process models are exploratory, though now there is a growing base of experimental or industrial knowledge about these models (Basili 1988, Raffo et al 1999, Raffo and Scacchi 2000).
Operational Process Models
As opposed to the preceding non-operational process models, many models are actually beginning to appear which codify software engineering processes in computational terms–as programs or executable models. Three classes of operational software process models could be identified and examined. After this, we can also identify numerous emerging trends that exploit and extend using operational process models for software engineering. Operational specifications for rapid prototyping. The operational method of software development assumes the presence of a formal specification language and processing environment that props up evolutionary growth and development of specifications into an prototype implementation (Bauer 1976, Balzer 1983, Zave 1984). Specifications within the language are coded, so when computationally evaluated, constitute a practical prototype from the specified system.
When such specifications could be developed and processed incrementally, the resulting system prototypes could be refined and become functionally more complete systems. However, the emerging software systems will always be operational in certain form throughout their development. Variations in this approach represent either efforts in which the prototype may be the end sought, or where specified prototypes are kept operational but refined right into a complete system. The specification language determines the ability underlying operational specification technology. Essentially, if the specification language is really a conventional programming language, then not new in the way of software development is realized. However, when the specification incorporates (or reaches) syntactic and semantic language constructs which are specific towards the application domain, which often are not a part of conventional programming languages, then domain-specific rapid prototyping could be supported.
A fascinating twist worth note is it is generally inside the capabilities of numerous operational specification languages to specify “systems” whose purpose would be to serve as a type of an arbitrary abstract process, like a software process model. In this manner, using a prototyping language and environment, one could possibly specify an abstract type of some software engineering processes like a system that creates and consumes certain kinds of documents, along with the classes of development transformations put on them. Thus, in connection with this, it may be possible to create operational software process models that may be executed or simulated using software prototyping technology.
Humphrey and Kellner describe one particular application and provide an example while using graphic-based state-machine notation provided within the STATECHARTS environment (Humphrey 1989). Software automation. Automated software engineering (also known as knowledge-based software engineering) tries to take process automation to the limits by let’s assume that process specifications may be used directly to develop software systems, and also to configure development environments to aid the production tasks available. The common approach would be to seek to automate some type of the continuous transformation model (Bauer 1976, Balzer 1985). Consequently, this implies an automatic environment able to recording the formalized growth and development of operational specifications, successively transforming and refining these specifications into an implemented system, assimilating maintenance requests by the new/enhanced specifications in to the current development derivation, then replaying the revised development toward implementation (Balzer 1983b, Balzer 1985).
However, current progress continues to be limited to demonstrating such mechanisms and specifications on software coding, maintenance, project communication and management tasks (Balzer 1983b, Balzer 1985, Sathi 1985, Mi 1990, Scacchi and Mi 1997), in addition to software component catalogs and formal types of software development processes (Ould 1988, Wood 1988, Mi 1996). Last, reserach has shown how you can combine different life-cycle, product, and production process models inside a process-driven framework that integrates both conventional and knowledge-based software engineering tools and environments (Garg 1994, Heineman 1994, Scacchi and Mi 1997). Software process automation and programming. Process automation and programming are worried with developing formal specifications of methods a system or group of software systems ought to be developed. Such specifications therefore offer an account for the business and description of numerous software production task chains, the way they interrelate, when then can iterate, etc., in addition to what software tools to make use of to support different tasks, and just how these tools ought to be used (Hoffnagel 1985, Osterweil 1987). Focus then converges on characterizing the constructs integrated into the language for specifying and programming software processes.
Accordingly, discussion then turns to look at the appropriateness of language constructs for expressing rules for backward and forward-chaining, behavior, object type structures, process dynamism, constraints, goals, policies, modes of user interaction, plans, off-line activities, resource commitments, etc. across various amounts of granularity (Garg and Scacchi 1989, Kaiser 1988, Mi and Scacchi 1992, Williams 1988, Yu and Mylopoulus 1994),. Therefore implies that conventional mechanisms for example operating system shell scripts (e.g., Makefiles on Unix) don’t support the types of software process automation these constructs portend. Lehman (1987) and Curtis and associates, (1987) provide provocative critiques from the potential and limitations of current proposals for software process automation and programming.
Their criticisms, given our framework, essentially explain that many process programming proposals (by 1987) were focused almost exclusively to people aspects of software engineering which were amenable to automation, for example tool sequence invocation. They explain how such proposals often neglect to address the way the production settings and merchandise constrain and connect to how the software production process is determined and performed, as revealed in recent empirical software process studies (Bendifallah 1987, Curtis, et al., 1988, Bendifallah 1989, Grinter 1996). Beyond these, the dominant trend throughout the 1990′s related to software process automation was the introduction of process-centered software engineering environments (Garg 1996). A large number of research projects plus some commercial developments were undertaken to build up, experiment with, and assess the potential opportunities and obstacles related to software environments driven by operational software process models. Several process model formalisms were tried including knowledge-based representations, rule-based schemes, and Petri-net schemes and variations. In early 1990′s, emphasis centered on the development of distributed client-server environments that generally trusted a centralized server.
The server might then interpret a procedure model based on how to schedule, coordinate, or reactively synchronize the program engineering activities of developers dealing with client-side tools (Garg et al 1994, Garg 1996, Heineman 1994, Scacchi and Mi 1997). To no real surprise, by the late 1990′s emphasis has shifted towards environment architectures that employed decentralized servers for process support, workflow automation, data storage, and tool services (Bolcer 1998, Grundy 1999, Scacchi and Noll 1997). Finally, there is also some effort to grow the scope of operational support certain to process models in terms that recognized their growing importance like a new type of software (Osterweil 1987). Ideas began to begin to see the emergence of process engineering environments that support their very own class of life-cycle activities and support mechanisms (Garg and Jazayeri 1996, Garg et al 1994, Heineman 1994, Scacchi and Mi 1997, Scacchi and Noll 1997).
Emerging Trends and New Directions
As well as the ongoing interest, debate, and assessment of process-centered or process-driven software engineering environments that depend on process models to configure or control their operation (Ambriola 1999, Garg and Jazayeri 1996), there are a variety of promising avenues for more research and development with software process models. These opportunities areas and sample direction for more exploration include: _ Software process simulation (Raffo et al, 1999, Raffo and Scacchi 2000) efforts which aim to determine or experimentally assess the performance of classic or operational process models utilizing a sample of alternative parameter configurations or empirically derived process data (cf. Cook and Wolf 1998). Simulation of empirically derived types of software evolution or evolutionary processes offer new avenues for exploration (Chatters, Lehman, et al., 2000, Mockus 2000). _ Web-based software process models and process engineering environments (Bolcer 1998, Grundy 1998, Penedo 2000, Scacchi and Noll 1997) that aim to provide software development workspaces and project support capabilities which are tied to adaptive process models.
(see Engineering Web Applications with Java) _ Software process and business process reengineering (Scacchi and Mi 1997, Scacchi and Noll 1997, Scacchi 2000) which focuses focus on opportunities that emerge once the tools, techniques, and ideas for each disciplined are combined for their relative advantage. Therefore is giving rise to new approaches for redesigning, situating, and optimizing software process models for specific organizational and system development settings (Scacchi and Noll 1997, Scacchi 2000). (see Business Reengineering within the Age of the web) _ Understanding, capturing, and operationalizing process models that characterize the practices and patterns of globally distributed software development related to open source software (DiBona 1999, Fogel 1999, Mockus 2000), along with other emerging software development processes, for example extreme programming (Beck 1999) and Web-based virtual software development enterprises or workspaces (Noll and Scacchi 1999,2001, Penedo 2000).
Summary
The central thesis of the chapter is the fact that contemporary types of software development must take into account software the interrelationships between software products and production processes, and for the roles played by tools, people as well as their workplaces. Modeling these patterns can utilize options that come with traditional software life-cycle models, in addition to those of automatable software process models. Nonetheless, we should also notice that the death from the traditional system life-cycle model might be at hand. New models for software development enabled through the Internet, group facilitation and distant coordination within open source communities, and shifting business imperatives in reaction to these the weather is giving rise to a different generation of software processes and process models. These new models give a view of software development and evolution that’s incremental, iterative, ongoing, interactive, and responsive to social and organizational circumstances, yet still time, increasingly amenable to automated support, facilitation, and collaboration within the distances of space and time.
