Chapter 3 Prescriptive Process Models Moonzoo Kim CS Division of EECS Dept. KAIST moonzoo@cs.kaist.ac.kr http://pswlab.kaist.ac.kr/courses/cs550-07 Spring 2007 1
Generally did good job Comments on HW #1 HWs submitted earlier have better scores Start your HW as early as possible Do not write in a colloquial style, but a literary style Be careful to select proper words appropriate in technical context Spend time to find a right work by using thesaurus If you have a score less than 8/10, try to improve your writing skill Spring 2007 2
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 thrives 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? Spring 2007 3
The Waterfall Model Communication project init iat ion requirement gat hering Planning estimating scheduling tracking analysis design Construction code test Deployment delivery support feedback Which problems does the waterfall model have? Spring 2007 4
The Incremental Model increment # n Communicat ion Planning increment # 2 Can manage technical risks analysis design Const ruct ion code test Deployment delivery feedback delivery of nt h increment Communicat ion Planning increment # 1 analysis design Const ruct ion code test Deployment delivery feedback delivery of 2nd increment Communicat ion Planning analysis design Const ruct ion code test Deployment delivery feedback delivery of 1st increment Can be implemented with fewer people project calendar time Spring 2007 5
The RAD (Rapid Application Development) Model Team # n business m odeling data modeling process modeling Communication Team # 2 business modeling data modeling process modeling Construction component reuse automatic code generation testing Planning Requires sufficient human resources Modularization is prerequisite Global tuning is not possible Team # 1 business modeling dat a modeling process modeling Construction component reuse automatic code generat ion testing 60-90 days Co nst ruct io n component reuse automatic code generation t est ing Deployment int egrat ion delivery feedback Spring 2007 6
Evolutionary Models: Prototyping Communication communication Quick plan Quick plan Quick design Quick de sign Ex. Use-case design Ideally, the prototype serves to identify SW requirements Deployment Deployment Delivery delivery & & Feedback feedback Construction Construction of prototype of prototype Spring 2007 7
Evolutionary Models: The Spiral communication planning estimation scheduling risk analysis start modeling analysis design deployment delivery feedback construction code test Spring 2007 8
Still Other Process Models Component based development the the process to apply when reuse is a development objective Formal methods emphasizes emphasizes the mathematical specification of requirements AOSD provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process a use-case driven, architecture-centric, centric, iterative and incremental software process closely aligned with the Unified Language (UML) Spring 2007 9
The Unified Process (UP) Elaboration elaboration Inception inception inception Release software increment transition const ruct ion production Spring 2007 10
Inception phase UP Work Products 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. Oneormoreprototypes Incept io n Elaboration phase Use-case model Supplement ary requirement s including non-funct ional Analysis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot ype. Preliminary design model Revised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual Construction phase Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment Transit ion phase Delivered soft ware increment Bet a t est report s General user feedback Spring 2007 11
Quick Overview of SafeHome The SafeHome company has developed an innovative HW box that implements wireless Internet (802.11) connectivity in a very small form factor (the size of a matchbook). The idea is to use this technology to develop and market a comprehensive home automation product line. This would provide security functions, control over telephone answering machines, lights, heating, air conditioning, and home entertainment devices. The first generation of the system will only focus on home security since that is a market the public readily understands. Spring 2007 12
Spring 2007 13
Spring 2007 14
SafeHome: : Selecting a Process Model, Part 2 The players: Lee Warren: engineering manager Doug Miller: SE manager Ed and Vinod: : members of the SE team The conversation: (Doug( describes evolutionary process options) Ed: : Now I see something I like. An incremental approach makes sense and I really like the flow of that spiral model thing. That s s keeping it real. Vinod: : I agree. We deliver an increment, learn from customer feedback, replan,, and then deliver another increment. It also fits into the nature of the product. We can have something on the market fast and then add functionality with each version, er, increment. Lee: Wait a minute, did you say that we regenerate the plan with each tour around the spiral, Doug? That s s not so great, we need one plan, one schedule, and we ve got to stick to it. Doug: That s s old school thinking, Lee. Like Ed said, we ve got to keep it real. I submit that it s s better to tweak the plan as we learn more and as changes are requested. It s s way more realistic. What s s the point of a plan if it doesn t reflect reality? Lee (frowning): I suppose so, but senior management s s not going to like this they want a fixed plan. Doug (smiling): Then, you ll have to reeducate them, buddy Spring 2007 15