Академический Документы
Профессиональный Документы
Культура Документы
Prescriptive Models
Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions If prescriptive process models strive for structure and order, are they inappropriate for a software world that increases on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
Planning
es timating sc heduling tra cking
Mode ling
analysis design
Const r uc t ion
code t est
De ploy m e nt
de liv e ry s upport f e e dba c k
Problems:
Sequential flow. Real projects rarely follow the sequential flow that the model proposes. Requirements. It is often difficult for the customer to state all requirements explicitly. It has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. Patience. The customer must have patience. A working version of the programs will not be available until late in the project timespan.
communication
10
Evolutionary Models
Prototyping
Customer is not clear about detailed input, output requirements Developer is unsure of a particular aspect of the design Allows better understanding of what is to be built when requirements are fuzzy It can be treated as a standalone process model or within the context of any one of the process models Serves as a mechanism for identifying software requirements.
11
12
13
14
15
Incremental Models
C o n s t r u c t io n
Team # 2
Mo d eling
b u si n e ss m o d e l i n g dat a m odeling p ro ce ss m o d e l i n g
Planning
Co nst r uct io n
De ploym e nt
int egrat ion deliv ery feedback
co m p o n e n t re u se a u t o m a t i c co d e g e n e ra t i o n t e st i n g
6 0 - 9 0 days
16
17
18
19
Incremental Models
Short development cycle High-speed adaptation of the waterfall model Uses a component-based construction approach Uses the generic framework activities Multiple software teams work in parallel on different functions Drawbacks: May not be appropriate if:
System cannot be properly modularized Technical risks are high High performance is an issue
20
21
22
23
Incremental Models
increment # n
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign
Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k
increment # 2
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign
Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k
increment # 1
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k
25
Incremental Models
Waterfall model applied in an iterative manner Delivery of an operational product with each increment Linear sequences in a staggered fashion. Each linear sequence produces deliverable increments of the software (e.g. word processing software)
Increment 1: file management, editing and document production Increment 2: More sophisticated editing and production Increment 3: Spelling and grammar checking Increment 4: Advanced page layout capability
27
28
communication modeling
analysis design start
deployment
delivery feedback
construction
code test
29
Evolutionary Models
The Spiral
Software is developed in a series of evolutionary releases First circuit around the spiral: product specification The project manager adjusts the number of iterations required to complete the software Circuit 1: Product specification Circuit 2: Prototype Circuit n: More sophisticated versions of the software Each pass through the planning region result in adjustments to the project plan
30
Evolutionary Models
The Spiral
It can be adapted to apply throughout the life of software Iterations around the spiral may be used to represent:
Is a realistic approach to the development of large-scale systems. It is not a panacea: it may be difficult to convince customers that the approach is controllable
31
Evolutionary Models
Concurrent Model
none Modeling act ivit y
Under development
Done
32
Evolutionary Models
Concurrent Model
Also known as concurrent engineering Consist of framework activities, SE actions and tasks, and associated states. The activity can be in one of the states at a time All activities exist concurrently but reside in different states.
Appropriate for system engineering projects where different teams are involved
33
Evolutionary Models
Final Comment
uncertain number of cycles required Most project management and estimation techniques are based on linear layouts
If evolution is too fast, the process will fall into chaos If evolution is too slow, then productivity could be affected
34
Evolutionary Models
Final Comment
We should prioritize the speed of the development over zero defects Extending the development in order to reach high quality could result in late delivery of the product.
It is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development. The challenge is to establish a proper balance between product parameters and customer satisfaction.
35
Component based developmentthe process to apply when reuse is a development objective Formal methodsemphasizes the mathematical specification of requirements AOSDprovides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Processa use-case driven, architecturecentric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)
36
elaboration
inception n Incep t io
inception
co nst r uct io n
Release
soft ware increment
t r ansit io n
p r o d uct io n
37
A framework for OO SE using UML Has its roots in the industrial experience within Ericsson Successor methodologies led by Rational and Objectory Status: a widely adopted industrial standard Uses the Unified Modeling Language (UML) Several OOA and OOD methods were proposed during the 80s and early 90s UP combine the best features of each individual method. Rational Corporation developed automated tools to support UML methods
38
Document a vision of the product Who are the expected users of the system What is the preliminary high-level architecture of the system What is the development plan and what are the development costs? Use cases are specified in detail Software architecture is developed and specified
2.
Elaboration
3.
4. 5.
Construction developing and testing code Transition corresponds to beta testing. Production deployment, monitored use of software
39
UP Phases
UP Phase s
Incept ion Elaborat ion Const ruct ion Transit ion Product ion
UP Work Products
Incept ion phase
Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary . One or more prot ot y pes
I nc e pt i o n
41