Boehm’s Spiral Process Model

-
Spiral model:
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral life-cycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

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

 •Objective setting
-Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed management  plan  is  drawn  up.  Project  risks  are  identified.  Alternative  strategies, depending on these risks, may be planned.

 •Risk assessment and reduction
-For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.

 •Development and validation
-After risk evaluation, a development model for the system is chosen. For example, throwaway prototyping may be the best development approach if user interface risks are dominant. If safety risks are the main consideration, development based on formal transformations may be the most appropriate process, and so on. If the main identified risk is sub-system integration, the waterfall model may be the best development model to use.
•Planning 
-The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.


•Main characteristics
 –Also a hybrid model that support process iteration.
–The process is represented as a spiral, each loop in the spiral representing a process phase.
–Risk is explicitly taken into consideration.

•Advantages
–Risk reduction mechanisms are in place.
–Supports iteration and reflects real-world practices –Systematic approach.

•Disadvantages:
–Requires expertise in risk evaluation and reduction.
–Complex, relatively difficult to follow strictly.
–Applicable only to large systems

•Applicability
–Internal development of large systems.

You can also view:
1. Rational Unified Process Model.
2. Rapid Application Development-RAD
3. Prototyping Process Model
4. Incremental Process Model
5. Component Based Software Engineering
6. Evolutionary Process Development Model
7. Waterfall Process Model
8. Software Process Framework Activity

Comments

Post a Comment

i am running my new blog at Knowledge Sharing (https://ksharing.info). please subscribe my new blog

Popular posts from this blog

Component Based Software Engineering

-
Image
•Main characteristics –Makes intensive use of existing reusable components. –The focus is on integrating the components rather than on creating them from the scratch. •Advantages –Reduces considerably the software to be developed “in-house”. –Allows faster delivery. –In principle, more reliable systems, due to using previously tested components. •Disadvantages –agreement in requirements are needed. –Less control over the system’s evolution •Applicability: –When there is a pool of existing components that could satisfy the requirements of the new product. –Emerging trend: integration of web services from a range of suppliers. You can also view: 1. Boehms Spiral Process Model 2. Rational Unified Process Model 3. Rapid Application Development-RAD 4. Prototyping Process Model 5. Incremental Process Model 6. Component Based Software Engineering 7. Evolutionary Process Development Model 8. Waterfall Process Model 9. Software Process Framework Activity
Read more

What is Non-functional requirements

-
Image
These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. i.e. Deactivate or delete record after 24 hrs Process requirements may also be specified mandating a particular programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. Types of Nonfunctional requirement Product requirement: Examples The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement:  Examples Users of the MHC-PMS system shall authenticate themselves using their health authority identity card. External requirement:  Examples The system shall implement patient privacy. Non-functional requirements implementation Non-functional requirements may affec
Read more

Software engineering Ethics Issues of Professional Responsibility

-
•Confidentiality –Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. •Competence –Engineers should not misrepresent their level of competence. They should not knowingly accept work which is out with their competence. •Intellectual property rights –Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. •Computer misuse –Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).
Read more