Object Oriented Software Engineering   View all facts   Glossary   Help

subject > process model

process model comparison table

Subject	name because	follow	form	have web site	have principles	correct	recommend	be	promote	is a kind of	suggest	require	describe	is an instance of	have some limitations	have philosophy	have weaknesses	has definition	use	be often supported by	represent	recognize	show	have steps
concurrent engineering model										process model								A process model in which each team works on its own component, typically following a spiral or evolutionary approach	the divide and conquer principle: Each team works on its own component, typically following a spiral or evolutionary approach
evolutionary model										process model								A process model that views development as a series of hills, each representing a separate loop of the spiral model			software development as a series of hills, each representing a separate loop of the spiral		that loops, or releases, tend to overlap each other: As testing and preparations for deployment of one release are underway, planning for the next release has already started development work tends to reach a peak, at around the time of the deadline for completion of implementation each prototype or release can take different amounts of time to deliver, and can take differing amounts of effort
extreme programming				www.extremeprogramming.org	The development team includes all the stakeholders Large requirements documents are replaced by short user stories which dictate project planning Releases are small and frequent Planning takes place just before the start of each iteration Scope, resources and time are the three project variables that can be changed. Management can only dictate two of these; the developers determine the third Quality should not be sacrificed In order to ensure high quality, design for testability is emphasized: Automated test cases are written before the software is developed			popular for small projects that involve uncertain, changing requirements and other sources of high risk	the use of CRC cards, a focus on simplicity, creation of 'spike' throwaway prototypes when difficult technical issues are encountered, merciless restructuring of code, frequent integration, programming in pairs, and continual improvement			the use of a particular notation and the production of documentation in particular formats	aspects of project management	process model		software developers should not need to be overworked, so overtime should not be needed		A process model and methodology that provides a disciplined approach to highly incremental and user-centred development of small projects		tools developed by the author of the process, or others
incremental development										process model								A process model in which the software is developed in a series of releases
opportunistic approach										process model							Since requirements and design are not worked out before implementing a system, the system might satisfy certain user needs, but reaching a high-level of user satisfaction will require many changes The software will deteriorate rapidly since it was not well designed There is no control of costs or schedule since there are no plans to work towards There are many undetected defects since there is no recognition of the need for systematic testing and other forms of quality assurance The cost of developing and maintaining software is very high	An unsatisfactory process model in which developers keep on modifying the software until they or their users are satisfied
phased-release model						some, but not all, of the problems of the waterfall model	the use of incremental development			process model	that after requirements gathering and planning, the project should be broken into separate subprojects, or phases which can be released to customers when ready						It suggests that all requirements be finalized at the start of development It downplays the importance of prototyping	An approach to incremental development in which, after requirements gathering and planning, the project is broken into separate subprojects, or phases
spiral model		principles: prototyping iteration risk analysis the idea that maintenance is simply a type of on-going development								process model	that the first thing to do before embarking on each new loop of the spiral is to decide what are the major difficulties to be handled							An incremental process model that explicitly embraces prototyping and an iterative approach to software development						a project undergoes a large number of cycles, starting with a small prototype each loop of the spiral follows a mini-waterfall process before each cycle of the spiral ends, a review is held subsequent cycles become official releases the cycling only ends when the system is finally retired
waterfall model	diagrams of it tend to look like cascading waterfalls		the foundation of many software development methodologies in use today		software engineers should work in a series of stages before completing each stage, they should perform quality assurance so that the next stage can be built on a good foundation software engineers sometimes have to step back to earlier stages when they discover a problem in a subsequent stage			better than the opportunistic approach		process model							if followed too closely: It has an overly rigid viewpoint that you should attempt to complete the entire specification before moving on to the design, and the entire design before moving on to implementation It makes no allowances for prototyping It implies that you can get the requirements right by simply writing them down and reviewing them, something that only works for simple, well-understood types of software development It implies that once the product is finished, everything else is maintenance	A process model in which the software engineer works in a series of stages				the importance of requirements, design and quality assurance

Next subject: process^2    Up: subject    Previous subject: process