Ad
More Related Content
What's hot (20)
Similar to Software Process Models (20)
Ad
Recently uploaded (20)
Ad
Software Process Models
- 2. NEED FOR MODELING A PROCESS • When a team writes down a description of its development process it forms a common understanding of the activities, resources and constraints involved in software development. • Creating a process model helps the team find inconsistencies, redundancies and removals in the process, as these problems are noted and corrected the process becomes more effective. • The model reflects the goals of development and shows explicitly how the product characteristics are to be achieved.
- 3. • Each development is different and a process has to be tailored for different situations, the model helps people to understand these differences.
- 4. PRESCRIPTIVE MODELS • Advocates an orderly approach to software engineering. • They prescribes – A set of process elements, – Framework activities, – Software engineering actions, – Tasks, – Work products, – Quality assurance and change control mechanism for each project.
- 5. WATER FALL MODEL • ADVANTAGES • The model suggests that software engineers should work in a series of stages. • Before completing each stage, they should perform quality assurance (verification and validation). • The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.
- 6. WHEN TO USE • Requirements of the complete system are clearly defined and understood. • Major requirements must be defined. • There is a need to get a product to the market early. • A new technology is being used. • Resources with needed skill set are not available • There are some high risk features and goals.
- 8. DISADVANTAGES • The model implies that you should attempt to complete a given stage before moving on to the next stage • Does not account for the fact that requirements constantly change. • It also means that customers can not use anything until the entire system is complete. • The model makes no allowances for prototyping. • It implies that you can get the requirements right by simply writing them down and reviewing them. • The entire functionality is developed and then tested all together at the end. • Major design problems may not be detected till very late. • The model implies that once the product is finished, everything else is maintenance.
- 9. INCREMENTAL PROCESS MODEL • Development occurs as a succession of releases with increasing functionality. • Combines elements of the water fall model applied in an iterative fashion. • Each linear sequence produces deliverables of the software. • Customers provide feedback on each release, used in deciding requirements and improvements for next release. • There is no “maintenance” phase – each version includes both problem fixes as well as new features.
- 10. ADVANTAGES • Customers get usable functionality earlier than with waterfall. • Early feedback improves likelihood of producing a product that satisfies customers. • The quality of the final product is better – The core functionality is developed early and tested multiple times (during each release) – Only a relatively small amount of functionality added in each release: easier to get it right and test it thoroughly – Detect design problems early and get a chance to redesign
- 12. DISADVANTAGES • Needs good planning and design. • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. • Total cost is higher than waterfall.
- 13. RAD DEVELOPMENT MODEL • RAD is an incremental software process model that emphasizes a short development cycle. • Using Component based construction approach.
- 14. Team # n M o d e lin g business m odeling dat a m odeling process m odeling Co n st ru ct io n com ponent reuse aut om at ic code generat ion t est ing Team # 2 Communicat ion Mo d eling business m odeling dat a m odeling process m odeling Planning Co nst ruct io n Team # 1 com ponent reuse aut om at ic code generat ion t est ing Mode ling business modeling dat a modeling process modeling Const ruct ion component reuse aut omat ic code generat ion t est ing 6 0 - 9 0 days De ployme nt int egrat ion deliv ery feedback
- 15. ADVANTAGES & DISADVANTAGES • • • • RAD reduces the development time Reusability of components help to speed up development. All functions are modularized so it is easy to work with. For large projects RAD require highly skilled engineers in the team. • Both end customer and developer should be committed to complete the system in a much abbreviated time frame • If commitment is lacking RAD will fail. • RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well.
- 17. • Business and product requirement often change as development proceed. • Software engineer need a process model that has been explicitly designed to accommodate a product that evolves over time. • Evolutionary models are iterative. • Enables software engineers to develop increasingly more complete version of the software. • There are two types of evolutionary development: – Exploratory development • Start with requirements that are well defined • Add new features when customers propose new requirements – Throw-away prototyping • Objective is to understand customer’s requirements (i.e. they often don’t know what they want, hence poor requirements to start • Use means such as prototyping to focus on poorly understood requirements, redefine requirements as you progress
- 18. ADVANTAGES & DISADVANTAGES • Advantages: – Happier customers since we help them by defining requirements – Flexibility in modifying requirements – Prototypes are very visual, hence no ambiguities • Disadvantages: – Hard to trace the “process” due to the ad-hoc nature – Systems are often poorly structured – Special tools and techniques may be required (for rapid development) that may be incompatible – Not cost-effective to produce documents
- 19. PROTOTYPING MODEL • Customer defines a set of general objectives for software but doesn’t identify the detail. • Assist the software engineer and the customer to better understand what is to be built when requirement are fuzzy.
- 22. • SPRIAL PROCESS MODEL A hybrid model where the development of the system spirals outward from an initial outline through to the final developed system. • Each loop in the spiral represents a phase of the software process. • Like the innermost loop might be concerned with system feasibility, next loop with system requirements, next loop with system design and so on. • Each loop in the spiral is split into four sectors: – Object Setting: set specific object for that phase. – Risk assessment and reduction. – Development and validation: select a development model based on risk levels. – Planning: decide if a next loop is required
- 24. ADVANTAGES & DISADVANTAGES • Advantages – Explicit consideration of risks (alternative solutions are evaluated in each cycle). – More detailed processes for each development phase. • Disadvantages – Cost is high. – Sometime difficult to implement or too time consuming.
- 26. COMPONENT BASED DEVELOPMENT • COTS (Commercial Off The Shelf) software components, developed by vendors who offer them as products can be used when software is to built. • Provides targeted functionality with well defined interfaces. • Incorporates many of the characteristics of spiral model. • Regardless of technology to be used, it must follow the steps like – – Available component based products are researched and evaluated for the current application.
- 27. – Component integration issues is to dealt. – A software architecture is designed to accommodate the components. – Components are integrated into the architecture. – Comprehensive testing is conducted to ensure proper functionality. • This model leads to software reuse. • Provides software engineers with a number of measureable benefits.
- 28. FORMAL METHODS MODEL • Comprises set of activities that leads to formal mathematical specification of computer software. • Enables a software engineer to specify, develop and verify a computer based system by applying mathematical notation. • Problems of ambiguity, incompleteness and inconsistency can be managed by this method. • Provides a base for verification therefore enable a software engineer to discover and correct undetected errors also. • But using this method in current scenario is time consuming and expensive.
- 29. • Extensive training is required for applying this method as few developers have the necessary background to work with this method. • It is difficult to use the models as a communication mechanism for technically unsophisticated customers.
- 30. ASPECT ORIENTED SOFTWARE DEVELOPMENT • Complex software are being implemented as set of localized features, functions and information content referred as components. • But it becomes crosscutting concerns when it flows across multiple systems. • Aspectual requirements define these crosscutting concerns that have impact across the software architecture. • AOSD provides a process and methodological approach for defining, specifying, designing and constructing aspects.
- 31. UNIFIED PROCESS MODEL • Comprises best features and characteristics of conventional software process models. • Emphasize importance of customer communication and streamlined methods for describing the customers view of system. • Phases of Unified Process – Inception = Involves customer communication and planning activities. – Elaboration = Encompasses the customer communication and modeling activities of the generic process model. Architectural representation using Use Case Model, Analysis Model, Design Model, Implementation Model and Deployment Model.
- 33. – Construction = Develops or acquires the software components that will make each use case operational for end users. – Transition = Software is given to end user for beta testing and user feedback reports both defects and necessary changes. – Production = Coincides with the deployment activity of process. The on going use of software is monitored, support for the operating environment is provided, and defect reports and requests for changes are submitted and evaluated.
- 34. Thanks