Systems Development Models
Before any software is made there is a process to go through to make it work. It passes through phases to make it as faultless as possible for the users. It might go through planning, coding, developing and other steps before one can create a software system work. This now relates to process model. If I were to define it from the word itself it is a flow of steps to organize the building or engineering of a software system. Having a process model help us to strategies what should be done for the system and help create the algorithm of the program.
For a better understanding and for a more concrete definition, here follows the definition of process model from Wikipedia.
“Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.”
Software process models represent a sequence of activities or events that symbolize strategies for accomplishing software development. Process models can be used to develop more precise and formalized descriptions of software life cycle activities. Based on my reading software process network represents a multiple interconnected task chains that transform object to what it should be and build a finish product.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
3. The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755068,00.html
The Systems Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development
(RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed.
http://www.startvbdotnet.com/sdlc/sdlc.aspx
3 Systems Development Models
The Waterfall Model
The Waterfall Model is the earliest method of structured system development. Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with providing the theoretical basis for other Process Models, because it most closely resembles a “generic” model for software development.
The Waterfall Model consists of the following steps:
• System Conceptualization. System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
• Systems Analysis. This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
• System Design. Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).
• Coding. Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
• Testing. As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.
Problems/Challenges associated with the Waterfall Model
Although the Waterfall Model has been used extensively over the years in the production of many quality systems, it is not without its problems. In recent years it has come under attack, due to its rigid design and inflexible procedure. Criticisms fall into the following categories:
• Real projects rarely follow the sequential flow that the model proposes.
• At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.
• Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.
Iterative Development
The problems with the Waterfall Model created a demand for a new method of developing systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products which are produced at the end of each step (or series of steps) can go into production immediately as incremental releases.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Critic
One traditional process model is the waterfall model and according to Schacchi was only accepted just until the early 1980s because of its lack of functionality. The waterfall model is said to be the easiest model to understand and I do believe with this. It is easily understood because it provides a sequential succession of phases to be followed but then it is not that reliable. Just seeing a figure of the flow of the waterfall model you would just see the sequence of phases to go through but the problem here is it would not go through a cycle but just have a one-way flow just like a waterfall. Because of its simplicity it would only be suitable for certain classes of software development and would not work well with the other software like interactive applications. This model does not have risk management and management during the life cycle and mainly document-driven or code-driven that is why it would not work as smoothly as the other models.
Prototyping Model
The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front .
When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified.
There are a few different approaches that may be followed when using the Prototyping Model:
• creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like,
• development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system (depicting proposed screens, reports, relationships etc.), or
• use of an existing system or system components to demonstrate some functions that will be included in the developed system.
Prototyping is comprised of the following steps:
• Requirements Definition/Collection. Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
• Design. Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
• Prototype Creation/Modification. The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
• Assessment. The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
• Prototype Refinement. Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
• System Implementation. In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system.
Problems/Challenges associated with the Prototyping Model
Criticisms of the Prototyping Model generally fall into the following categories:
• Prototyping can lead to false expectations. Prototyping often creates a situation where the customer mistakenly believes that the system is “finished” when in fact it is not. More specifically, when using the Prototyping Model, the pre-implementation versions of a system are really nothing more than one-dimensional structures. The necessary, behindthe- scenes work such as database normalization, documentation, testing, and reviews for efficiency have not been done. Thus the necessary underpinnings for the system are not in place.
• Prototyping can lead to poorly designed systems. Because the primary goal of
Prototyping is rapid development, the design of the system can sometimes suffer because the system is built in a series of “layers” without a global consideration of the integration of all other components. While initial software development is often built to be a “throwaway, ” attempting to retroactively produce a solid system design can sometimes be problematic.
Variation of the Prototyping Model
A popular variation of the Prototyping Model is called Rapid Application Development (RAD).
RAD introduces strict time limits on each development phase and relies heavily on rapid application tools which allow for quick development.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Critic
The last model I am to discuss is the Rapid Prototyping Model. This model cannot be used in robust application. It is convenient because it is fast or rapid from the word itself. It can replace the specification phase but not the design phase because it mainly relates to the designing phase. In the waterfall model every phase should directly right at the first time while rapid prototyping changes frequently and the discarded if wrong.
The Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping
Models, and introduces a new component - risk-assessment. The term “spiral” is used to describe the process that is followed as the development of the system takes place. Similar to the
Prototyping Model, an initial version of the system is developed, and then repetitively modified based on input received from customer evaluations. Unlike the Prototyping Model, however, the development of each version of the system is carefully designed using the steps involved in the Waterfall Model. With each iteration around the spiral (beginning at the center and working outward), progressively more complete versions of the system are built.6
Risk assessment is included as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be halted. For example, if a substantial increase in cost or project completion time is identified during one phase of risk assessment, the customer or the developer may decide that it does not make sense to continue with the project, since the increased cost or lengthened timeframe may make continuation of the project impractical or unfeasible.
The Spiral Model is made up of the following steps:
• Project Objectives. Similar to the system conception phase of the Waterfall Model.
Objectives are determined, possible obstacles are identified and alternative approaches are weighed.
• Risk Assessment. Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs.
• Engineering & Production. Detailed requirements are determined and the software piece is developed.
• Planning and Management. The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer.
Problems/Challenges associated with the Spiral Model
Due to the relative newness of the Spiral Model, it is difficult to assess its strengths and weaknesses. However, the risk assessment component of the Spiral Model provides both developers and customers with a measuring tool that earlier Process Models do not have. The measurement of risk is a feature that occurs everyday in real-life situations, but (unfortunately) not as often in the system development industry. The practical nature of this tool helps to make the Spiral Model a more realistic Process Model than some of its predecessors.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Critic
Another traditional process model is the spiral model which is suggested by Barry Boehm in 1988. Spiral model is still regarded as one of the best model because it is a combination of the prototyping model and the waterfall model and comprises the strengths of the other software models.. According to Boehm, "the major distinguishing feature of the Spiral Model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties" [Boehm 1988]. This model is better that the waterfall because it may allow iteration. The main concept of the spiral model is that it aims to minimize risks with the use of repeated use of prototypes so that certain changes may be applied over again if there appears a problem upon the development.
Before any software is made there is a process to go through to make it work. It passes through phases to make it as faultless as possible for the users. It might go through planning, coding, developing and other steps before one can create a software system work. This now relates to process model. If I were to define it from the word itself it is a flow of steps to organize the building or engineering of a software system. Having a process model help us to strategies what should be done for the system and help create the algorithm of the program.
For a better understanding and for a more concrete definition, here follows the definition of process model from Wikipedia.
“Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.”
Software process models represent a sequence of activities or events that symbolize strategies for accomplishing software development. Process models can be used to develop more precise and formalized descriptions of software life cycle activities. Based on my reading software process network represents a multiple interconnected task chains that transform object to what it should be and build a finish product.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
3. The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755068,00.html
The Systems Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development
(RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed.
http://www.startvbdotnet.com/sdlc/sdlc.aspx
3 Systems Development Models
The Waterfall Model
The Waterfall Model is the earliest method of structured system development. Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with providing the theoretical basis for other Process Models, because it most closely resembles a “generic” model for software development.
The Waterfall Model consists of the following steps:
• System Conceptualization. System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
• Systems Analysis. This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
• System Design. Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).
• Coding. Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
• Testing. As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.
Problems/Challenges associated with the Waterfall Model
Although the Waterfall Model has been used extensively over the years in the production of many quality systems, it is not without its problems. In recent years it has come under attack, due to its rigid design and inflexible procedure. Criticisms fall into the following categories:
• Real projects rarely follow the sequential flow that the model proposes.
• At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.
• Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.
Iterative Development
The problems with the Waterfall Model created a demand for a new method of developing systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products which are produced at the end of each step (or series of steps) can go into production immediately as incremental releases.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Critic
One traditional process model is the waterfall model and according to Schacchi was only accepted just until the early 1980s because of its lack of functionality. The waterfall model is said to be the easiest model to understand and I do believe with this. It is easily understood because it provides a sequential succession of phases to be followed but then it is not that reliable. Just seeing a figure of the flow of the waterfall model you would just see the sequence of phases to go through but the problem here is it would not go through a cycle but just have a one-way flow just like a waterfall. Because of its simplicity it would only be suitable for certain classes of software development and would not work well with the other software like interactive applications. This model does not have risk management and management during the life cycle and mainly document-driven or code-driven that is why it would not work as smoothly as the other models.
Prototyping Model
The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front .
When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified.
There are a few different approaches that may be followed when using the Prototyping Model:
• creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like,
• development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system (depicting proposed screens, reports, relationships etc.), or
• use of an existing system or system components to demonstrate some functions that will be included in the developed system.
Prototyping is comprised of the following steps:
• Requirements Definition/Collection. Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
• Design. Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
• Prototype Creation/Modification. The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
• Assessment. The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
• Prototype Refinement. Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
• System Implementation. In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system.
Problems/Challenges associated with the Prototyping Model
Criticisms of the Prototyping Model generally fall into the following categories:
• Prototyping can lead to false expectations. Prototyping often creates a situation where the customer mistakenly believes that the system is “finished” when in fact it is not. More specifically, when using the Prototyping Model, the pre-implementation versions of a system are really nothing more than one-dimensional structures. The necessary, behindthe- scenes work such as database normalization, documentation, testing, and reviews for efficiency have not been done. Thus the necessary underpinnings for the system are not in place.
• Prototyping can lead to poorly designed systems. Because the primary goal of
Prototyping is rapid development, the design of the system can sometimes suffer because the system is built in a series of “layers” without a global consideration of the integration of all other components. While initial software development is often built to be a “throwaway, ” attempting to retroactively produce a solid system design can sometimes be problematic.
Variation of the Prototyping Model
A popular variation of the Prototyping Model is called Rapid Application Development (RAD).
RAD introduces strict time limits on each development phase and relies heavily on rapid application tools which allow for quick development.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Critic
The last model I am to discuss is the Rapid Prototyping Model. This model cannot be used in robust application. It is convenient because it is fast or rapid from the word itself. It can replace the specification phase but not the design phase because it mainly relates to the designing phase. In the waterfall model every phase should directly right at the first time while rapid prototyping changes frequently and the discarded if wrong.
The Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping
Models, and introduces a new component - risk-assessment. The term “spiral” is used to describe the process that is followed as the development of the system takes place. Similar to the
Prototyping Model, an initial version of the system is developed, and then repetitively modified based on input received from customer evaluations. Unlike the Prototyping Model, however, the development of each version of the system is carefully designed using the steps involved in the Waterfall Model. With each iteration around the spiral (beginning at the center and working outward), progressively more complete versions of the system are built.6
Risk assessment is included as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be halted. For example, if a substantial increase in cost or project completion time is identified during one phase of risk assessment, the customer or the developer may decide that it does not make sense to continue with the project, since the increased cost or lengthened timeframe may make continuation of the project impractical or unfeasible.
The Spiral Model is made up of the following steps:
• Project Objectives. Similar to the system conception phase of the Waterfall Model.
Objectives are determined, possible obstacles are identified and alternative approaches are weighed.
• Risk Assessment. Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs.
• Engineering & Production. Detailed requirements are determined and the software piece is developed.
• Planning and Management. The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer.
Problems/Challenges associated with the Spiral Model
Due to the relative newness of the Spiral Model, it is difficult to assess its strengths and weaknesses. However, the risk assessment component of the Spiral Model provides both developers and customers with a measuring tool that earlier Process Models do not have. The measurement of risk is a feature that occurs everyday in real-life situations, but (unfortunately) not as often in the system development industry. The practical nature of this tool helps to make the Spiral Model a more realistic Process Model than some of its predecessors.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Critic
Another traditional process model is the spiral model which is suggested by Barry Boehm in 1988. Spiral model is still regarded as one of the best model because it is a combination of the prototyping model and the waterfall model and comprises the strengths of the other software models.. According to Boehm, "the major distinguishing feature of the Spiral Model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties" [Boehm 1988]. This model is better that the waterfall because it may allow iteration. The main concept of the spiral model is that it aims to minimize risks with the use of repeated use of prototypes so that certain changes may be applied over again if there appears a problem upon the development.
0 comments:
Post a Comment