System Development Models or System Process Models
What is a software process model?
A software process model is an abstract representation of a software process. Each process model represents a process from a particular perspective so only to provide partial information about the process. Models, by their very nature, are simplifications, so a software process model is an abstraction of the actual process which is being described. Process models may include activities which are part of the software process, software products and the roles of the people involved in software engineering.
Software development activities
Planning
The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.
Implementation, testing and documenting
Implementation is the part of the process where software engineers actually program the code for the project.
Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible.
Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.
Deployment and maintenance
Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment.
Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.
Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control.
Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.
Traditional Process Model Software
Waterfall Model
The Waterfall model is one of the most used model of 70’s. It was proposed by Royce in 1970 as an alternative to Build and Fix software development method in which code was written and debugged. System was not formally designed and there was no way to check the quality criteria.
This takes the fundamental process activities of specification, development, validation and evolution and represents them as separate process such as requirements specification, software design, implementation, testing and so on.
This model, known as the waterfall, is an approach to development that emphasizes completing a phase of the development before proceeding to the next phase. In conjunction with certain phase completions, a baseline is established that "freezes" the products of the development at that point. If a need is identified to change these products, a formal change process is followed to make the change. The graphic representation of these phases in software development resembles the downward flow of a waterfall.
The principal stages of the model map onto fundamental developmental activities:
Requirements analysis and definition
The system’s services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as system specification.
Requirements analysis phase focuses on understanding the problem domain and representing the requirements in a form which are understandable by all the stakeholders of the project i.e. analyst, user, programmer, tester etc. The output of this stage is a document called Requirements Specification Document (RSD) or Software Requirements Specification (SRS). All the successive stages of software life cycle are dependent on this stage as SRS produced here is used in all the other stages of the software lifecycle.
System and Software Design
The system design process partitions the requirements to either hardware or software systems. It establishes overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationship.
System design phase translates the SRS into the design document which depicts the overall modular structure of the program and the interaction between these modules. This phase focuses on the high level design and low level design of the software. High level design describes the main components of software and their externals and internals. Low level design focuses on transforming the high level design into a more detailed level in terms of a algorithms used, data structures used etc.
Implementation and Unit Testing
During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.
Implementation phase transforms the low level design part of software design description into a working software product by writing the code.
Testing phase is responsible for testing the code written during implementation phase. This phase can be broadly divided into unit testing (tests individual modules), integration testing (tests groups of interrelated modules) and system testing (testing of system as a whole). Unit testing verifies the code against the component’s high level and low level design. It also ensures that all the statements in the code are executed at least once and branches are executed in all directions.
Additionally it also checks the correctness of the logic. Integration testing tests the inter modular interfaces and ensures that the module drivers are functionally complete and are of acceptable quality. System testing validates the product and verifies that the final product is ready to be delivered to the customers. Additionally several tests like volume tests, stress tests, performance tests etc., are also done at the system testing level.
Integration and System Testing
The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been meet. After testing, the system software is delivered to the customer.
Operational and Maintenance
Normally (although not necessarily) this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of the system units and enhancing the system’s services as new requirements are discovered.
After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected.
There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact, this is where the domain of requirements management comes in, which includes change control. The counter argument, by critics to the process, is the significantly increased cost in correcting problems through introduction of iterations. This is also the factor that extends delivery time and makes this process increasingly unpopular even in high risk projects.
This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management."
Often the supposed stages are part of review between customer and supplier; the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills.
Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.
Few business systems have stable requirements.
Appropriate only when the requirements are well-understood and changes will be fairly limited during the design process.
Applicability:
For large systems engineering projects where a system is developed at several sites.
Advantages and disadvantages of the Waterfall model are listed below:
Advantages
Easy to understand even by non-technical persons i.e., customers
Each phase has well defined inputs and outputs e.g., input to system design stage is Requirement Specification Document (RSD) and output is the design document.
Easy to use as software development proceeds
Each stage has well defined deliverables or milestones.
Helps the project manager in proper planning of the project
Disadvantages
The biggest drawback of Waterfall model is that it does not support iteration. Software development on the other hand is iterative i.e., while designing activities are being carried out, new requirements can come up. Similarly while product is being coded, new design and requirement problems can come up.
Another disadvantage of Waterfall model is that it is sequential in nature. One cannot start with a stage till preceding stage is completed e.g., one cannot start with the system design till all the requirements are understood and represented.
Users have little interaction with the project team. Their feedback is not taken during development.
Customer gets opportunity to review the product very late in life cycle because the working version of product is available very late in software development life cycle.
Model is very rigid because output of each phase is prerequisite for successive stage.
The Waterfall model also has difficulty in accommodating changes in the product after the development process starts.
Amount of documentation produced is very high.
The model in no way supports delivery of system in pieces.
The model is not suitable for new projects because of uncertainty in the specifications.
Incremental Model
The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.
The incremental model performs the waterfall in overlapping sections attempting to compensate for the length of waterfall model projects by producing usable functionality earlier. This may involve a complete upfront set of requirements that are implemented in a series of small projects. As an alternative, a project using the incremental model may start with general objectives. Then some portion of these objectives is defined as requirements and is implemented, followed by the next portion of the objectives until all objectives are implemented. But, use of general objectives rather than complete requirements can be uncomfortable for management. Because some modules will be completed long before others, well-defined interfaces are required. Also, formal reviews and audits are more difficult to implement on increments than on a complete system. Finally, there can be a tendency to push difficult problems to the future to demonstrate early success to management.
Incremental development advantages
1.Customer value can be delivered with each increment so system functionality is available earlier.
2.Early increments act as a prototype to help elicit requirements for later increments.
3.Lower risk of overall project failure.
4.The highest priority system services tend to receive the most testing.
Advantages
As product is to be delivered in parts, total cost of project is distributed.
Limited number of persons can be put on project because work is to be delivered in parts.
As development activities for next release and use of early version of product is done simultaneously, if found errors can be corrected.
Customers or end users get the chance to see the useful functionality early in the software development life cycle.
As a result of end user’s feedback requirements for successive releases become clearer.
As functionality is incremented in steps, testing also becomes easy.
Risk of failure of a product is decreased as users start using the product early.
Disadvantages
As product is delivered in parts, total development cost is higher.
Well defined interfaces are required to connect modules developed with each phase.
The model requires well defined project planning schedule to distribute the work properly.
Testing of modules also results into overhead and increased cost.
Spiral Model
The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.
The incremental model can be viewed as a spiral model. The spiral view illustrates one strength of the incremental model: resources can be held constant but the system size grows. The spiral size corresponds to system size, while the distance between the coils of the spiral indicates resources. In Figure 3, the distance between the coils does not change, which indicates that the amount of the resources being used is not changing.
Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be concerned with system feasibility, the next loop with system requirements definition, the next loop with system design and so on.
Each loop in the spiral is split into four sectors:
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 projects risks, a detailed analysis is carried out. Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.
Development and Validation
After risks evaluation, a development model for the system is then chosen. For example, if the user interface risks are dominant, an appropriate development model might be evolutionary prototyping. If safety risks are the main consideration, development based on formal transformations may be the most appropriate and so on. The waterfall model may be the most appropriate development if the main identified risk is sub-system integration.
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.
The important distinction between the spiral model and the other software process models is the explicit consideration of risk on the spiral model. Informally, risk is simply something which can go wrong.
A cycle of the spiral begins by elaborating objectives such as performance, functionality, etc. Alternative ways of achieving these objectives and the constraints imposed on each of these alternatives are then enumerated. Each alternative is assessed against each objective. This is usually results in the identification of the sources of projects risk.
The next step is to evaluate these risks by activities such as more detailed analysis, prototyping, simulation, etc. Once risks have been assessed, some development is carried out and this is followed by a planning activity for the next phase of the process.
There are no fixed phases such as specification or design in the spiral model. The spiral model encompasses other process models. Prototyping may be used in one spiral to resolve requirements uncertainties and hence reduce risks. This may be followed by a conventional waterfall development. Formal transformation may be used to develop those parts of the system with security requirements.
Advantages
The model tries to resolve all possible risks involved in the project starting with the highest risk.
End users get a chance to see the product early in life cycle.
With each phase as product is refined after customer feedback, the model ensures a good quality product.
The model makes use of techniques like reuse, prototyping and component based design.
Disadvantages
The model requires expertise in risk management and excellent management skills.
The model is not suitable for small projects as cost of risk analysis may exceed the actual cost of the project.
Different persons involved in the project may find it complex to use.
Spiral model is generally used for large projects with medium to high risk because in small projects it is possible that cost of risk analysis may exceed the actual cost of project. In other words, Spiral model is a practical approach for solving large scale software development related problems.
This can also be used if requirements of the project are very complex or if the company is planning to introduce new technologies. Some areas where Spiral model is successfully used are decision support system, defense, aerospace and large business projects.
No comments:
Post a Comment