A Process Model refers to a description of business flow (order of task group).In many cases, a diagram is drawn "from left to right" or "from top to bottom" on the basis of execution procedure of each task. As a concept, not only Flow Models but also Data Models, etc. are included. An example of element resolution of Process Models is as follows.
• Flow models (definition of diagram)
• Divergence conditions (definition of condition that cannot be written in diagram)
• Allocation models (definition of person in charge of each task)
• Data models (definition of input/output, visibility)
According to this article found in the internet it says that a Process Model is a sequence of activities, objects, transformations, and events that embody strategies for accomplishing a certain task.
The model generally starts with a context diagram showing the system as a single process connected to external entities outside of the system boundary. This process explodes to a lower level DFD that divides the system into smaller parts and balances the flow of information between parent and child diagrams. Many diagram levels may be needed to express a complex system. Primitive processes, those that don't explode to a child diagram, are usually described in a connected textual specification.
What is a software process model?
In contrast to software life cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.
Software process networks can be viewed as 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 implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).
Task chains can be employed to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. For example, a task chain for the activity of object-oriented software design might include
the following task actions:
1. Develop an informal narrative specification of the system.
2. Identify the objects and their attributes.
3. Identify the operations on the objects.
4. Identify the interfaces between objects, attributes, or operations.
5. Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.
Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic 5 foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990).Thus, any software production web will in some way realize only an approximate or incomplete description of software development.
Traditional Process Model
Traditional models of software evolution have been with us since the earliest days of software engineering. The traditional process models of software development are as follows:
•Stepwise Refinement
In this approach, software systems are developed through the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili 1986).
However, the choice and order of which steps to choose and which refinements to apply remain unstated. Instead, formalization is expected to emerge within the heuristics and skills that are acquired and applied through increasingly competent practice.
This model has been most effective and widely applied in helping to teach individual programmers how to organize their software development work. Many interpretations of the classic software life cycle thus subsume this approach within their design and implementations.
In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:
1. Develop artist rendering (to consider viability).
2. Design foundation and superstructure.
3. Design Floor plans.
4. Design electrical and plumbing diagrams.
In other words, before the first shovel of dirt is dug on the project, the architect knows precisely what the building will look like and how it will work. All of the guess work has been eliminated.
•Incremental Development and Release Model
Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals (Basili 1975).
This model combines the classic software life cycle ("waterfall chart”) with iterative enhancement at the level of system development organization. It also supports a strategy to 7 periodically distribute software maintenance updates and services to dispersed user communities. This in turn accommodates the provision of standard software maintenance contracts. It is therefore a popular model of software evolution used by many commercial software firms and system vendors. This approach has also been extended through the use of software prototyping tools and techniques (described later), which more directly provide support for incremental development and iterative release for early and ongoing user feedback and evaluation (Graham 1989).
•Industrial and Military Standards, and Capability Models
Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices (Royce 1970, Boehm 1976, Distaso 1980, Humphrey 1985, Scacchi 1984, Somerville 1999).
Military software systems are often constrained in ways not found in industrial or academic practice, including:
(1) Required use of military standard computing equipment (which is often technologically dated and possesses limited processing capabilities);
(2) Embedded in larger systems (e.g., airplanes, submarines, missiles, command and control systems) which are mission-critical (i.e., those whose untimely failure could result in military disadvantage and/or life-threatening risks);
(3) Developed under contract to private firms through cumbersome procurement and acquisition procedures that can be subject to public scrutiny and legislative intervention; and ;
(4) Many embedded software systems for the military are among the largest and most complex systems in the world (Moore1997).
In industrial settings, standard software development models represent often provide explicit detailed guidelines for how to deploy, install, customize or tune a new software system release in its operating application environment. In addition, these standards are intended to be compatible with provision of software quality assurance, configuration management, and independent verification and validation services in a multi-contractor development project. Early efforts in monitoring and measuring software process performance found in industrial practice appear in (Humphrey 1985, Radice 1985, Basili 1988). These efforts in turn help pave the way for what many software development organizations now practice, or have been certified to practice, software process capability assessments, following the Capability Maturity Model developed by the Software Engineering Institute (Paulk 1995) (see Capability Maturity Model for Software).
All these models are independent of any organizational development setting, choice of programming language, software application domain, etc. In short, the traditional models are context-free rather than context-sensitive. But as all of these life cycle models have been in use for some time, we refer to them as the traditional models, and characterize each in turn.
Recent Process Model
Collectively, these process models are finer-grained, often detailed to the point of computational formalization, more often empirically grounded, and in some cases address the role of new automated technologies in facilitating software development. The recent process models of software development are as follows:
•Software Product Development Models
Software products represent the information-intensive artifacts that are incrementally constructed and iteratively revised through a software development effort. Such efforts can be modeled using software product life cycle models. These product development models represent an evolutionary revision to the traditional software life cycle models (MacCormack 2001).
The revisions arose due to the availability of new software development technologies such as software prototyping languages and environments, reusable software, application generators, and documentation support environments. Each of these technologies seeks to enable the creation of executable software implementations either earlier in the software development effort or more rapidly.
Therefore in this regard, the models of software development may be implicit in the use of the technology, rather than explicitly articulated. This is possible because such models become increasingly intuitive to those developers whose favorable experiences with these technologies substantiate their use. Thus, detailed examination of these models is most appropriate when such technologies are available for use or experimentation.
•Rapid Prototyping
Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987).
Software prototypes come 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 what distinguishes the prototype forms on this list.
Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model (described later) and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well an overall software development.
• Joint Application Development (JAD)
JAD is a technique for engaging a group or team of software developers, testers, customers, and prospective end-users in a collaborative requirements elicitation and prototyping effort (Wood and Silver 1995).
It is quintessentially a technique for facilitating group interaction and collaboration. Consultants often employ JAD or external software system vendors who have been engaged to build a custom software system for use in a particular organizational setting.
The JAD process is based on four ideas:
1. People who actually work at a job have the best understanding of that job.
2. People who are trained in software development have the best understanding of the possibilities of that technology.
3. Software-based information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
4. The best information systems are designed when all of these groups work together on a project as equal partners.
For large-scale projects, it is recommended that the project be organized as an incremental development effort, and that separate JAD's be used for each increment (Wood and Silver 1995). Given this formulation, it is possible to view open source software development projects that rely on group email discussions among globally distributed users and developers, together with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), as an informal variant of JAD.
References:
Alan Cline, “Joint Application Development (JAD) for Requirements Collection and Management”, www. Carolla.com
http://en.q-bpm.org/mediawiki/index.php/Process_Model#Use_of_Process_Models
http://www.excelsoftware.com/processmodel.html
http://it.toolbox.com/blogs/irm-blog/stepwise-refinement-25007
• Flow models (definition of diagram)
• Divergence conditions (definition of condition that cannot be written in diagram)
• Allocation models (definition of person in charge of each task)
• Data models (definition of input/output, visibility)
According to this article found in the internet it says that a Process Model is a sequence of activities, objects, transformations, and events that embody strategies for accomplishing a certain task.
The model generally starts with a context diagram showing the system as a single process connected to external entities outside of the system boundary. This process explodes to a lower level DFD that divides the system into smaller parts and balances the flow of information between parent and child diagrams. Many diagram levels may be needed to express a complex system. Primitive processes, those that don't explode to a child diagram, are usually described in a connected textual specification.
What is a software process model?
In contrast to software life cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.
Software process networks can be viewed as 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 implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).
Task chains can be employed to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. For example, a task chain for the activity of object-oriented software design might include
the following task actions:
1. Develop an informal narrative specification of the system.
2. Identify the objects and their attributes.
3. Identify the operations on the objects.
4. Identify the interfaces between objects, attributes, or operations.
5. Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.
Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic 5 foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990).Thus, any software production web will in some way realize only an approximate or incomplete description of software development.
Traditional Process Model
Traditional models of software evolution have been with us since the earliest days of software engineering. The traditional process models of software development are as follows:
•Stepwise Refinement
In this approach, software systems are developed through the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili 1986).
However, the choice and order of which steps to choose and which refinements to apply remain unstated. Instead, formalization is expected to emerge within the heuristics and skills that are acquired and applied through increasingly competent practice.
This model has been most effective and widely applied in helping to teach individual programmers how to organize their software development work. Many interpretations of the classic software life cycle thus subsume this approach within their design and implementations.
In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:
1. Develop artist rendering (to consider viability).
2. Design foundation and superstructure.
3. Design Floor plans.
4. Design electrical and plumbing diagrams.
In other words, before the first shovel of dirt is dug on the project, the architect knows precisely what the building will look like and how it will work. All of the guess work has been eliminated.
•Incremental Development and Release Model
Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals (Basili 1975).
This model combines the classic software life cycle ("waterfall chart”) with iterative enhancement at the level of system development organization. It also supports a strategy to 7 periodically distribute software maintenance updates and services to dispersed user communities. This in turn accommodates the provision of standard software maintenance contracts. It is therefore a popular model of software evolution used by many commercial software firms and system vendors. This approach has also been extended through the use of software prototyping tools and techniques (described later), which more directly provide support for incremental development and iterative release for early and ongoing user feedback and evaluation (Graham 1989).
•Industrial and Military Standards, and Capability Models
Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices (Royce 1970, Boehm 1976, Distaso 1980, Humphrey 1985, Scacchi 1984, Somerville 1999).
Military software systems are often constrained in ways not found in industrial or academic practice, including:
(1) Required use of military standard computing equipment (which is often technologically dated and possesses limited processing capabilities);
(2) Embedded in larger systems (e.g., airplanes, submarines, missiles, command and control systems) which are mission-critical (i.e., those whose untimely failure could result in military disadvantage and/or life-threatening risks);
(3) Developed under contract to private firms through cumbersome procurement and acquisition procedures that can be subject to public scrutiny and legislative intervention; and ;
(4) Many embedded software systems for the military are among the largest and most complex systems in the world (Moore1997).
In industrial settings, standard software development models represent often provide explicit detailed guidelines for how to deploy, install, customize or tune a new software system release in its operating application environment. In addition, these standards are intended to be compatible with provision of software quality assurance, configuration management, and independent verification and validation services in a multi-contractor development project. Early efforts in monitoring and measuring software process performance found in industrial practice appear in (Humphrey 1985, Radice 1985, Basili 1988). These efforts in turn help pave the way for what many software development organizations now practice, or have been certified to practice, software process capability assessments, following the Capability Maturity Model developed by the Software Engineering Institute (Paulk 1995) (see Capability Maturity Model for Software).
All these models are independent of any organizational development setting, choice of programming language, software application domain, etc. In short, the traditional models are context-free rather than context-sensitive. But as all of these life cycle models have been in use for some time, we refer to them as the traditional models, and characterize each in turn.
Recent Process Model
Collectively, these process models are finer-grained, often detailed to the point of computational formalization, more often empirically grounded, and in some cases address the role of new automated technologies in facilitating software development. The recent process models of software development are as follows:
•Software Product Development Models
Software products represent the information-intensive artifacts that are incrementally constructed and iteratively revised through a software development effort. Such efforts can be modeled using software product life cycle models. These product development models represent an evolutionary revision to the traditional software life cycle models (MacCormack 2001).
The revisions arose due to the availability of new software development technologies such as software prototyping languages and environments, reusable software, application generators, and documentation support environments. Each of these technologies seeks to enable the creation of executable software implementations either earlier in the software development effort or more rapidly.
Therefore in this regard, the models of software development may be implicit in the use of the technology, rather than explicitly articulated. This is possible because such models become increasingly intuitive to those developers whose favorable experiences with these technologies substantiate their use. Thus, detailed examination of these models is most appropriate when such technologies are available for use or experimentation.
•Rapid Prototyping
Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987).
Software prototypes come 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 what distinguishes the prototype forms on this list.
Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model (described later) and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well an overall software development.
• Joint Application Development (JAD)
JAD is a technique for engaging a group or team of software developers, testers, customers, and prospective end-users in a collaborative requirements elicitation and prototyping effort (Wood and Silver 1995).
It is quintessentially a technique for facilitating group interaction and collaboration. Consultants often employ JAD or external software system vendors who have been engaged to build a custom software system for use in a particular organizational setting.
The JAD process is based on four ideas:
1. People who actually work at a job have the best understanding of that job.
2. People who are trained in software development have the best understanding of the possibilities of that technology.
3. Software-based information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
4. The best information systems are designed when all of these groups work together on a project as equal partners.
For large-scale projects, it is recommended that the project be organized as an incremental development effort, and that separate JAD's be used for each increment (Wood and Silver 1995). Given this formulation, it is possible to view open source software development projects that rely on group email discussions among globally distributed users and developers, together with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), as an informal variant of JAD.
References:
Alan Cline, “Joint Application Development (JAD) for Requirements Collection and Management”, www. Carolla.com
http://en.q-bpm.org/mediawiki/index.php/Process_Model#Use_of_Process_Models
http://www.excelsoftware.com/processmodel.html
http://it.toolbox.com/blogs/irm-blog/stepwise-refinement-25007
0 comments:
Post a Comment