Intro to Software Engr
Intro to Software Engr CS 3300
Popular in Course
Popular in ComputerScienence
This 0 page Class Notes was uploaded by Alayna Veum on Monday November 2, 2015. The Class Notes belongs to CS 3300 at Georgia Institute of Technology - Main Campus taught by Staff in Fall. Since its upload, it has received 16 views. For similar materials see /class/234099/cs-3300-georgia-institute-of-technology-main-campus in ComputerScienence at Georgia Institute of Technology - Main Campus.
Reviews for Intro to Software Engr
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 11/02/15
Definitions Testing Verification has the program been implemented y 7 Chapter 23 7 quotAre We building the program right Chapter 22 7 Process question 7 testplandoc Validation has the correct program been implemented 7 quotAre We building the right programquot 7 Product question Testing the process of executing a program With the intent of detecting problems 7 Can be used for either veri cation or validation Error a human mistake made in the 6 alpha lest informal inhouse early process of constructing software gem lest fomal out0fh0use pm F aullbugdefecl the manifestation of an release errOl39 in the SOftW l39C Sanity check quickanddirty just before Failure a condition arising when executing shipping software produces an incorrect result Approaches to Verification Testing exercising software to try and generate failures lnspectionrevieWWalkthrough systematic group review of program text to detect faults Formal proof proving that the program text implements the program specification execution vs nonexecution based testing Comparison Testin r purpose create failure 7 danger inadequate test set Proof 7 p p ve correctness r d onlyselect Jnctionality Review 7 p detect defects 7 d informal Debugging r p nd and correct defects 7 d local xes and new defects Testing and SAN Lifecycle Acceptance Testing Integration Testing CI E 1 o 3 E on Regression Testing The Vmodel of development Adequacy criterion Test sets like programs are designed to accomplish a goal7to adequately exercise a program Adequacy criterion precise deterministic rule for deciding beforehand how you will know when to stop testing 7 Altematively7how do you know when you have a good suite of tests Examples 7 Every statement executed 7 Every requirement tested 7 Errorbased tests 7 eliability level Test Flaming Adequacy criterion For each test 7 What is the objective ofthe test 7 How will you know if the objective has been met 7 The input to use 7 Expected output 7 The actual output obtained Test Organization T op down test the main routine plus stubs then replace a stub by code more stubs and integrate 7 Advantage always have a complete s stem 7 Disadvantages stub generation meaningless output Bottom up test modules separately then combine 7 Advantages meaninng values generated 7 Disadvantages hides integration problems until late Incremental try to add one piece at a time so that you now what to concentrate on if a failure occurs Types of Testing Black box functional look only at the behavior of the program White box clear box base the testing on the structure of the code Black Box Generate tests to check desired program functionality Without knowledge of how the code works 7 Equivalence partitioning divide possible test sets into equivalence classes for valid and invalid inputs and run one test from each class 7 Bound value anzdyxix look for test cases on the boundaries of the equivalence classes 7 Exhaunive tearing run every possible input infeasible 7 Functional tearing construct tests directly from the requirements document R m if the tests are randomly generated with a distribution that corresponds to the expected usage ofthe program then you can get a reliability estimate such as MTBF to use as an adequacy criterion White Box exhaustive not possible in reality alone not sufficient 7 forgets about specs 7 doesn t check iflogic is awed 7 are proper equations used White BOX testing Coverage Adequacy based on control or data ow properties Statement coverage of all executable statements exercised during testing 7 Testing a statement once does not guarantee that the statement is correct 7 Some statements may be quotdead codequot Branch coverage of conditional branches exercised 7 do tests exercise both the then and el 5e branches of h eac l f statement even if one of them is empty Condition coverage of boolean expression constituents exercise 7 Was there a test that caused the then branch to be taken because aWas true Because b Was true if a H b then else Path coverage ofprograrn paths executed infeasible or impossible Datalow coverage measures 7 For a given use ofa variable and for each assignment to that variable that could quotreachquot that use is there a test that causes execution to proceed from the assignment to the use Errorbased testing Look for evidence ofa speci c class of errors such as off y one known to occur in pro rarns 7 error checklists may be languagedependent Adequacy is the extent of possible error opportunities evaluated Mutation analysis fault seeding 7 Generate a set of program variants mutants containing a comprehensive set of intentionally seeded bugs representative of typical errors 7 Compose tests sufficient to distinguish the generated programs from the original kill the mutant nonfunctional testinganalysis Performance Load Usability Security Portability Maintainability complexity metrics Coding standards you Will maybe look at performance load reliability usability need operational model instrumentation of the code still need quanti able adequacy criteria 7 When are you done testing When do you determine that system meets this nonfunctional requirement stresstesting valuable even if conditions outside of operational mo el Guideliness quotProgram testing can best show the presence of errors but never their absence Dijkstra 50 of program development effort goes into testing primarily integration testing quotThe act ofdesigning tests is one ofthe most effective error prevention mechanisms known Beizer Effective testing requires a different attitude destructive from effective programming constructive Test functional as well as nonfunctional requirements Test that a program does what it is supposed to do and doesn t do what it isn t supposed to do Test how well the program deals with erroneous input and internally detected failures Tests shouldbe traceable to customer requirements Tests should be planned before testing begins 80 of defects will be traced to 20 ofmodules Exhaustive testing is not possible To be most effective testing should be conducted by an independent third party Include Release Test 7 product deployment installation con guration Regression testing 7 rerun tests after updates or integration 39 identify critical regression tests 7 man need to automate scripts testing tools harness of tests and inpquutput data 7 one reason which makes maintenance costly Beware not to consider outputs resulting from previous test Nonexecution based Verification Statistics show reduces time ofexecution based testing Informal reviews 7 desk checks 7 unstructured driven by author upon eg minor changes to noncritical components walkthroughs 7 more structure involve a meeting major change to noncritical component Formal reviews 7 inspections formal well de ned structure assigned roles to participants de ned entryexit criteria for phases in inspection process User Interface Design 7 Chapter 16 Importance of U1 Design System users often judge system quality by its interface rather than its functionality Computers are now being used by many nontechnical people Implementers are o en poor judges of interface acceptability and effectiveness Poor user interface design can decrease the effectiveness productivity and safety of software intensive systems The interface to one tool may psychologically quotinterferequot with the interface to another Hence tool integration is important A significant percentage of application code is f devoted to the user Inter ace As much as 70 for some classes of applications Human Factors Limited capacity of human shortterm memory need to quotchunkquot 111100001111111110 111100001111111110 7 4 1 7 7 6 741776 Human Factors Limited capacity of human shortterm memory nee to quotchunkquot People make mistakes People have different interaction preferences People perform differently novice knowledgeable intermittent frequent expert Performance improves as people learn to use a system Many human factor aspects of UI are measurable There exist some experimental results but technology is being driven by the market rather than by research Measurable Human Factor Goals Time to learn Speed of performance Rate of errors Subjective satisfaction Retention overtime Aspects of U1 Deslgn Menu selection formats Click letters numbers pulldown popup cascading Message wording terminology abbreviations syntax Character set fonts highlighting color Devices Keyboards displays cursor control virtual reality Modalities Sound touch position sensor Response times display rates Online help tutorials training and documentation Error interaction and recovery Structure of U1 Presentation display of computer generated or processed information Dialog controlled solicitation of user input Application interface the two way translation of processing requests between the user interface software and application software Presentation Issues Information visualization digital vs analog text vs graphs Animation Use of colors fonts highlights Text vs graphics Static vs dynamic Ambient vs requested Dialog Modeling Some interfaces are modal That is their state affects allowable user interactions Modality can be dealt with differing amounts of emphas39s A vs emacs on command entry Disabled options in dialogs Separate windows colors rds State transition machinesdiagrams can often be used to model Ul dialog Elements of Dialog Models For computer application software the user typically interacts by entering text pressing mouse buttons or pressing a function ke The user may be selecting from a menu filling in a form or answering a question Hence a model of a user interface needs indicate not only the states and their transitions but also the contents of the menus the layout of the forms and the details of the questions A user action often translates into a request for computation So a dialog model must specify the requested computations Application Interface User requests are initiated by Ul events such as keystrokes or mouse c ic s GUI software normally features an event loop that interprets events and invo es corresponding functionality Parameters may be passed to the program either by push or pull Resultant values must be displayed by the GUI Interaction Style lmmcl39nn Main advxnhgu Main diadvxnhgu Appmm39nn y mmle Dmct pm and intuitive Maybe mi ta implement vim games mampilhtmn imam Onlysmlnble wime there is a CAD systems Easyt lzam wsulmetaphnxfaxtasks and abjects Mann Awids Isexemx Slawfaxexpnemednsexs whsigmni selecnan Little Iypmg required Canbecame camp ex ifmany pllrpuse systems menu aptinns Farm mm 5mm am entry Takes up slat afscnen space Stuck camml Easy tn lzam Causes pmblzms wime isquot Pusan lmn e l apnans dn mt matchthz farm cessmg mid Cammmd Pawer ll and mini Hard ta leam Opxatmg sgstzms language Paar exmx management Cammmd and mum systems Natural Accessible tn casual qumxes mm typing lnl39annanan language Isexs Ami language understanding retrieval systems Easlly extended systems are unreliable Other interaction styles Programming language Handwriting Voice speech Drawing UI serVices Macro commands hot keys accellerators Undo redo Cut copy paste Online help tutorials Default values User confirmation customization files Command files UI integration ere is now an abundance of applications available to typical computer users Similar sounding operations in separate applications may cause very different actions to be taken Hence integration speeds learning and reduces errors It can also increase productivity by allowing separate applications to interact effectively Aspects of integration Presentation integration same message format highlighting and WIMP styles across applications Dialog integration message and error interactions data entry and menu control behaving similarly Semantic intergration identical actions in separate applications behaving identically Integration metaphors One way that integration has been facilitated in the past is through the use of a consistent metaphor for all applications This includes applications written by the user Examples of metaphors that have been used are the following Desktop Window manager Screen editor Spreadsheet Data base UI Principles Know the user support transition Organize application interface around tasks Limit reliance on human memory Provide easy ways to do common things Common look and feel integration use of metaphor Engineer for error Measure evaluate refine More UI principles Principle Dmripvim User emth The theme shuuld use tarms and cuncepts which are drawn mm the Expenmce ufthe peepie whu will wake must use ufthe system Cehsslehey eehstslehl m that Wherever pusslble e a cummhle Upem ns shuuld hesenwlemh the memy surprise Usa39s Shuuld neverbe surprisedbythe behavmur Ufa system Recuvembihty The inta ce Shuuld include meehamsms m alluw users tn racuva39 hem armrs User guldance The theme shame pmvlde mmth feedback when mars uncur and pruvlde cuntmrsensmve usa help facilities User dlv sty The mlexfeee shame pmvlde appmpnate mtmctmn raethues fur m mt types ufsystemuser Error message guidelines Product Be as speci c and precise as possible Be constructive indicate what needs to be done 5 r Consider multiple levels ofmessages eep consistent grammatical form terminology and abbreviations Process Establish a message quality control group Include messages in the des39 Place all messages in a le Review messages during development Attempt to eliminate he need for messages Carry out acceptance tests Collect frequency data for each message Review and revise messages over ime Menu selection guidelines Use task semantics to organize menu structure single linear sequence tree structure acyclic networks and cyc ic networks Try to give posi ion in organization by graphic design numbering and itles ltems become titles in walking down a tree Items should be brief and consistent in grammatical style Permit typeahead jum pahead or other shortcuts Permit jumps to previous and main menu Use consistent layout and terminology Consider novel selection mechanisms and devices Consider response time and display rate impact Consider screen size Offer help facilities Dialog design guidelines Consistency Short cuts for experts Feedback Closure Be aware of common errors Simple error handling Undo Userdriven Reduced shortterm memory load Log user errors Feedback on selection Command language guidelines Create explicit model of objects and actions Choose meaningful specific distinctive names Try for hierarchical structure Provide consistent structure hierarchy argument order actionobject Support consistent abbreviation rules prefer truncation to one letter Ofter frequent users the capability to create macros Consider command menus on highspeed displays Limit number of commands and ways of accomplishing a task UI Design Process Ul design is an iterative process involving close liaisons between users and designers Core activities User analysis Understand whothe user is and what they will do with the system System prototyping Develop a series of prototypes for experimen Interface evaluation Experiment with these prototypes with users Analys1s Usab1l1ty Attnbutes Task analysis Attr39h t D 39 ti Models the steps Involved In completing a task I u 2 my Dquot Leamabxhty Huw lung dues make anew usa m becume pmaumve with Task breakdown looping conditionality Lhesystem7 concurrency speed ufupmm Huw Well dues the 5mm mum match the 5205ka mam 39 InterV39eW39ng and queStlonna39res Rubusmess HuwtulerantxsLhesystemufuseren39u Asks the users about the work they do Recuverabxlxty Huwguudsthesystematrecuvenng 39um userenurs7 Ethnography Adaptability Huw clusely isthe system bed in a single mudel ufwurk7 Observes the user at work UI Des1gn Technology Sample Evaluation Techniques Questionnaires for userfeedback Video recording of system use and subsequent tape evaluation Instrumentation of code to collect information about facility use and user errors The provision of code in the software to collect online userfeedback VWSIWYG Ulbuilding tools Widget libraries UI toolkits Special purpose graphics hardware Animation scripting Virtual reality Hypertext Groupware Libraries for 3D presentations Modelbased user interface generation User display presentation dialog application models Scripted GUI testers CS3300 Introduction to Software Engineering wwwccgatecheduclassesAY2006cs33007fall Ada Gavrilovska adacc 7 CCB 222 MW 7 12pm may change Daniel Popescu popescucc TBA text Software Engineering Sornmerville 7Lh ed newsgroup swiki reading assignments midterm and final 20 20 class participation project 55 7 you choose project 7 groups 35 members different roles 7 online templates 7 two entire iterations Software Engineering Build software 7 address requirements 7 adhere to specification 7 meet constraints beyond programming 7 includes documentation 7 testing amp validation 7 maintenance development of largescale software systems through an explicit methodology notation guidelines 7 not an art form or a cra lO5 Commercial software product 105 Mainframe operating system 102 Class exercise 3 programming 10 Term prOJ ect lt 6fo 104 Compiler o ware engineering effort lO7 Strategic Defense Initiative So ware engineen39ng i quot1 the application ofa Ws tzmatic dISL lplmzd azifiaazc approach to the dzvzlopment apzmtmn and maintznamz ofso ware that is the application ofzrigmzzrmg to so warz a appmachzs as m 1 H IEEE standard 51012 SE certi cation 1icensin ethics cod e con dentiality competence IP rights resource misuse toda e growth in dnvende e inPcmarke nil e olvmg r 7 systems with long hf Software Engineering y historically e So ware Crisisi 1 enakmgs e e deveiopment und ould not me ar nts far exceeded eosts and peetaaons eowboy metiiodoio gy e popu anzed atter 1968 NATO Software Engineering Conference t o ware eosts gtgt hardware eosts developed eeonomies is highly soitware pendent complexity and demand neity delivery and trust 7 missionbusiness e eonstantiy v e equirements needs operating eonditions eames How are we doing we Mai muid re used as deiweted 5119mm nni oi smi me l dehvered aiii ieet 55 5 mm sucuessmi v Sad 53 2 miiiieiii Sammie mid sortate imil eoiiid int ml ml he used atiet changes dehveral isisisumi si 95 miiiidn s hvare ised bul extensiveN termed nine Sammie devehpnenl mnimcis or titer ammuned Am 3 miiiioiii Growth in NASA Software Demand ms i n Data Processing in the US as a Percent of GNP Growth in Sy stems Signal Interfac es Cam exny SIZE ma 197a 1975 ma 1935 Ms W a ts i n are gen cos Dlsmb rmo BCA LRU System Resource ngandLaburatones I I I Aevudynamms Dlstr1but1on non Software 30 Software n velopm e a Software Veri cation 50 m gt 20 39 in conclusion 7 SE importantcritical discipline 7 concerned With costeffective software development 7 With a systematic approach using appropriate tools and techniques and resources and under speci c development constraints 7 Where delivered product should meet requirements speci cations projected timecost estimates and deliver mctionality Software Process A set ofactivities whose goal is the development or evolution of so ware Generic activities in all software processes are 7 Speci cation What the system should do and its development constraints 7 Development production of the software system 7 Validation checking that the software is What the customer Wants 7 Evolution changing the software in response to changing demands Software Process Model An abstract representation of a software process presented from a speci c perspective 7 Waterfall model 7 Iterative development 7 Componentbased software engineering 7 Agile process modelsExtreme Programming XP 7 Formal models 7 Rational Uni ed Process RUP determine order of phases of development and transition criteria Costs IllI d 5 5 5 o W DWI Mm MUM uquot WW 5 5 1 m WWIIquot minim Wan M a 9pm Dude WanMm Wm m kww o lo no so metmm munsun Colin Potts 3302 Winter 1997 Configuration Management Exercise Three Problems oGet into groups ofthree o Reading the cases Individually read w of the cases and answer the questions that follow it Describe the case and the general problem you think it illustrates to the others o Summarizing the cases You ll be called on to summarize a case you didn t read celin Polls Fall 2mm Configurations o A configuration is System a selection of so ware components that are built together to in a coordinated way celin Polls Fall 2mm Colin Potts CS 3300 Culln Putts FallZEIEIi The three problems 5 Eric W s 5 Bill Us 5 D amp J s shortcut final bug unfixed fixes or Multiple correCtion o Simultaneous copies 5 Shared data update 5 Multiple or A localized o The latest copies error has save always pervasive overwrites the diverge effect earlier ones Culln Putts FallZEIEIi Versions m E o Systemi amp SystemZ are versions Maybe SystEmZ isa revision or System or ma be it is a variation of Systeml fur a different 057 E233 m m o Systems ampthelrcornporlerlts may be versioned o versions may be pnysically separate orgenerated linked conditionally from a ommon source oblin Pulls FallZEIEIi Physical nature of versions Separate les A1 and A2 are in different files Deltas of revisions and branches of variations Ai through An are in one file tnat contains tne latest or earliest orbrancn point version and representation ofthe es e E g Urllgtlt sccs and Rcs Conditional compilation of variations gt At an don t eXlSI as source instead A contains directives to compile into Ai orA2 conditionally on environment e E g irder in c celin Polls Fall 2mm Design 7 Chapters 7 mainly 8 and 11 for now 7 sdsdoc 7 look at grading criteria as well Why Design good design gt good code easier to code test maintain change easier to understand impact of requirements changes large projects 7 divide across teams but have unifying design Software design So ware design is the process ofbuildi a program while satisfying a problem39s functional requirements and without violating its non functional constraints So ware design is normally broken into two p ases 7 high level or architectural design and 7 low level or detail design 7 SDS also asks you for U1 design Overview of Design Phase Input e speci cation e description ofwhatthe product is to do Output 7 design document 7 how the product is to achieve this Three main activities 7 architectural desi n deeompose the product into modules amp eoemeeuons bw mem e detailed design data structures chosen amp sigommms selecteddesigned e design testing make sure design is correct 7performedthroughoutphase Two key aspects of product to base desi n e actions amp data gt actiononented dameanented or hybrid 00 Design is the most creative phase 7 no set rules that you must follow 39 a lot of its success boils down to experience 7 instead there are principles and patterns which improve quality of design Architectural design Architectural design is the process of identifying and assigning the responsibility for aspects of functional behavior to various modules or components of a software system 7 Management of nonfunctional constraints must be determined 7 The communication interfaces among the components must also be speci red 7 sometimes can be derived naturally from the problem 7 some guidelines for select application domains in Chapter 13 Detail design Detail design is the process of specifying the logical behavior of each of the components 7 Algorithm selection 7 Data structure representation 7 combination of natural language pseudo code graphical representation Architectural models Used to document an architectural design Static structural model that shows the major system componen 5 Dynamic process model that shows the process structure of the system Interface model that de nes subsystem interfaces Relationships model such as a data ow model that shows subsystem relationships Distribution model that shows how subsystems are distributed across computers System organization system architecture Re ects the basic strategy that is used to structure a system CASE toolset architecture Three organizational styles are Widely used 7 A shared data repository style 7 A shared services and servers style 7 An abstract machine or layered style Film and picture library Version management system Architecture and nonfunctional properties Performance 7 Localize critical operations and minimize communications Use 39 ts ge ra er than negram componen Security 7 Use a layered architecture With critical assets in the inner layers Safety 7 Localize safetycritical features in a small number of sub systems Availability 7 Include redundant componenm and mechanisms for fault tolerance Maintainability 7 Use finegrain replaceable components Design Approach There are many approaches to design 7 Some espouse a particular point ofvieW as to how best to structure a system for example objectoriented design 7 Some of them are intended for a particular class of application eg realtime systems transactional 7 And some are intended for a specific part of the system structure such as userinterface design All approaches to design however contain three aspects that may be compared method representation and validation Design Method A method is a systematic sequence ofsteps that a design team uses to solve a pro m A method usually encourages a particular viewpoint on its users 7 For example the objectoriented design method encourages designers to view problems in terms of their constituent objects before Worrying out mctional be avior 7 data flow analysis better for apps With pipelined mctional rs components eg compile A method acts as a discipline on the designers forcing them to order their thoughts and activities in certain wa s All design methods must deal With the management of complexity typically by means of abstraction and re nemen Design Representation Nontrivial problems require design solutions to be expressed using some form of representation The design representation may be either graphical or textual but it is suf ciently formal that it can be checked for certain properties A design representation serves two audiences r The designers themselves That is the discipline imposed by ethod and th epresentation encoura es early detection of missing or inconsistent aspects of a proposed solution 7 Design representations are also read by other stakeholders These might be coders or testers Notably they might subsequently be maintainers trying to understand the designers original intent Design Validation Designs must be checked to assure that they ls accomplish their intended goa A good design method Will have an associated validation technique 7 measure the extent of coupling and cohesion to check the quality of its designs Design inspections walkthroughs and reviews are general techniques for assessing design quality They can successfully complement method speci c validation techniques Design Concepts Conceptual integrity coherence Coupling cohesion Information hiding Abstraction refinement Rationaletradeoffs Coupling the extent to which two components depend on each other for successful execution 7 Low coupling is good Cohesion the extent to which a component has a single purpose or function 7 High cohesion is good What does this mean 7 modules singlemindedselfcontained functions 7 address subset of requirements related to that function 7 simple interface limited interaction gt bugs are o en at interfaces 39 in terms of data control access to common contentdata 7 easy to ef ciently divide among team members 39 Information Hiding e Use of encapsulation to hide implementation details e Reduces intercomponent coupling thereby supporting subsequent maintenance Abstraction and Re nement e All design methods support the idea of abstraetion and refinement igns are expressed at various levels of detail With eoirespondenees between the levels vices abstraeaon meehanisms are used to refine a design at one level to alowerlevel e Abstractions inelude procedural data and eontxol abstraeuon 39 RationaleTradeoffs 7 Design decisions are explicit choices ofhow to ade offtwo nonfunctional aspects ofa design such as speed versus size d e Documentation of design decisions is called dzslgn rationale esign decisions shouldbe explicitly ocumented Modularity and Software Cost illellv iiiiiiiiiiiiiiiii rsiiini iii ximi in ship consider low couplinghigh cohesion r module shouldbe stand alone39 errors contained as mueh as possible consider requirements e ehange in requirements shouldminimize number of modules affected What Does this Program Do QEO REX WhileR2Y REREY QEQ1 How can you be sure Answer Integer division Compute quotient Q and remainder R ofX divided by Y for nonnegative integer X and positive integer Y Expressed as a function returning two results ltQ Rgt DIVIDEX Y Expressed as a relation of four variables Dmmmmqm Preconditions What must be true about the inputs to this program in order forthe program to successfully execute QEO REX whileR2Y Preconditions X 2 0 Y gt 0 The value of X is nonnegative and The value of Y is positive before execution begins QEO REX whileR2Y RERrY QEQ1 Postconditions What must be true about the program output variables after the program has completed execution Expressed in terms of input and output variables Assuming that it terminates Q E 0 REX whileR2Y QEQ1 RERiY Postconditions 39Ygt0A X20 QEO REX whileR2Y RERrY QEQ1 Postconditions YgtRZOA 39XZOA QZO QEO REX whieR2Y REREY QEQ1 Proof Plan Construct flow chart Annotate with preconditions Add invariants at intermediate program points based on the type of statement executed Postconditions Ygt0A 39XZOA Q20 QEO REX whileR2Y RE REY QEQ1 Postconditions YgtR20A 39XZOA 39QZOA XQYR 0E0 REX whileR2Y RE REY QEQ1 Flow Chan Assignment Conditional Loop Add Pre Conditions Simple Assignment The statement Q lt 0 guarantees that Q has the value 0 after it executes Moreover all othervariables remain unchanged Assuming no aliasing ofname Therefore the invariant after the assignment execution looks like X 2 0 Y gt 0 Q 0 Assignment 7nan xzmwu 1 Slightly More Complex Assignment The statement R lt X guarantees that R has the same value as X after it executes SoX20Ygt0Q0becomes X20Ygt0Q0RX We can also use the laws of algebra to manipulate other assertions The invariant is algebraically equivalent to R20Ygt0X20Q R Assignments nzuygtnxznunx x Conditionals A conditional statement like an assertion describes a possible program state Execution branches leading out of a conditional statement can be labeled with an assertion corresponding to the truth or falsity of the Boolean condition tested In the example the conditional tests the value of the expression R lt Y On the true Yes branch leading out 39om this test lt Y can be conjoined with the assertions coming into the conditiona 7 Likewise forthe No branch Conditional nynxznunx x YgtnYgtxan ygtnxzyxzn Loops Unlike other statements a loop like the one in the example has to deal with multiple incoming flows of control 7 That is there are two Ways at ehtehhg the lump m the start at the prugram one after guihg amuhu the loop at least uhce The statements ll lSlde the loop must be true in both circumstances fact they heed to be true ho rnatterhow rnahytirnes the loop l5 executed Forthis reason they are called oop Vivaisms Normally you think at lumps behaving differently eh each 7 But the assenieh has te stay the sam e That l5 the loop ihvahaht has to generalize over all iterations e The analysthas to invent this generallzatluh More on Loop Invariants A loop invariant has to satisfies three properties It must be true the rst time execution reaches it If it is true after some number n of iterations it must be true a er n It must be strong enough to imply the postcondition Recall the post condition we are looking for is YgtRZOAX20AQZOAXQYR We already have Y gt 0 Y gt R X2 0 Let39stryR2Ygt0X20Q20XRQIY xlnxn x quot n zunxznunx x Example Luann More Invariants Let39s try our first test Is the invariant true the first time through Condition before entering the loop 20Ygt0X20Q0XR Loop invariant R2Ygt0X20020XRQY R20andYgt0andR2YimpliesR2Ygt0 so we are okay so ar X still nonnegative IfQ equal to 0 then it is certainly greater than or ual to 39t Finally ifQ 0 and X R then X does equal RQ Y39R0 YR Assignments One Last Time The algorithm includes the assignment statement R R Y What is interesting about this statement is that the variable on the Iett hand side R also occurs on he r39 h 39 lfwe naively state that the postcondition is R R Y we would get nonsense Instead we must introduce a little more notation and perform some algebraic manipulations Assignments 2 Assume that the precondition for the assignment statement is X R 0 Y and the assignment statement Y First using the assignment statement annotate the Iett h n with a prime R39 r R39 can be read as the value ofR afterthe asstghmeht Then solve for R in terms of R39 R39 R Y gt R39 Y Substitute this expression R39 Y into the precondition for all occurrences ofR X R39 Y Q Y Simplify to produce the postcondition drop the prime XRQ1Y The general rule is to solve for the variable without the apostrophe and plug that expression into the precondition More CD Assignments mum x quot n Azniysnixzniu ix x xznixzniuznix I out LZIXZII YH QEI X n a my Last Assignment Let39s try this procedure on the last assignment statement in the algorithm 04 0 1 The precondition ofthe assignment is R20 0 0Q2OXRQ10Y Set 039 0 1 Solve for Q Q Q39 1 Substitute into precondition 20 X20Ygt0Q39120XRQ3911tY Simplify R20 X20Ygt0Qgt0XRQ Y CE Last Assignment xlnnbniu n Jzninnixzniu ix x unixzniuznix x m unxznivgtniuuix x a nut uuxzniygtniovix IL on Implications Notice that the postcondition of the last assignment labels the arc that re urns to the top 0 he loop We can now make our second test on the loop invariant if the loop has successfully executed n times is will the invariant ho on The postcondition on the nth execution on any executionis 0 Qgt0XRQY The loop invariant is R2Ygt0X20Q20XRQY Surely G gt 0 implies Q 2 0 And R 2 0 Y gt 0 and the loop condition R 2Y imply 2Ygt0 So the second test of our loop invariant is passed Third Test It is easvto come up Witn loop invariants After aII I i 2 is a loop invariant tis tme forevery execution of any loop s We need to nave loop invariants tnat impivtne program s post condmons Tnis is iust anothervvay of saving tnattne loop computation nas to contribute to tne producing tne intended program resuit Forthe example program tne resuit ofthe loop is R20 X20Ygt0QgtOXR We aiso know from tne conditionai tnat Rlt Y The program post condition is YgtR20X20Q20XQIYR Sothe tnird test is passed as Well Summary of Example Preconditions for successful execution Postconditions Examination of all possible paths Assignment Conditionals Invariant First execution In uction Strong enough Termination There is one other detail to clear up We have proved that the program is correct matches its specification assuming that it termina es We have to also prove this Assignments and conditions always progress so loops are the concern The way to show that loops terminate is to show that they always make progress Termination of Loops You can show that loops terminate using the following method De ne a function with the following properties rnain oftne function is tne set ofprograrn vanaples e The range of tne function is tne integers e The value computed pvtne function gets srnaller on every loop iteration e vvnen tne loop exit condition is reached tne function value is gative That is you are relying on the following property ofthe integers 7 Any constantlv decreasing series of integer values must eventually become negative Example Revisited What Jnction fcan be used as a termination function For the example program the termination function is fXYQRR Y While the loop continues to execute on the No branch 7 R zY R Y 20 r is always rlorlrrlegatlve e The line R4 R Y gets executed on every loop iteration e R and Y are potn positive at all tirnes e Tnis irnplies tnat R gets srnaller on every loop iteration e Consequentlvr gets reduced on every loop iteration On the Yes branch R ltY 2 R Y lt0 Dfis negative Consequently the loop must eventually terminate Another Exercise What Does this Program Do Assume B is a sorted vector of ints of length n lN 1 BI l BIeP II1 else I I1 P P1 endlf Answer P is the length of the longest plateau in B where a plateau is a sequence of equal values Process Assessment 7 Capability Maturity Model CMM Section 3 from SEI TR and followup CMMI Chapter 7 Assessment process Capability Maturity Model 39 D ve oped by the Software Engineering mg e 1 Institute SE1 with DoD fund Designed for large organizations doing routine developmen l 539 E a s a a Five levels of maturity Key processes Levels Level 1 Initial 7 Instable dependent on individuals a abl r 0 a a N 5 7 Policies use ofexpenence in planning discipline Level 3 De ned 7 Documentedprocess process group readiness and completion criteria Level 4 Managed 7 Quanataave goals data collection Level 5 ti 39 7 Continuous process improvement 3751quot W nanquot tvnsmu Ummn M i j Key Prueess Arms Level I 7 Initial Process Illde ned inputs cost and schedule overruns Unde ned process no repeatability Simple metrics of size staff effort Baseline for later comparison Level II 7 Repeatable Process Identi ed process inputs outputs and constraints No know e e of ow outputs are produced 39 Measures of size 7 Lines of eode LOC function points object andmethod eounts Requirements volatility E en o personne1 experience determines succe s 7 Domain appiieations development areiuteeture toois methods overall years ofexpenence turnover Key areas 7 Requirements management projectplanmng project oaeiung subcontractmanagement QA CM railed taged Level III 7 De ned Process Activities with de nitions and entry exit criteria Measures of requirements complexity design modules code complexity test paths pages of documentation So ware Engineering Process Groups SEPGs Quality metrics e Defects discovered error density for eaeh aetiVity area Key areas 7 Organizational proeess definition training program integrated management produet engineering intergroup eoordinataon peer reviews Level IV 7 Managed Process Feedback from early activities is used to set priorities for later stages Data collected roeess type extent of reuse produeaon and eonsumption when are defects deteeted testing eompletion eriteria use ofconflguratlon management ehange eontrol traeeability links module eompleaon rate Key areas 7 Process measurement and analysis quality management Level V 7 Optimized Process 39 Measures of activities are used to change the process 39 Analogy with Statistical Process Control SPC 39 Key Areas 7 Defect prevention technology innovation process change management mmsi tintinrmnnitmtit nitnsiiininimnsm tut intimii inn Assessment process Selection of assessment team Management commitment survey questionnaire t a E 2quot e Questionnaire analysis diseussions Witli proieets and funeuonal area representatives ndmgs feedback presentation Report Follow Up 7 uwn wr mm FtrlSmonth Assessment Details Assessment team has 68 members m E mem ave gt 10 years experience team leader has gt 20 years experience Assessment itselftakes 35 days Four or live projects are examined per organization 0 functional area representatives a a QA integration testing eoding andunittest requirements and design Implementation process takes 1218 months Followup at the end ofthis time Questionnaire 2 3 Data Management and Analysis Datamanagement deals With the gatlienng andretention of proeess tfaclllues an a s promptly obtained properly eneeked aeeurately enteredinto the database and etreetively man ed Analysis deals With the an yses ist dete ningtneoptimumu frevle sand resourees the tool mostneeded testing priorities andn edue tion 1 Has a managed and controlled process database been 39 23 established for process metrics data across all projects 232 Are the review data gathered during design reviews analyzed 233 Is the error data from code reviews and tests analyzed to determine the likely distribution and characteristics of the errors remaining in the product 34 Are analyses of errors conducted to determine their process related causes 235 Is a mechanism used for error cause analysis 236 Are the error causes reviewed to determine the process changes required to prevent them 39 237 Is a mechanism used for initiating error prevention actions 39 238 Is review ef ciency analyzed for each project 239 Is software productivity analyzed for major process steps CMIVI and CMIVH Integrated CMIVH CMIVH 7 staged and 7 continuous Continuous model permits different maturity levels in different process areas 7 DoD software focus on improvements in system speci cation veri cation and validation 7 Web development company focus on customer related processes SE1 TR on CIVIM So ware process assessments focus on identifying improvement priorities within an organization39s own so tvvare process Assessment teams use the CMM to guide them in identifying and prioritizing ndings These ndings along with guidance provided by the key practices in the CMM are used by a so ware engineering process group for example to plan an improvement strategy for the organization Software capability evaluations are focused on identifying the risks associated with a particular project or contract for building highquality so ware on schedule and within budget During the acquisition process software capability evaluations may be performed on bidders The ndings of the evaluation as structured by the CMM may be used to identify the risks in selecting a particular contractor Evaluations may also be performed on existing contracts to monitor their process performance with the intent of identifying potential improvements in the software process of the contractor Software process assessments and software capability evaluations differ in motivation objective outcome and ownership of the results project status reports grades due swiki submissions add team name amp members to group list then create and link to your team s page Project Flaming team amp project project plan scheduling cost estimates and risks Team common goalshared vision 7 project topic and project success diverse backgrounds 7 exploit strengths domain knowledge technical skills communicate 7 good amp bad news arrange meeting times work together 7 to resolve problemsbugs issues revise plan Member Roles ProjectManager 39 Documentation Principal Engineer CoordinatorTechnical Programmer wnter Technical Lead 39 TSSter Designer 39 Customer Support I Marketing 7 installation training maintenance Analyst small teams 7 not always separated roles Role distribution Project Manager 7 motivate 7 run amp organize meetings 7 status reports 7 produce project plan amp updates to plan Development Manager 7 development strate 7 timesize estimates ofproduct 7 lead designer 7 lead in preparing SRS interaction with customer Quality Manager 7 producing and tracking the quality plan alert to quality probl ms 7 lead in developing test plan for development integration and system testing test materials and runnin s 7 review proposed changes to baseline Ian 7 moderator for reviews recorder at team meetings Support Manager 7 support needs 7 resources facilities etc 7 prepare user documentation 7 monitor risk issues 7 manage source control system 7 maintain project les Everyone also acts as Development Engineer Project Flaming goals 7 on time delivery 7 within schedule 7 within budget using available resources 7 product satis es requirements main asset7rnanager s experience 7 but product is intangible no standard SE processes changes in requirements technologies tools personnel capabilities Management activities Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel selection and evaluation Report writing and presentations Project planning process Estaohsh the project constrarnts Make mmal assessments of the project parameters Denne project mnestones and dehverables whne project has not been completed or cancelled loop endloop raw up projec sche ule lmttate actwrtres accordmg to schedule Wart tor a whne Review project progress Revrse estimates of project parameters Update the project schedule Renegotrate project constrarnts and dehverables r problems anse then lmttate technical revtew and pOSSlble revrston end lf Project plan structure Use online templates Plan components include 7 Introduction 7 Project organisation 7 Risk analysis 7 Hardware and software resource requirements 7 Work breakdown 7 Project schedule 7 Monitoring and reporting mechanisms So How Do we Do this Spend time understanding the problem Estimate amount of effort required 7 Number of major Jnctions 7 Difficulty of each inction Develop schedule with built in safety nets 7 Increase estimates by some factor 7 Have a backup plan for worst case 7 Make sure schedule is realistic Revise schedule as project understanding increases Estimation hard to estimate well during the rst iteration 7 need constant improvements estimate dif culty of each task 7 size ofproblern LOC and 7 resource requirements gt personhours personmonths you have 5060 hours per credit perperson 7 provision for error understand tasks dependencies and ability for concurrent progress 7 objective minimize dependencies optimize concurrency for workforce identify milestones 7 1 per week milestone deliverable calendar estimate mm mm ludt 7 n Y my use mun milm d ables 7 lVlilestones in the RE process Beware Fuzzy Front End 7 minimize time here things may go Wrong 7 have contingency plans 7 have to do risk analysis and monitoring adding people to a late project may cost you more 7 overhead of extra communication productivity not always scalable in terms of number of people you and team members have other classesjobslives ArchitectureDesign Detailed Design CodeDebug Unit Testing Integration System Test Sample averages for small project 10 20 25 20 15 10 Scheduling understand dependencies 7 another activity cannot proceed build dependency graphs charts build in safety nets and backup plans identify critical path Scheduling mechanisms Process model Work breakdowns 7 Tasks and Milestones PERT Program Evaluation and Review Technique charts Gantt charts Task durations and dependencies Amway Dmu39en days Dependencies T1 8 T2 15 T3 15 T1 M1 T4 10 T5 10 T2T4 M2 T6 5 T1T2 NB T7 20 T1 M1 T8 25 T4 M5 T9 15 T3Ts MA T10 15 T5T7 M7 T11 7 T9 M6 T12 10 T11 MS Activity network PERT graph Activity timeline Gantt chart Staff allocation Cost Estimation 7 improves with time sue 15mm miwleled A r m m ngmms Hm so I i wpam 5 mam mm i 5 mm m R 5 as n as 1 Acre my 2 open im slit 3mg sin swim Feaslhmrv pm lem Detail new and Drag new and ms 725 Phasa and Milestones Metrics In estimation planning monitoring 7 cost dollars 7 duration months 7 effort personmonths 7 size LOC 7 quality of faults Size of Product 0 Lines of Code LOC or K delivered Source Instructions KDSI 7 different languages While lines hard to estimate size of code 7 source code only portion of effort 7 Weighted av optimistic pessimistic and most likely case 0 Function Points 7 functionality delivered by so ware 7 components 7input output user inquiries les interfaces weight for simple average complex 7 technical complexity 7 performance transaction mtes distributed communication 7 more in advanced SE classes 39 Files Flows Processes 39 3D Function Points 7 for real time sw considers state transitions in control process 39 Feature Points C OCOMO Constructive Cost Model 7 ongm y anyBoehm 3981 cumpunentrtased mulrbased PC realrtime turmruund su ware develupmenL COTS mmumunsimesrufrcude vs funcnun pumtsvs abjects 7 objective 7gt estimate eosts Within 20 70 ofthe time Database ofproduct histories calibrated annuall 7 calibration sgt adjustment ofweights to product eomponents circumstances language 1eve1 toois development stage Original COCOMO 7 Simple1ntermediate andDetailed Forms 7mm AthAFkAA 39 Input 7 estimate ofproject size 7 type of development 39 Output 7 effort and phase distribution tttttttte m http www1 Jsc nasa govbuZCOCOMO html Basic COCOMO 39 SM staff month 152 hours 24 KDSIl 5 r KDSI 1000 delivered lines of source code 39 TDEV development time in calendar months 25 SM 38 Risk Management 39 Risk Something that can go wrong 7 Often a result ofinadequate information 39 Assessment 7 Identify Analyze Prioritize 39 Control 7 Planning Resolution Monitoring Risk identification Technology risks People risks Organisational risks Requirements risks Estimation risks Risk analysis i Hit O39gamsahunal finannal pmblems fume reduchuns m the nnneet budget It 15 impussible tn recruit staffwith the skills required fur the meet Key Stats are in at critical times m the pruject shew nmnnnents that shuuldbe reused enntan defects which llrmt thenfunennnahty anges tn requirements that require ma en design revmrk are pennnsen The urgzmsatmn ls restxucmred su that di fa39ent management are respunsible an the meet Frnhzhi ty Luw High Muderate Muderate Muderate High Effects Catastxuphm Catastxuphm Senuus Senuus Senuus Senuus Risk analysis ii Risk The database mediums system Ennntpmnessas many hansaetmns pa secmd as expee tad The hme hemmed tn develup the su warels underesurmted CASE tuuls mnnnthemtegaten Cu uma39s an tn understand the mmaet er ments ehan 5 ma en The enne gma ated hy CASE tuuls ls lnef ml thahmty Mnneeate new Htgn Mnneeate Mudemte Mudemte Mudemte Effects 5mm 5mm Tulmble Tulmble Tulmble Risk Flaming Consider eachrisk and develop a strategy to t 39 manage Avoidance strategies 7 The probability that the risk Will arise is reduced Minimisation strategies 7 The impact of the risk on the project or product Will be red ced Contingency plans with that risk 7 Lfthe risk arises contingency plans are plans to deal A enda Types of maintenance Maintenance planning and the maintenance or change request MAINTENANCE Typical change requests and the management of their flow Technical impacts of change requests GA TeCh CS 3300 AY 2002 0 Metrics and the in uence of good SE Fall 2001 practice on maintainability Types of Maintenance Lientz amp Swanson Activity persondays Ammy Corrective 1Udstdth bl d39dtjfyth 5c 391 d39t t39t Fixing defect identificatlon and removal tunictinicnisiilnme m iddede 39 bagel n m Adaptive changes resulting from operating 2 Design mechanges 7 Testruncuonamyorchanges system hardware or DBMS changes 3 Pe fmm impact analysis 8 Perform regressiontesting Enhancing changes resulting from user requests Preventative 4 Impleth changesin some code 9 Release new baseline and report results changes made to the software to 5 Change SRSSDD STPcon gumu39on make It more maintainable nan Example of Corrective Maintenance Request Maintenance Request 78 The computations that ensue when the player changes the value of a quality are supposed to keep the total invariant but they do not For example if the qualities are strength 10 patience 08 and endurance 08 sum 116 and the player adjusts strength to 11 then the result is strength 11 patience 0 and endurance 0 which do not sum to 116 Rwud mm nnummn W W Exam le of Per ective Maintenance Re uest Maintenance Request 162 Modify Encounter so that the game begins with areas and connections in a coordinated style When the player achieves level 2 status all areas and connections are displayed in an enhanced coordinated style which is special to level 2 etc The art department will provide the required images Rwud mm nnummn W W Exam le of Per ective Maintenance Re uest Maintenance Request 162 Modify Encounter so that the game begins with areas and connections a coordinated style Impact ofMR 162 Add change appearance when player achieves new levels Accommodate ability to change global appearance use Abstract Factory design pattern Impact of MR 1 62 EncounterEnvironment Package Before Modification GameEnvironment GameCh aracter Add change appearance when player achieves new leve GameArea Accommodate ability to change gt global appearance use Abstract Factory design pattern Add interface methods for Layout package Add classes and methods EncounterEnvironment EncounterEnvironment O Rwud mm mm mmquot W Iquot I Rrud mm mm mmquot W Iquot I GameAreaConnection A Abstract F actor En viron men tFactor En vironmentFactorK Applied to getAreaO getArea Encounter buildConnection 0 getConnection A quoton n ection I LevellArea I I LevelZArea I I Level3Area I 4 K Abstract 1 F actory I I Am I LevellAreaConnection I I LevelZAreaConnection I Level3AreaC0nnecti0n Encounter 1x I I 1x quot I l Level3Fact0ry LevellFactory LevelZFactory Level3Fact0ry getAreaO getAreaO getAreaO getAreaO getAreaConnectionO getAreaConnectionO getAreaConnectionO getAreaConnectionO Ada ted 39nm So are En menu An Ob stronemedPer unveil Encl Brands 1 ZEIEIl with emss M i ration Plan for Levelbased Gra hics PhaseZ 39 39 quot 39 39 ofAretland Cannet on omterEnVlrmment Migration Plan for Levelbased Graphics Stan E xistingMudel Phasel Introduce Subclasses orAmr mdL 7 Cmn39m ma 4 L wellAreaComeaim Lwel re omectim L welSAre omectim Maintenance Metrics 0 Number oflines of code under maintenance Personmonths to perform various maintenance tasks Defect count Rwud rum HHHWWhn W to Phaw 1 TMrndllraTha ucollnta39Euvimnmeut r Wm gezAmro lV Rru rum nnnwmn W to Goal Question Note Selected Corresp ending Metrics How many problems are a eetmg the 514320sz 1 Fault densi How lang does rt take to fix a prob em 9 sure Average hme requlred to correct a defect from SW1 ofcorrechon Work 39Fau en duration Average hme from defect detechon to vahdaied corredlon satisfaction M ntenance Metr cs Clas ed by Goal Staff utilization per task type Average personrmonihs to a detect each detect and b repalr each detect 39Com 1 39 39zation Wm M W Average tlme CPUhme per defect bottleneerrsv Effort andtime spent per defect and per severity category o plannin Optimize elroit Where are rzsmuczs o reproducing customer finding and schedule bemg use 9 Yepo lng mm o re amng o en ancing N nimize defects nunue romsed Where are defects most lxkzly to l72ft71md9 13 Number of entries and exits per module 15 Cyclotomic complexity Vmodel again I Q How amp when can you assess a design Ace Lance De51gn Validation amp Integration 7 Desxgusdonwmn Testin I LHS gt RHS g 7 LHS 7 synthesis lst 7 RHS testing last CS 3300 7 LH87gtRHS istestplanmng as early as possible Colin Potts Design modules and interfaces rgt Integration Umt Lemng test lan review Detailed designmodule spec rgt Unittestplan amp T 39 1 eunan Ogy Luteglatiqlttesliug I Integration Testing sPrinciple Ctrl 7 Testing of subsystems as a Whole 7 Individual progam unitsmay work in isolation 7 Units assumed to have been tested and passed Burma not work madly E m I Review when integrated 2s Localization of defects 7 Systematic examination of a design usually by Defect maybemanifested not m m I a team at source but in a diffaent Program mt m failure I Inspection here 7 Special kind ofreview defCCl here Interface errors Testing strategies I Interface misuse I Testing strategies are Ways of approaching the 7 A calling component calls another component and testing process 39 its use of in interface e g parameters 7 Incremental testing ofbuild m me wroing order I 7 Usually combined in different parts of the system I Interface mlsundersmndmg I Examples illustrations from Sommerville 1995 7 A calling component embeds assumptions about the 7 Topdovm testing behaviour of the called component which are incorrect 7 Bonomup testing I Tlmmg errors 7 Thread testing 7 The called and the calling component operate a 7 Stress testing different speeds and outofdate information is accessed 39Jliigbailg39itesting Ctrl Test sequence E ca o Design Errors are difficult to locate UnitOriented Build 1 Module 1 UnitOriented Build 2 Module 1 UnitOriented Build 3 Module 1 2 3 4 Last Build Module 1 2 3 4 1 Understand the architecture decomposition 7 try to make architecture simple to integrate 2 Identify the parts ofthe architecture that each iteration will implement 7 build framework classes rst or in parallel u 7 if possible integrate continually 7 build enough UI to anchor testing an 7 document requirements for each iteration IntegratiOI 7 try to build bottomup 39lable when required amp Bu1lds 7 try to plan iterations so as to retire risks biggest risks rst 7 specify iterations and builds so that each use case is handled completely by one Decompose each iteration into builds if necessary Plan the testing review and inspection process 39 t d 5 5 Re ne the schedule to re ect the results 1 Decide extent of all tests Roadmap for 2 Integration and System Test 22 Perform iteration system and usability tests see ecn39an M I 3 Perform installation tests see semanth 4 Perform acceptance tests see section tint Roadmap for Integration and System Test RPG Video Game Architecture Packages built around the domain classes Packages built around the Framework layer 1 GameArtifacts C asses EncounterCharacters mfg application package Enmuntzrchamctzr A PlayerChzrzcter FureignChzrzcter PlayerQuzlityWinduw PlayerQuzlityWinduw Meeting Scheduler example Meeting scheduler example SyslzmServIces l Dialog Mgr Ti Locate Per on System Services Drain Ngr SystzmSemces SgstzmSemces Topdown testing I Start with the highlevels of a system and work your way downwards I Advantages 7 Works well with topdown development 7 Finds architectural errors early I Disadvantage 7 System relies on what s underneath May need too much lnfrastructure before testlng ls posslble tends toward blg7b ang lntegatlon Maybe dlfflcult to develop program stubs that you re con dent slmulate the ln astructure Bottomup testing e9 9 Q Q Q level N level N Level N level N level N mg g Q QA km level N71 Level N71 level N71 Meeting scheduler example rm J malang c user 39 D Y m r T Calzndar Locate Ll m y W Pen quoti 7 SystzmSemces Dela Wr SyeemSemes SystemSemces Bottomup testing I Start with the lower levels of the system and work upwar Advantages 7 Appropriate for objectoriented systems 7 Or where infrastructure components are critical I Disadvantages 7 Needs test drivers to be implemented May not slmulate eventual calllng envt 7 Does not nd major design problems until late in the process Thread Testing I Testing tests behavior so why base it on Structure 7 In topdown amp bottomup integration boxes modules arrows inter a 7 A thread is an execution trace that de nes a set of interrelated modules I boxes modules arrows interaction instances I Build systems around major use cases Relationship Between Use Cases Iterations and Builds Iteration 5 build 5 3