What is the purpose of system development model?
System development models are used to guide the analysis, design, development, and maintenance of information systems. Each is designed for a specific purpose or reason; most have similar goals and share many common tasks.. In order to ensure that cost-effective, quality systems are developed which address an organization’s business needs, developers employ some kind of system development model to direct the project’s life cycle.
3 System Development Models
Waterfall Model
Introduction
This model is sometimes referred to as the linear sequential model or the software life cycle.
The waterfall model is the earliest method of structured system development. Although it has come under criticism 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.
The waterfall model derives its name due to the cascading effect from one phase to the other. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design (validation), construction, testing and maintenance. Progress flows from the top to the bottom, like a waterfall.
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specifications, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.
Thus the waterfall model maintains that one should move to a phase only when it’s proceeding phase is completed and perfected.
Waterfall Development Phases:
Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.
The model consists of six distinct stages, namely:
1. In the requirements analysis phase
- 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.
• The problem is specified along with the desired service objectives (goals)
• 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.
- 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.
3. In the system and software design phase, the system specifications are translated into a software representation.
- 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?).
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.
- 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.
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 / Constructive Details
• 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
• it is easier to fix the specific components
• A further argument for the waterfall model is that it places emphasis on documentation
• simple approach
• provides a structured
• easily understandable and explainable phases and thus is easy to understand
• The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly.
Disadvantages / Criticism
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.
• The waterfall model is argued by many to be a bad idea in practice. This is mainly because of their belief that it is impossible for any non-trivial project to get one phase of a software product's lifecycle perfected, before moving on to the next phases and learning from them.
• Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product.
• Its rigid design and inflexible procedure.
• 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.
Spiral model
Introduction
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 lifecycle 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 model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
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. It was the first model to explain why the iteration matters.
Spiral Development Phases:
Depending on the model it may have 3-6 task regions (/framework a ctivities) our case will consider a ‘6-task region’ model.
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.
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. [More study needs to be done in this regard]
Agile Modeling
Introduction
Agile Modeling is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.
Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. No matter what development disciplines are required, each agile team will contain a customer representative.
Most agile implementations use a routine and formal daily face-to-face communication among team members. Agile emphasizes working software as the primary measure of progress.
Agile methods differ to a large degree in the way they cover project management. Some methods are supplemented with guidelines on project management, but there is generally no comprehensive support.
Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals. For more on them, see Flexible product development.
Agile Procedures:
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.
Agile values:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances
.
Comparisons
Agile methods lie on the "adaptive" side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the vaguer an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a time box.
Agile development has little in common with the waterfall model. The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.
The main problem with the waterfall model is the inflexible division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project.
Agile methods, in contrast, produce completely developed and tested features every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point up to the end, there is nothing to show for it beyond a huge resources bill. With the agile method, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.
In this respect, agile critics may assert that these features are not placed in context of the overall project, concluding that, if the sponsors of the project are concerned about completing certain goals with a defined timeline or budget, agile may not be appropriate. Proponents of agile development counter that adaptations of Scrum show how agile methods are augmented to produce and continuously improve a strategic plan.
Grounds of Agile
Agile home ground: Low criticality
• Senior developers
• Requirements change often
• Small number of developers
• Culture that thrives on chaos
Plan-driven home ground: High criticality
• Junior developers
• Requirements do not change often
• Large number of developers
• Culture that demands order
Agile methods
Some of the well-known agile software development methods:
• Agile Modeling
• Agile Unified Process (AUP)
• Agile Data Method
• DSDM
• Essential Unified Process (EssUP)
• Extreme programming (XP)
• Feature Driven Development (FDD)
• Getting Real
• Open Unified Process (OpenUP)
• Scrum
• Lean software development
Agile practices
• Test Driven Development (TDD)
• Behavior Driven Development (BDD)
• Continuous Integration
• Pair Programming
• Planning poker
• RITE Method
Measuring agility
While agility can be seen as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM) score projects against a number of agility factors to achieve a total. The similarly-named Agility Measurement Index, scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals. Another study using fuzzy mathematics has suggested that project velocity can be used as a metric of agility. There are agile self assessments to determine whether a team is using agile practices. While such approaches have been proposed to measure agility, the practical application of such metrics has yet to be seen.
Criticism
The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method, which can easily be tailored into agile processes.
Agile software development has been criticized because it may not bring about all of the claimed benefits unless utilized by above average programmers; above average programmers create above average code regardless of the method used.
References:
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
http://en.wikipedia.org/wiki/Waterfall_model
http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm
http://en.wikipedia.org/wiki/Spiral_model
http://scitec.uwichill.edu.bb/cmp/online/cs22l/spiralmodel.htm
http://en.wikipedia.org/wiki/Agile_Modeling
http://en.wikipedia.org/wiki/Agile_software_development
RSS Feed (xml)
No comments:
Post a Comment