Wednesday, June 9, 2010
What is a software process model?
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. Examples of models include the workflow model, the data-flow model, and the role model.
-The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.
-The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.
-The role model represents the roles of people involved in the software process and the activities for which they are responsible.
Three (3) of the software development models:
1.Waterfall Model
The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in Figure1.1. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.
The model consist of six distinct stages, namely:
1.In the requirements analysis phase
(a)The problem is specified along with the desired service objectives (goals)
(b)The constraints are identified
2.In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.
3. In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:
·Data structure
·Software architecture
·Algorithmic detail and
·Interface representations
The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’
4.In the implementation and testing phase stage the designs are translated into the software domain
·Detailed documentation from the design phase can significantly reduce the coding effort.
·Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.
5.In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]
6.The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:
·Meet the changing customer needs
·Adapted to accommodate changes in the external environment
·Correct errors and oversights previously undetected in the testing phases
·Enhancing the efficiency of the software
Advantages
·Testing is inherent to every phase of the waterfall model
·It is an enforced disciplined approach
·It is documentation driven, that is, documentation is produced at every stage
Disadvantages
The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:
·It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
·As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
·The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.
2. The Spiral Model
The spiral model combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.The model is divided into a number of task regions.These regions are:
1.The customer communication task – to establish effective communication between developer and customer.
2.The planning task – to define resources, time lines and other project related information..
3.The risk analysis task – to assess both technical and management risks.
4.The engineering task – to build one or more representations of the application.
5.The construction and release task – to construct, test, install and provide user support (e.g., documentation and training).
6.The customer evaluation task – to obtain customer feedback based on the evaluation of the software representation created during the engineering stage and implemented during the install stage.
The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the production of a product specification and a prototype, respectively. Subsequent traversals may then produce more sophisticated versions of the software.
An important distinction between the spiral model and other software models is the explicit consideration of risk. There are no fixed phases such as specification or design phases in the model and it encompasses other process models. For example, prototyping may be used in one spiral to resolve requirement uncertainties and hence reduce risks. This may then be followed by a conventional waterfall development.
Advantages of the Spiral Model
*The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.
*The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.
*It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.
*If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.
Disadvantages of the Spiral Model
·Demands considerable risk-assessment expertise
·It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient.
3. Prototyping Model
A prototype is a working model that is functionally equivalent to a component of the product.In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.
The following sections examines two (2) version of the prototyping model:
Version I: Prototyping is used as a requirements technique.
Version II: Prototype is used as the specifications or a major part thereof.
Version I
This approach uses the prototype as a means of quickly determining the needs of the client; it is discarded once the specifications have been agreed on. The emphasis of the prototype is on representing those aspects of the software that will be visible to the client/user (e.g. input approaches and output formats). Thus it does not matter if the prototype hardly works.
Version II
In this approach the prototype is actually used as the specifications for the design phase. This advantage of this approach is speed and accuracy, as not time is spent on drawing up written specifications. The inherent difficulties associated with that phase (i.e. incompleteness, contradictions and ambiguities) are then avoided.
Disadvantages of prototyping:
1.Often clients expect that a few minor changes to the prototype will more than suffice their needs. They fail to realise that no consideration was given to the overall quality of the software in the rush to develop the prototype.
2.The developers may lose focus on the real purpose of the prototype and compromise the quality of the product. For example, they may employ some of the inefficient algorithms or inappropriate programming languages used in developing the prototype. This mainly due to laziness and an over reliance on familiarity with seemingly easier methods.
3.A prototype will hardly be acceptable in court in the event that the client does not agree that the developer has discharged his/her obligations. For this reason using the prototype as the software specification is normally reserved for software development within an organisation.
To avoid the above problems the developer and the client should both establish a protocol, which indicates the deliverables to the client as well as an contractual obligations.In both versions the prototype is discarded early in the life cycle. However, one way of ensuring that the product is properly designed and implemented is to implement the prototype in a different programming language from that of the product.
ref: http://scitec.uwichill.edu.bb/cmp/online/cs22l/prototype.htm, http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
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. Examples of models include the workflow model, the data-flow model, and the role model.
-The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.
-The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.
-The role model represents the roles of people involved in the software process and the activities for which they are responsible.
Three (3) of the software development models:
1.Waterfall Model
The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in Figure1.1. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.
The model consist of six distinct stages, namely:
1.In the requirements analysis phase
(a)The problem is specified along with the desired service objectives (goals)
(b)The constraints are identified
2.In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.
3. In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:
·Data structure
·Software architecture
·Algorithmic detail and
·Interface representations
The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’
4.In the implementation and testing phase stage the designs are translated into the software domain
·Detailed documentation from the design phase can significantly reduce the coding effort.
·Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.
5.In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]
6.The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:
·Meet the changing customer needs
·Adapted to accommodate changes in the external environment
·Correct errors and oversights previously undetected in the testing phases
·Enhancing the efficiency of the software
Advantages
·Testing is inherent to every phase of the waterfall model
·It is an enforced disciplined approach
·It is documentation driven, that is, documentation is produced at every stage
Disadvantages
The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:
·It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
·As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
·The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.
2. The Spiral Model
The spiral model combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.The model is divided into a number of task regions.These regions are:
1.The customer communication task – to establish effective communication between developer and customer.
2.The planning task – to define resources, time lines and other project related information..
3.The risk analysis task – to assess both technical and management risks.
4.The engineering task – to build one or more representations of the application.
5.The construction and release task – to construct, test, install and provide user support (e.g., documentation and training).
6.The customer evaluation task – to obtain customer feedback based on the evaluation of the software representation created during the engineering stage and implemented during the install stage.
The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the production of a product specification and a prototype, respectively. Subsequent traversals may then produce more sophisticated versions of the software.
An important distinction between the spiral model and other software models is the explicit consideration of risk. There are no fixed phases such as specification or design phases in the model and it encompasses other process models. For example, prototyping may be used in one spiral to resolve requirement uncertainties and hence reduce risks. This may then be followed by a conventional waterfall development.
Advantages of the Spiral Model
*The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.
*The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.
*It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.
*If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.
Disadvantages of the Spiral Model
·Demands considerable risk-assessment expertise
·It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient.
3. Prototyping Model
A prototype is a working model that is functionally equivalent to a component of the product.In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.
The following sections examines two (2) version of the prototyping model:
Version I: Prototyping is used as a requirements technique.
Version II: Prototype is used as the specifications or a major part thereof.
Version I
This approach uses the prototype as a means of quickly determining the needs of the client; it is discarded once the specifications have been agreed on. The emphasis of the prototype is on representing those aspects of the software that will be visible to the client/user (e.g. input approaches and output formats). Thus it does not matter if the prototype hardly works.
Version II
In this approach the prototype is actually used as the specifications for the design phase. This advantage of this approach is speed and accuracy, as not time is spent on drawing up written specifications. The inherent difficulties associated with that phase (i.e. incompleteness, contradictions and ambiguities) are then avoided.
Disadvantages of prototyping:
1.Often clients expect that a few minor changes to the prototype will more than suffice their needs. They fail to realise that no consideration was given to the overall quality of the software in the rush to develop the prototype.
2.The developers may lose focus on the real purpose of the prototype and compromise the quality of the product. For example, they may employ some of the inefficient algorithms or inappropriate programming languages used in developing the prototype. This mainly due to laziness and an over reliance on familiarity with seemingly easier methods.
3.A prototype will hardly be acceptable in court in the event that the client does not agree that the developer has discharged his/her obligations. For this reason using the prototype as the software specification is normally reserved for software development within an organisation.
To avoid the above problems the developer and the client should both establish a protocol, which indicates the deliverables to the client as well as an contractual obligations.In both versions the prototype is discarded early in the life cycle. However, one way of ensuring that the product is properly designed and implemented is to implement the prototype in a different programming language from that of the product.
ref: http://scitec.uwichill.edu.bb/cmp/online/cs22l/prototype.htm, http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment