What is System Development Model?
“Specify how the activities of development process are organized in the total system development effort.”
The term process model is used in various contexts. For example, in business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.
It is a framework for approaching strategy development.
It is typically used in structured analysis and design methods.
The current process model for data mining provides an overview of the life cycle of a data mining project. It contains the corresponding phases of a project, their respective tasks, and relationships between these tasks. At this description level, it is not possible to identify all relationships. There possibly exists relationships between all data mining tasks depending on goals, background and interest of the user, and most importantly depending on the data.
The software development process
• Investigate user requirements (analysis)
This phase is characterized by review and analysis of a functional document that describes the product. Requirements are reviewed and analyzed and requirements based test-cases are also generated at this stage.
• Clearly set out necessary features of system (specification)
• Create (or adapt) a suitable solution (design)
Design drafts are reviewed and finalized. Test cases for design integrity are also generated at this stage.
• Develop the proposed solution (implementation)
• Ensure that the solution solves the original problem (testing)
All test cases are finalized. The implementation is tested, first at the unit level, then following integration.
• Ensure that the solution works in context (integration)
The system is accepted for release to customers during this phase. This may involve some minimal final acceptance level testing.
• Modify the working solution as new requirements are identified (maintenance)
Regression testing, software evaluations and specifications for evolving the software are generated during this phase.
System Development Models
1.) Waterfall Model
The simplest possible model and therefore the least likely to be correct!
Model the software development process as a stately and sequential progression through the previously mentioned phases.
Traditionally, software development has been based on the "Waterfall" model, shown in figure 1, or its variations. There is a natural tendency among designers to proceed in a highly sequential, linear, and non-iterative manner. Designers tend to adhere to the old adage "Well begun is half done," by trying to make the analysis and design of the product as complete and precise as possible, before even embarking on its implementation. Every iteration, if any, to refine the design is viewed as an indicator of an insufficiency in the design. Tampering with the original conceptual design is discouraged, and though designers do iterate, they do so with a feeling of "guilt/incompetence."
The Waterfall Development Process
a.) Analysis and RequirementsSpecification
Initial Analysis :Developer analyses users requirement and, performs further investigation of requirements, produces developers version of requirements: System Requirements Document (SRD). The SRD is now a specification and part of the contract. Prepare project plan, including costing and schedule. Risk analysis.
Problem: Cost estimation.
Proposal :We are now in the realm of business contracts and the SRD is now a specification and part of the contract and will probably become a technical annex to a business proposal from developer to user.
Detailed Analysis :Starts once business proposal accepted by user.
• Up to this the developer will have been working unpaid.
• The main concern in `Initial Analysis' was the size of the project.
• This is real systems analysis.
• Specification of unambiguous and testable requirements. These will be the criteria for user acceptance, see
Acceptance Test.
• Risk analysis: identify risks, analyse, categorise/prioritise, produce backup-policies.
• Bad risks may need a Pilot Project to resolve them. See Spiral Model.
Problems:
• (Again) Difficulties in capturing requirements.
• The project can get stuck in the `analysis black-hole' [Peters, 1988].
• Difficulties in specifying requirements with precision and lack of ambiguity (testable). See Formal Methods.
Input: URD.
Outputs:
• Revised SRD.
• Tender or Quotation (proposal) from developer.
Milestones:
• Kickoff (project start).
• Software Requirements Review (a Deliverable).
b.) Design
High-Level Design :Decompose into subsystems/modules. Allocate to teams or individuals. Design tests for subsystems. Other names are Architectural Design, Preliminary Design, Product Design.
Input: SRD
Outputs:
• Architectural Design Document (ADD) (Deliverable).
• System Test Document (STD) (Deliverable).
Milestone: Architectural Design Review.
Problem: Does the decomposition technique provide really decoupled modules? I.e. Can teams work independently? The answer to these questions have massive implications for maintenance and reuse . See Object-oriented Analysis and Design.
Detailed Design :Decompose further into subsystems (or units or components) such that approx. one person can cope. Specify these subsystems. Design tests for (sub)subsystems.
Input: ADD.
Outputs:
• Detailed Design Document (DDD).
• Detailed Test Document (specifications and test data).
Milestone: Detailed Design Review.
c.) Implementation
Implementation and Coding :Code and test components - each programmer. Notice how far into project.
Outputs:
• Revised Detailed Design Document (DDD).
• Coded and Tested Software.
• Test documentation.
d.) Testing and Integration
Components and modules are brought together to form higher level systems. And tested. Repeat until you have a working system.
System Test
You should now have a working system! The full system is tested, in the developers environment.
Acceptance Test
Assess the system against the rquirements defined in SRD. Probably done under users control and supervision, and in their environment. Final payment hinges on this.
e.) Operation and Maintenance
Operations :The system gets used - hopefully!
Maintenance :Following [Pressman, 1997], we identify four types of development (change) neccessitated during maintenance.
Correction :Correct defects in the software: defects relating to incorrect requirements, or incorrectly specifications; defects from any of the construction phases - `bugs'.
Adaption :Adapt to changes in the original software and hardware platform. E.g. simpler: MS-DOS to Windows.
Complex: stand-alone to client-server.
Enhancement :Customer identifies additional requirements.
Prevention :After many sets of changes, the software `deteriorates', or otherwise becomes difficult to maintain. See Reengineering, Legacy Systems.
Problems:
• Programmers do not like doing maintenance.
• Maintenance needs a project of its own. It is very uncommon to include maintenance in a (development) contract.
• Cost estimation. Normal software cost estimation is difficult enough; most estimation models do not include maintenance.
• Design deficiencies make system impossible to extend. See Object-oriented ....
• Deterioration of legacy systems.
• When do you decide to start again from scratch, or reengineer?
Advantages:
Easy to understand, easy to use
Provides structure to inexperienced staff
Sets requirements stability
Good for management control (plan, staff, track)
Much better than ``all hands to the keyboards, spend half the budget on the latest hardware, with no planning''.
Misinterpretations may surface early. Errors found during operations may cost one hundred times or more to fix than if caught during Software Requirements Review.
Other problems may surface early; overspend; lack of feasibility; note 90of budget but the next 10
Limitations:
All requirements must be known upfront
System can be frozen before the design begins
Little opportunity for customer to preview the system (until it may be too late)
Maintenance. Much of what goes with the waterfall process. assumes `building something new'. Likewise reuse .
2.) Prototyping
Variations on the theme of "build something and see if that's what's wanted"
May be entire development process (exploratory programming) or merely replace the early design-implement cycle or may take an evolutionary approach (Gall's dictum).
The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users.
There are several steps in the Prototyping Model:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.
Advantages:
Customers can “see” the system requirements as they are being gathered
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Lower overall development costs when requirements change frequently
Limitations:
Prototyping can lead to false expectations.
Prototyping can lead to poorly designed systems.
3.) Iterative Enhancement Model
The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented.
At each step extensions and design modifications can be made. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model. Furthermore, as in prototyping, the increments provides feedback to the client which is useful for determining the final requirements of the system.
In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system.
Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available.
Advantages:
Easier to test
Provide Feedback
Limitations:
Provide incomplete system
Time consuming
High cost
4.) Spiral Model
Spiral model A software life-cycle model devised by Barry Boehm that encompasses a management strategy, a life-cycle development model, and risk assessment. The model takes its name from the spiral representation as shown in the diagram. Beginning at the center of the spiral, where there is limited detailed knowledge of requirements and small costs, successive refinement of the software is shown as a traverse around the spiral, with a corresponding accumulation of costs as the length of the spiral increases. Interaction between phases is not shown directly since the model assumes a sequence of successive refinements coupled to decisions that project risks associated with the next refinement are acceptable. Each 360° rotation around the center of the spiral passes through four stages: planning, seeking alternatives, evaluation of alternatives and risks, and (in the lower right quadrant) activities equivalent to the phases represented in waterfall or V-models.
The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.
The steps in the spiral model can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.
• Categorizes the many (and repeated) phases of software development into a number of cyclically repeated sectors
• Determining objectives/alternatives/constraints
• Risk analysis
• Prototyping
• Simulation/modelling/benchmarking
• Specification and design
• Planning
• System complexity and size grows with increasing radius, as do investment and risk
• Suggested by Boehm in 1988
• Still regarded as one of the best models
Advantages:
Risk assessment
Users see the system early because of rapid prototyping tools
Limitations:
Time spent for evaluating risks too large for small or low-risk projects
The model is complex
Risk assessment expertise is required
5.) Fountain model
Based on the waterfall model. But observes that the sequence always contains cycles. Reflects the fact that some phases cannot begin before others and that some phases are poorly delineated. A mental image to help visualize what actually happens in many real software development projects.
Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.
To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.
The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:
• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
But It Doesn't Work!
The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."
Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.
The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.
The necessity of an iterative approach to product development requires basic building blocks that do not undergo drastic mutation over iterations. This is an issue of the choice of the "Problem representation domain" in which the model life-cycle is to be represented. The solution to this is to adopt an object-oriented approach since objects are fairly stable building blocks that can be identified at a very early stage in the product life-cycle. In most cases, the analysis, design, and implementation stages can all be mapped into the object-oriented domain without having to make disjoint mappings into the "Structured Analysis Domain". And the "Fountain model," employed with much success in object-oriented projects, is ideally suited for modeling such projects.
Sources:
http://www.scribd.com/doc/15243782/System-Development-Model?autodown=ppt
http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/07.13.SWEng1/html/text.html
http://codecourse.sourceforge.net/materials/The-Waterfall-Lifecycle-Model.html
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755347,00.html
http://www.freetutes.com/systemanalysis/sa2-iterative-enhancement-model.html
http://www.encyclopedia.com/doc/1O11-spiralmodel.html
http://portal.acm.org/citation.cfm?id=227536
http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html
http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
http://en.wikipedia.org/wiki/Process_model
http://sensacom.com/web_glossary.html
http://www.crisp-dm.org/Process/index.htm
No comments:
Post a Comment