Self Assessment
CONTENTS Objectives
E- learning & Content Development
Our e-learning courses range from programming using .NET to personal productivity using Office. We also have the capability of custom-building exclusive content based on specific requirements. These modules include testing, grading and analyzing tools to create a complete learning experience.
Training
Our team of corporate trainers consists of experienced software professionals with a high level of skill set in a variety of technologies including Microsoft .NET, J2EE and the entire range of Microsoft server software. Our training programmes are designed to equip freshers and also to aid existing professionals in technology migration and upgradation.
TechCamp
Tech Camp is an absolutely unique skills development program that will make students instantly ready for the IT industry. Intensive training will be immediately followed by a REAL LIFE PROJECT supported by industry. The TechCamp model is designed to equip you with exactly what the industry is looking for.
Business Process Improvement
We provide a unique, data-driven approach to process intelligence to increase employee productivity. Starting with a capture agent that provides detailed application audit information from every end-user action, the software delivers comprehensive insight into process execution, including detailed individual tasks and activities. This technology can help in:
1. Cutting down cost of training and retraining employees 2. Identifying error prone and difficult tasks
3. Improving existing processes Our Clients
Our clients include Corporate Organisations (Microsoft, Savvy Soft, MGM Group, Parkin’s, Sutherland, Hardy Exploration, Ashok Leyland, Schlumburger, Aban, Greeva) and Academic Institutions (Anna University, IIT Madras, Madras University, SRM University, Dr. MGR University, VIT, SASTRA), Hindustan group, Dr. Mahalingam group, Thiagarajar, NIOT, PSG, CIT, RMK group.
Software Engineering
Notes
3.3 Summary
The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order.
There are many variations of the waterfall model depending on the nature of activities and the flow of control between them. In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirements analysis and project planning begins.
In incremental model, a series of releases called ‘increments’ are delivered that provide more functionality progressively for customer as each increment is delivered.
The first increment is known as core product. This core product is used by customers and a plan is developed for next increment and modifications are made to meet the needs of the customer. The process is repeated.
If the requirements are well understood and defines, and the project scope is constraint, the RAD process enables a development team to create a fully functional system with in very short time period.
3.4 Keywords
RAD: Rapid Application Development SRS: Requirement Specification document SDD: Software Design Description document
3.5 Review Questions
1. The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order. Justify this statement with diagram.
2. The requirements analysis phase is mentioned as “analysis and planning.” What have you understood from this statement?
3. “A good plan is based on the requirements of the system and should be done before later phases begin”. Discuss.
4. Why RAD reduces the development time and reusability of components help to speed up development? Explain.
5. Discuss why RAD is a linear sequential software development process model that emphasis an extremely short development cycle using a component based construction approach?
6. Critically analyze the various RAD Model Phases.
7. Briefly explain the incremental phases of the incremental model.
8. A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Comment.
9. Is waterfall model perspective model or incremental model? Explain with examples.
10. Subsequent iterations build on the initial software produced during the first iteration.
Why or why not? Justify your answer.
Notes
Answers: Self Assessment
1. coding 2. Planning
3. certification 4. development
5. complexities 6. manageable
7. common 8. product
9. increments 10. business rationale
11. prototyping 12. waterfall
13. iterations 14. RAD (rapid application development)
15. Incremental model
3.6 Further Readings
Books Rajib Mall, Fundamentals of Software Engineering, 2nd Edition, PHI.
Richard Fairpy, Software Engineering Concepts, Tata McGraw Hill, 1997.
R.S. Pressman, Software Engineering – A Practitioner’s Approach, 5th Edition, Tata McGraw Hill Higher Education.
Sommerville, Software Engineering, 6th Edition, Pearson Education.
Online links http://productdevelop.blogspot.com/2011/07/what-is-incremental-model-in-software.html
http://en.wikipedia.org/wiki/Rapid_application_development http://www.waterfall-model.com/
http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
Software Engineering
Notes
Unit 4: Evolutionary Process Models
CONTENTS Objectives Introduction
4.1 Evolutionary Process Model
4.1.1 Benefits of Evolutionary Development Model 4.2 Prototyping Model
4.3 The Spiral Model
4.4 Concurrent Development Model
4.5 A Final Comment on Evolutionary Models 4.6 Summary
4.7 Keywords 4.8 Review Questions 4.9 Further Readings
Objectives
After studying this unit, you will be able to:
Demonstrate evolutionary process models
Recognize Prototyping and Spiral Models
Describe the concurrent development model
Introduction
There is growing recognition that software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds, making a straight path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolves over time.
The linear sequential model is designed for straight-line development. In essence, this waterfall approach assumes that a complete system will be delivered after the linear sequence is completed.
The prototyping model is designed to assist the customer (or developer) in understanding requirements. In general, it is not designed to deliver a production system. The evolutionary nature of software is not considered in either of these classic software engineering paradigms.
Notes Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.
Notes
4.1 Evolutionary Process Model
The evolutionary model could be seen as one of the classic iterative activity based models. Each of the activities are handled in sequential order. After each of the iterations an evolutionary prototype is produced. This prototype is used to validate the iteration it’s just coming from and forms the basis of the requirements for the next phase. It’s usually applied when the requirements are unclear. There are two well-known forms: exploratory programming and prototyping.
Did u know? Who is Theodosious Dobzhansky?
Theodosious Dobzhansky defined evolution as the change in allele frequencies over time, a definition that appears to be more applicable to fine-scale population genetics questions than, necessarily, to between-species evolutionary relationships.
A prototype is used to discover the requirements and is discarded once the real system is developed. In exploratory programming a system is implemented and functionality is added iteratively.
One of the major problems here is the way of dealing with the development of software. The prototypes produced are being used in the next phase. Because many prototypes are produced that are redefined further and further, the whole software might become a patchwork of features.
Hence the whole approach might only work for small projects.
The waterfall model is viable for software products that do not change very much once they are specified. But for software products that have their feature sets redefined during development because of user feedback and other factors, the traditional waterfall model is no longer appropriate.
The Evolutionary EVO development model divides the development cycle into smaller, incremental waterfall models in which users are able to get access to the product at the end of each cycle.
Figure 4.1 Evolutionary Model
Software Engineering
Notes Feedback is provided by the users on the product for the planning stage of the next cycle and the development team responds, often by changing the product, plans, or process.
These incremental cycles are typically two to four weeks in duration and continue until the product is shipped.
4.1.1 Benefits of Evolutionary Development Model
Benefit not only business results but marketing and internal operations as well.
Use of EVO brings significant reduction in risk for software projects.
EVO can reduce costs by providing a structured, disciplined avenue for experimentation.
EVO allows the marketing department access to early deliveries, facilitating development of documentation and demonstrations.
Short, frequent EVO cycles have some distinct advantages for internal processes and people considerations.
The cooperation and flexibility required by EVO of each developer results in greater teamwork.
Better fit the product to user needs and market requirements.
Manage project risk with definition of early cycle content.
Uncover key issues early and focus attention appropriately.
Increase the opportunity to hit market windows.
Accelerate sales cycles with early customer exposure.
Increase management visibility of project progress.
Increase product team productivity and motivation.
!
Caution Large or complex projects can’t be handled this way as the software might become too hard to manage. Evolutionary process model consist of prototyping and spiral model.
Self Assessment
Fill in the blanks:
1. A process model that views development as a series of hills, each representing a separate loop of the ……… model.
2. Use of evolutionary model brings significant ………. in risk for software projects.
3. The ……….. and flexibility required by evolutionary model of each developer results in greater teamwork.
4. Feedback is provided by the users on the ……… for the planning stage of the next cycle and the development team responds, often by changing the product, plans, or process.
5. These incremental cycles are typically two to four weeks in duration and continue until the product is………...
Notes
4.2 Prototyping Model
Since waterfall model shows some constraints; we study prototyping to counter these problems.
The goal of a prototyping-based development process is to counter the first two limitations of the waterfall model. The basic idea here is that instead of freezing the requirements before any design or coding can proceed, a throwaway prototype is built to help understand the requirements. This prototype is developed based on the currently known requirements.
Development of the prototype obviously undergoes design, coding, and testing, but each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an actual feel of the system, because the interactions with the prototype can enable the client to better understand the requirements of the desired system. This results in more stable requirements that change less frequently.
Did u know? What is the basic idea of prototyping model?
The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements.
Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determine the requirements. In such situations, letting the client “play” with the prototype provides invaluable and intangible inputs that help determine the requirements for the system. It is also an effective method of demonstrating the feasibility of a certain approach. This might be needed for novel systems, where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements. In both situations, the risks associated with the projects are being reduced through the use of prototyping. The process model of the prototyping approach is shown in Figure 4.2.
Requirement
A development process using throwaway prototyping proceeds as follows. The development of the prototype starts when the preliminary version of the requirements specification document has been developed. At this stage, there is a reasonable understanding of the system and its needs and of which needs are unclear or likely to change. After the prototype has been developed, the end users and clients are given an opportunity to use the prototype. Based on their experience, they provide feedback to the developers regarding the prototype: what is correct, what needs to be modified, what is missing, what is not needed, etc. Based on the feedback, the prototype is modified to incorporate some of the suggested changes that can be done easily, and then the users and the clients are again allowed to use the system. This cycle repeats until, in the judgment of the prototypers and analysts, the benefit from further changing the system and obtaining feedback is outweighed by the cost and time involved in making the changes and obtaining the feedback. Based on the feedback, the initial requirements are modified to produce the final requirements specification, which is then used to develop the production quality system.
Figure 4.2: The Prototyping Model
Software Engineering
Notes In prototyping, for the purposes of requirement analysis to be feasible, its cost must be kept low.
Consequently, only those features are included in the prototype that will have a valuable return from the user experience. Exception handling, recovery, and conformance to some standards and formats are typically not included in prototypes. In prototyping, as the prototype is to be discarded, there is no point in implementing those parts of the requirements that are already well understood. Hence, the focus of the development is to include those features that are not properly understood. Because the prototype is to be thrown away, only minimal documentation needs to be produced during prototyping. For example, design documents, a test plan, and a test case specification are not needed during the development of the prototype. Another important cost-cutting measure is to reduce testing. Because testing consumes a major part of development expenditure during regular software development, this has a considerable impact in reducing costs. By using these types of cost-cutting methods, it is possible to keep the cost of the prototype low.
Prototyping is often not used, as it is feared that development costs may become large. However, in some situations, the cost of software development without prototyping may be more than the prototyping. There are two major reasons for this. First, the experience of developing the prototype might reduce the cost of the later phases when the actual software development is done. Secondly, in many projects, the requirements are constantly changing, particularly when development takes a long time. We saw earlier that changes in requirements at a later stage, during development, substantially increase the cost of the project. By elongating the requirements analysis phase (prototype development does take time), the requirements are “frozen” at a later time, by that time they are likely to be more developed and, consequently, more stable. In addition, because the client and use to get experience with the system, it is more likely that the requirements specified after the prototype will be closer to the actual requirements. This again will lead to fewer changes in the requirements at a later time. Hence, the costs incurred due to changes in the requirements may be substantially reduced by prototyping. Hence, the cost of the development after the prototype can be substantially less than the cost without prototyping; we have already seen how the cost of developing the prototype itself can be reduced.
Task In a group of four analyze this statement: “The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach.”
Prototyping is catching on. It is well suited for projects where requirements are hard to determine and the confidence in obtained requirements is low. In such projects, a waterfall model will have to freeze the requirements in order for the development to continue, even when the requirements are not stable. This leads to requirement changes and associated rework while the development is going on. Requirements frozen after experience with the prototype are likely to be more stable. Overall, in projects where requirements are not properly understood in the beginning, using the prototyping process model can be the most effective method for developing the software. It is an excellent technique for reducing some types of risks associated with a project.
We will further discuss prototyping when we discuss requirements specification and risk management.
Advantages of Prototyping
Users are actively involved in the development
It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.
Notes
Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.
Errors can be detected much earlier as the system is mode side by side.
Quicker user feedback is available leading to better solutions.
Disadvantages of Prototyping
Leads to implementing and then repairing way of building systems.
Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.
Self Assessment
Fill in the blanks:
6. Development of the ……….. obviously undergoes design, coding, and testing, but each of these phases is not done very formally or thoroughly.
7. Prototyping is an attractive idea for complicated and large systems for which there is no
……….. process or existing system to help determine the requirements.
8. After the prototype has been developed, the end users and ………. are given an opportunity to use the prototype.
9. Prototyping is often not used, as it is feared that development costs may become……….
10. Requirements frozen after experience with the prototype are likely to be more………..
4.3 The Spiral Model
As it is clear from the name, the activities in this model can be organized like a spiral that has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps done so far, and the angular dimension represents the progress made in completing each cycle of the spiral. The model is shown in Figure 4.3.
Each cycle in the spiral begins with the identification of objectives for that cycle, the different alternatives that are possible for achieving the objectives, and the constraints that exist. This is the first quadrant of the cycle (upper-left quadrant). The next step in the cycle is to evaluate these different alternatives based on the objectives and constraints. The focus of evaluation in this step is based on the risk perception for the project. Risks reflect the chances that some of the objectives of the project may not be met. The next step is to develop strategies that resolve the uncertainties and risks. This step may involve activities such as benchmarking, simulation, and prototyping.
Next, the software is developed, keeping in mind the risks. Finally, the next stage is planned.
The development step depends on the remaining risks. For example, if performance or user-interface risks are considered more important than the program development risks, the next step may be an evolutionary development that involves developing a more detailed prototype
The development step depends on the remaining risks. For example, if performance or user-interface risks are considered more important than the program development risks, the next step may be an evolutionary development that involves developing a more detailed prototype