Software Dev Process
Software Dev Process CS 6300
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 6300 at Georgia Institute of Technology - Main Campus taught by Staff in Fall. Since its upload, it has received 61 views. For similar materials see /class/234114/cs-6300-georgia-institute-of-technology-main-campus in ComputerScienence at Georgia Institute of Technology - Main Campus.
Reviews for Software Dev Process
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 11/02/15
s ed Modeling Language unmeginggeiing Language MarvueanHangig l Why We Model Primary product of software development is good software that satisfies the evolving needs of its users Secondary product of software development is everything else eg great meetings documentation code But secondary is not irrelevant it enables the primary product unmeg Mggeiing Language Mary uean Hangig 2 Importance of Modeling 0 Suppose you want to build a dog house 0 But what if you want a house for yourself 0 Now what if you want a skyscraper 0 Many software projects that start out as dog houses end up trying to be skyscrapers eg Aristotle Analysis System unmeginggeiing Language MarvueanHangig a Importance of Modeling Models Help us communicate with the customer Help us to visualize a system as it is or as we want it to be Permit us to specify the structure or behavior ofa system Give us a template that guides us in constructing a system Help us to documentthe decisions we have made unmeg Mggeiing Language Mary uean Hangig 4 ObjectOriented Was a Catalyst for New Modeling Tech 39 ues 0 Many different contenders Grady Booch Rational Software Jim Rumbaugh OMT IvarJacobsen Use cases 0 Unified Modeling Language UML Combines Booch Rumbaugh Jacobsen s techniques Developed by Rational Rational now part of IBM wversion incorporates new features eg more formalism OCL unmeginggeiing Language MarvueanHangig a Things in the UML Structural Things I BehavioralThings ciass interaction interface state macnine collaboration 39 50559 We class Grouping Things iltage component Dec I I node AnnotationalThings unmeg Mggeiing Language Mary uean Hangig a Relationships in the UML Dependency directeddashedime Association soiidiihepossioiydirected mayoe adorned Generalization Solid line with hollow arrowhead Realization dashed line with hollow arrowhead unmegMegeiing Language MaNJeanHanuid 7 Diagrams 39 the UML 4 0 Class diagrams 0 Use case diagrams 0 Sequence diagrams 0 Collaboration diagrams o Statechart diagrams unmeg Megeiing Language Marv uean Hanuid g Putting the UML to Work The ESU University wants to computerize their registration system The Registrarsets Up the cumcuium fora semester one course may have multiple uurse unenh s students select 4 primary courses and 2 alternative courses a 1 a 9 E Q m o a o a 3 o g 3 to E a a notified so the student may be billed forthe semes er students may use the system to adddrop courses fora period oftirne after registra ion Professors use the system to receive theircourse orrenhg ters Users orthe registration system are assigned passwords which are used at iogoh validation unmegMegeiing Language MaNJeanHanuid a Use Case Diagrams o Derived from usecase analysis Jacobson 0 Answers WHAT about the system Shows actors and their interaction with system through use cases Describes the outside view of the system unmeg Megeiing Language Marv uean Hanuid in Use Cases gt o A use case describes a set of sequences that represents the interaction ofthings outside the system actors with the system itself It is a narrative textual description 0 Each use case has a unique name 0 Also called scenarios scripts and user stories unmegMegeiing Language MaNJeanHanuid u Actors a 0 An actor represents a role that a human hardware device or another system plays with the system Actor may appear in more than one use case Use case may have more than one actor User may have more than one role may be represented by more than one actor More than one user may play the same role Are not necessarily human unmeg Megeiing Language Marv uean Hanuid 12 What are the Actors for the ESU Registration System unlnegMggellng Language ManeanHarmlg Documenting Use Cases 0 Flow of events document created for each use case Written from an actor s point of view Details what the system must provide to the actor when the use case is exe 0 Typical contents Howthe use case starts and ends Normal ow of events Alternate ow of events Exceptional ow of events unlneg Magellng Language Marv uean Hanulg Maintain Curriculum Use Case Informal Paragraph The Registrar logs onto the Registration System and enters hisher password lfthe Registrar s password is v lid the System prompts the Registrar select the Jture semester The Registrar en ers the desir d semester The ystem prompts the Registrar to selectt e desired activity ADD DELETE REVIEW or QUIT lfthe Reglstrar selects ADD the course ls added to the Course Llst for the selected semester lfthe Reglstrar selects DELETE the course ls deleted from the Course Llst for the selected semester lfthe Reglstrar selects REVlEW the course lhrormatlorl lrl the Course Llst for the selected semester ls dlsplayed lfthe Reglstrar selects OUlT the use case ends unlnegMggellng Language ManeanHarmlg What are the Actors for the ESU Registration System gtO a lllng Svs12m unlneg Magellng Language Marvuean Hanulg 0 Format Informal usergenerated paragraph Structured Purposeintent Sequence of ActorActionObject triplets unlneg Magellng Language Marv uean Hanulg Documenting Use Cases cont d H Maintain Curriculum Use Case 0 Detailed use case with interactions 0 Structured version unlneg Magellng Language Marv uean Hanulg Mainta39 Curriculum Use Case This use case begins when the Registrarlogs onto the Registration System and enters hisherpassword The s stem Verifies that the password is valid El and prompts the Registrarto select the current semester or a future semester E72 he Registrareriters the desired semester The system prompts the Registrarto select the desired aotwity ADD DELETE REVlEW or OUlT ifthe aotwity selected is ADD the set Add a Course suofiow is performed ifthe aotwity selected is DELETE the s2 Delete a Course suofiow is perfo ifthe aotwity selected is REVlEW the sea Review Curriculum suofiow is performed 39 lithe activity selected is OUlT the use case ends unmediiedeiinetaneuaee MaNJEanHarruld w Use Case Diagrams 0 Actors Rule Mme 0 Use Case o Is the actor of ltltextendsgtgt Use Case B varies slightly from and extends Use Case A Generated by asking Whateoud go wrong ouestiohs That is A is the typical case B is an extension ofA iiiustratihg what happens ifsomethihg goes wrong wth A May be more than one extension to a Use Case unmediiedeiinetaneuaee MaNJEanHarruld zt o Extends I 0 Uses Uni edMudelmgLanguage MaNJEanHarruld 2n ltltUS Sgtgt ti o If several Use Cases share steps then factor out the common parts into a new Use Case and have the original ones use it 0 Think of as a subprocedure Uni ed Medeiine Laneuaee Mary Jean Haneid 22 The Role of Use Cases 0 Requirements elicitation 0 User prioritization 0 Planning assignment of use cases to incremen 0 Architectural analysis 0 System testing unmediiedeiinetaneuaee MaNJEanHarruld 23 aiiine Svs12m Use Case Diagram E Request course Rus12r 9 Maintain Scheduie 0 Maintain Curriculum E Uni ed Medeiine Laneuaee Mary Jean Haneid 24 Use Case Diagrams Creation Tips Es Give name that Focus each use case on communicates purpose communicating one Lay out elements to aspect of use case view minimize i 55 iiiies Focus on those aspects 39 U59 quot0 95 and r as essential forthat aspect visual cues to draw attention to important features Provide only essential detail unmegnggellng Language Mawueannanglg 25 A Use Case Template Use Case Template unmeg Mggelmg Language Marv uean Hanuld 2g Class Diagrams V gm 0 Derived from Object Modeling Technique OMT Rumbaugh 0 Answers HOW about the system Static structural view ofthe system Descri es classes etc in the system and their relationships unmegnggellng Language Mawueannanglg 27 Class Diagrams a A class diagram shows the existence of classes and their relationships in the logical view of a system UML modeling elements in class diagrams Classes and tnelrstructure and behavlor ASSOClathl l aggregatlol l dependency and lnnentance relatlonsnlps Multlpllclty and navlgatlon lndlcators 39 Role names unmeg Mggelmg Language Marv uean Hanuld zg Classes and Objects A class is a collection of objects with common structure common behavior common relationships and common semantics Classes are found by examining the objects in sequence and collaboration diagram Classes should be named using the vocabulary ofthe domain Namll lg standards created e g all classes are slngularnouns startlng wlth a capltal letter unmegnggellng Language Mawueannanglg 29 Class Diagrams E w A class is drawn as a rectangle with three compartments Class Name attrlbute attrlbute type lnltlal value uperatlumargrllst resultrtype Attributes and operations shown depend on desired level of detail unmeg Mggelmg Language Marv uean Hanuld an Class Diagrams RE tratlunlvlan er The structure bra class rs represented by rts attnbutes Attnbutes rnay be found by examining class dennrtrons tne problem requrrernents and by applyrng dornarn knowl dge Course III HE Att butes Each course offering has anumbe r location and time CuurseOfferlng unmeg Mggelrng Language Mary Jean Harrglg unmeg Mggelrng Language Maryuean Harrglg Operatl HS a Class D grams The benayror of a class rs represented by rts operatr s n amylme oberatrons rnay be round by examining rnteraetron arnong obleets SeneguleAl mnrn n stratrgn ggstugent c Mana r gurse student Si gent a L unmeg Mggelrng Language M up MaNJeanHanuld 33 unneg negerrng Language MaNJeanHanuld 34 Requot i i gm Mime Relationships provide a pathway for communication Dependency39 A using relationship in which a change in between 0 39 speci cation of one thing supplier may affect another a Four types of relationships are thing that uses it client but not necessarily the Dependency reverse Association Generalrzatron Realrzatron Most orten used to Show tnat one class uses anotner class as an argument rn tne srgnature or an op n A de end by rs shown as a dasned lrne borntrng trorn tne clrent to tne subblrer unmeg Mggelrng Language Mary Jean Harrglg unmeg Mggelrng Language Maryuean Harrglg ScheduleAluuvllhm ReglstratlonM anager uses SeneduleAlgorltnrn ln lts lrnplernentatlon ReglstratlonM anager passes Student rn er onlnednudellnetaneuaee Manueannanuld 37 Relationsh ps 4 Generalization A relationship between a general thing super class or parent and a more speci c kind ofthat thing subclass or child Also known as an lSrarkll ldro oran Era relatlonsnlp oolects orcnlld may be used anywhere tne parent may appeal but not the reverse nerallzatlon ls shown as a solld llne Wltn an open trlangle polntlng to tne superclass onlned Modellne taneuaee Marv Jean Hanuld Subclasses Student and Preressor lnnentrrorn superr elass ReglstratlunUser onlnednudellnetaneuaee Manueannanuld Relationsh39ps ll Association A relationship in which objects of one thing are connected to objects ofanother Arl assoclatlon ls shown as a llne connectlng tne related cl s a ses Adornrnents tnat applyto assoolatlons name multlpllclty unlneunauellnetaneuaee MawdeanHanuld 4n Relationsh s m Name An association can have a name used to describe the nature of the relationship The narne ls used as a label tortne assoclatlon edge A dlrectlon trlangle tnat polnts ln tne dlrectlon tnat tne narne snould be read ls used Wltn tne narne onlnednudellnetaneuaee Manueannanuld 41 Name Example Assuelatluns can be labeled vvlth names and arruvvs 99 Gets rusternorn onlned Modellne taneuaee Marv Jean Hanuld Relationsh39ps 0 Multiplicity Defines number of objects that participate in a relationship 39 Multiplicity is the number of instances of one class related to E instance oftne otherclass Foreach association and aggregation tnere are two muitioiicity decisions to make one foreacn end oftne relationship Uni EdMudEliHE Language MarvueanHangig 43 Multiplic39ty E mple 4 Edges are labeled Witn numbers tnere can be many Registratiganrmsi m rses but oniy one RegistratignManager unineg Mggeiing Language Marv uean Hangig 44 Relationships Aggregation A relationship between two classes in which one class represents a larger thing whole which consists of smaller things parts Aiso known as as a nasra reiationsnio A plain association is adorned Witn an open diamond at tne noie end Uni EdMudEliHE Language MarvueanHangig 4a Aggregation Example A Course nas a CuurseOffenng an uauksuauxil a unineg Mggeiing Language Marv uean Hangig Class Diagrams Creat39on T39ps Understand tne problem Don t feel you naye to use all ilteeoitsimoie initiaiiy tne constructs cnoose good class names concentrate on WHAT Look for binary associations Documem documem ignore muitioiicities initiaiiy documentl Refine untii complete and correct Uni EdMudEliHE Language MarvueanHangig 47 Interac n D39 grams o The use case diagram presents an outside view of the system 0 An Interaction diagram consists of a set ofobiects and tneir relationships inciuding messages tnat may be sent among them now use cases are reaiized as interactions among societies ofobiects consists of obiectsi links and messages unineg Mggeiing Language Marv uean Hangig Sequence D grams o A sequence diagram is an interaction diagram that emphasizes the time ordering of messages Piaoe obiects that participate at the too of the diagram across Xaxis Piaoe messages that these ooiects send and receive aiohg the Y axis in order of increasing tirne from too to bottom Use ooieot irreiihe verticai oasheo iihe to Show existence ofobiect overperiod ortirne Use rocus oroohtroi taii thih rectahgieto show period of tirne during which an ooieot is performing an action unmegMggeiing Language MaNJeanHaiiuid 49 Sequence D grams amp 3i Place objects that parti pate in the interaction at the top of the diagram along the X axis iegis1i tun Place object that i tiates the interaction at the left and place increasingly more subordinate objects to the right unmeg Mggeiing Language Marv uean Having an Sequence D grams a mm manaei unmegMggeiing Language MaNJeanHaiiuid El Sequence D grams it Use lifelines to show object s lifetime in interaction unmeg Mggeiing Language Marv uean Hangig 52 Sequence D39 grams gm Use r cus of conttol to show pe39riod of time that an object is performing an action eitherdirectly or indirectly unmegMggeiing Language MaNJeanHaiiuid 53 Sequence D39 grams i iiininiu iue malh i unmeg Mggeiing Language Marv uean Hangig a4 State Transquot 39on Diagram State Transquot 39on Diagram 0 Consists of multiple state diagrams One for each class with important dynamic behavior Shows states orooreots and aotryrtres performed rn states oonortrons undervvnlcn eyents cause transrtrons The actions that result hm a state change 39 quotWWW and no produced by even 0 Created for objects with significant dynamic behavior 0 Shows The life history ofa given class object The events that cause a transition from one state to another in that object unmegnegerrng Language MaNJeanHarruld 55 unmeg negerrng Language Mary Jean Harrerg 5o Terminology A r 0 States determined by the values of an object s attributes and links 39 have a duratlon ll r tlme Terminology W m 0 Events external stimuli 39 lnstantaneous rnay produce state transrtrons 39 may be assoclated wrtn actlvltles may Dl39Oduce aCthl VS Activities operations performed by an object 0 Conditions boolean functions of object values a take me to complete 39 guard State transltlons onnggnaggrng Language ManJean Harruld 57 onngg naggrng Language ManJean Harruld sg TermInology gt Graph cal Notatlon X 0 Actions instantaneous operations performed Eventattxscund acnunl by an object Triggered eventannum an event that pruduces a State transltlun Ordering of Actions antenna a state aotrons on rnoomrng transltlon exltlng a state entry ac lon an eyenttnatdues nut cause a state transrtrun 39 WW a d 9V9 ECHO 55 appropl39late 39 exlt actlon su entry and eat aetruns are nut perrurrneu aotrons on outgorng transrtron UnmedMuuelrng Language ManJean Harruld 59 unmee Madelan Language ManJ23quot Havml n Example Consider a lamp with two lights when the amp rs pmgged n rter be off when the swrtcn rs depressed and amp rr om one term Wm turn on Wnen the swrtcn rs depressed and one term rs on both arnps Wmdrn on Wnen the swrtcn rs depressed and both arnps are on both ampswm turn 0 at anynrne the term can be unpmgged UnmedMudehnuLanouaue MawdeanHanurd States of Diagram X Initial State default starting state C Final State execution of state machine has been completed unmed Mudehng Language Marv Jean Hanqu a2 States of Diagram N 7 gm Other states are shown as rounded rectangles One Light On Two Lights On UnmedMudehnuLanouaue MawdeanHanurd States of Diagram W Transitions are re a nships between states When event occurs fires object changes state One Light On ons and Events One Light On Two Lights On UnmedMudehnuLanouaue MawdeanHanurd Events cause 39 transition from one C Two Lights 0 On dmraanuaanatanauaaa Mawtaannarmra a States of Diagram X Plug in unmed Mudehng Language Marv Jean Hanqu ENE Software Engineering Overview Software Engineering Overview Mary Jean Harrold Questions 0 Software 0 How has it evolved What are the various eras and the characteristics of each Early software binary too difficult to program Then assembly better but still tedious Big breakthrough in 1950 s with Fortran and compiler for it compiler given free with IBM machinesstill difficult to read understand maintain Structured languages such as Algol Pascal Ada C sort of Objectoriented languages such as C Smalltalk Java What s next 0 What are different types of software What are examples of each 0 How does it differ from hardware Software Engineering Overview Mary Jean Harrold 2 Questions cont d 0 What are common causes of its failure Software Engineering Overview no standard procedures for development inadequate specification of requirements difficult to keep up with hardware design difficult to realize realworld conditions before release complex software is linked by networks size of project too large for a single manager to comprehend difficult to match technical knowledge of staff with project needs poor designimplementationtesting methodology requirements change as project is developed poor documentation force fitting software components to applications changing code without first understanding it Mary Jean Harrold 3 Questions cont d 0 What are common causes of its failure cont d Software Engineering Overview poor management lack of communication poor cost and schedule estimates unrealistic expectations lack of teamwork performance differences among staff few good measures of productivity software engineering not sufficiently taught in academia poor user input to product development insufficient focus on integration problems Mary Jean Harrold 4 Questions cont d 0 What are some ways to solve development problems Pressman Brooks Software Engineering Overview reusing components better training better time management prototyping better process measured by CMM standard bench marking for softwaredevelopment process cleanroom approach formal methods certification exams objectoriented analysis design and programming Mary Jean Harrold 5 Questions cont d 0 Software Development 0 What is the largest system on which you have worked 0 What is the average LOC that professional software developers produce in one day lt25 2550 50100 100200 gt 200 0 What do they do with the rest of their time And if they only write 10 L00 per day how do large systems get built 0 What processes should they follow Software Engineering Overview Mary Jean Harrold 6 Questions cont d 0 Software Engineering 0 What is it 0 the application of a systematic disciplined quantifiable approach to the development operation and maintenance of software implies consistency and repeatability of process 0 How has it evolved 0 term introduced by NATO Science Committee in 1968 0 still immature not professional but getting there 0 How does its maturity compare with other engineering disciplines Software Engineering Overview Mary Jean Harrold 7 Software Crisis Rising demand Increasing product complexity Immaturity of the field Slow productivity growth Inability to deliver quality products 0 Changing economic environment Software Engineering Overview Mary Jean Harrold 8 lnclass Exercise Find as many problems as you can with the following specification for filling text It was originally developed by Peter Naur as part of his description of the stepwise refinement approach to program development Naur39s Original Problem Statement Given a text consisting of words separated by BLANKS or by NL newline characters convert it to a linebyIine form in accordance with the following rules 1ine breaks must be made only where the given text has BLANK or NL 2 each line is filled as far as possible as long as 3 no line will contain more than MAXPOS characters Problems 1 1 No definition of line no statement of the relationship of line to the newline character 2 If the input text does not end with an NL then presumably it is not a line hence it is meaningless to talk of it being converted on a linebyIine basis 3 More generally there is no description of the structure of the input file no definition in terms of lines There is also no definition of the output file structure 4 There is no prescription about what to do about multiple blanks and at least two interpretations are possible There is no rule about zero length words and in fact no definition of word Problems 2 5 There is no prescription about what to do about multiple newlines 6 Nothing is stated about restrictions on the input file specifically what to do if an input line has a word containing gt MAXPOS characters 7 There is no prescription about what to do if the first characters in the input are one or more BLANKs 8 There is no rule considering the case where multiple BLANKs end the file or come just before a NL that ends the file Another Try In the context of program testing Susan Gerhardt and John Goodenough devised the following version Gerhardt And Goodenough 1 The program39s input is a stream of characters whose end is signaled with a special endof text character ET There is exactly one ET character in each input stream Characters are classified as break charactersBL blank and NL newline nonbreak charactersall others except ET the endof text indicatorET A word is a nonempty sequence of nonbreak characters A break is a sequence of one or more break characters Thus the input can be viewed as a sequence of words separated by breaks with possibly leading and trailing breaks and ending with ET Gerhardt And Goodenough 2 The program39s output should be the same sequence of words as in the input with the exception that an oversized word Le a word containing more than MAXPOS characters where MAXPOS is a positive integer should cause an error exit from the program Le a variable Alarm should have the value TRUE up to the point of an error the program39s output should have the following properties 1 A new line should start only between words and at the beginning of the output text if any 2 A break in the input is reduced to a single break character in the output 3 As many words as possible should be placed on each line ie between successive NL characters 4 No line may contain more than MAXPOS characters words and BLs Problems With The GampG Spec 1 1 Use of both of the phrases nonempty and one or more Why not avoid potential confusion by using just one phrase Same criticism holds for the terms stream and sequence 2 Output text if any is an example of remorse A qualification to the definition of output text is added long after it is first used 3 Line is used before it is defined The definition is incorrect it defines a line as being between NL39s which ignores text before the first NL The meaning of NL and its relation to the concept of line is left implicit Alarm is a program concept instead of a problem concept Behavior ofAlarm is not specified if MAXPOS is never exceeded The point of error is not de ned Problems With The GampG Spec 2 4 Contradictory definitions of input stream of characters and sequence of words separated by breaks 5 ET is a machine dependent program domain concept It is used three times before it is defined The output file does not contain ET which is either a bug in the spec or a significant nonuniformity 6 The phrase trailing blanks ending With ET is confusing 7 MAXPOS is used before it is defined Betrand Meyer39s Approach Bertrand Meyer has addressed the difficulties in specifying the textfill problem mathematically His approach is to define the problem in terms of sequences sets of sequences functions and relations Left undefined is the concepts of CHAR other than it is a set that contains at least the two elements blank and newline The set BREAKCHAR is defined to be the set blank newline Both the input and the output are sequences of CHARs The main idea is to look at sets of subsequences that are related to the input by various rules and to select only those subsequences that obey other rules Any element of this set of subsequences is a valid output of the program Meyer39s Approach 2 Among the properties of Meyer39s solution are that if more than one output satisfies the spec the spec does not prefer one to another This is called a non deterministic spec The advantage of nondeterminism is that it gives more freedom to developers The spec also does not constrain the solution by discussing program details Thus if the input contains a word longer than MAXPOS no sequence of CHARs will satisfy the spec in relationship to it How the error is indicated is up to the implementation or another part of the spec After constructing a mathematical solution Meyer then expresses the solution in unambiguous structured English as presented on the next slide Meyer39s Final Spec Given are a nonnegative integer MAXPOS and a character set including two quotbreak charactersquot blank and newline The program shall accept as input a finite sequence of characters and produce as output a sequence of characters satisfying the following conditions It only differs from the input by having a single break character whenever the input has one or more break characters any MAXPOS 1 consecutive characters include a newline the number of newline characters is minimal If and only if an input sequence contains a group of MAXPOS 1 consecutive nonbreak characters there exists no such output In this case the program shall produce the output associated with the initial part of the sequence up to and including the MAXPOS th character of the first such group and report the error What Does this Program Do QeO Rex whileR2Y ReRY 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 lt DIVIDEX Y Expressed as a relation of four variables DIVIDEX Y Q R Preconditions What must be true about the inputs to this program in order for the program to successfully execute QeO ReX whieR2Y ReR Y QeQ1 Preconditions 39XZOAYgtO The value ofX is nonnegative and The value of Y is positive QeO ReX whieR2Y ReR Y 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 the program Q e 0 terminates R e X while R 2 Y R e R Y QeQ1 Postconditions 39 Ygt O A X20 Qeo Rex whieR2Y ReR Y QeQ1 Postconditions Ygt0 A X20 A QzO Qeo ReX whieR2Y ReR Y QeQ1 Postconditions Ygt R20 A X20 A QaO Qeo ReX whileR2Y ReRY QeQ1 Postconditions 39YgtR20A X20A 39QZOA XQYR QeO ReX whileR2Y ReR Y QeQ1 Proof Plan Construct flow chart Annotate with preconditions Add loop invariants at intermediate program points based on the type of statement executed Assignment Conditional Loop Flow Chart Rlt X l RltY Yes EXIT N0 Rlt R Y l Q 0 X20 Ygt0 Add Pre Post Conditions YgtR20 X20 Q20 XRQY Simple Assignment The statement Q lt 0 guarantees that Q has the value 0 after it executes Moreover all other variables remain unchanged Assuming no variable aliasing Therefore the invariant after the assignment execution looks like X 2 0 Y gt 0 Q 0 Assi nment g X20Ygt0 Slightly More Complex Assignment The statement R lt X guarantees that R has the same value as X after it executes So X20Ygt 0 Q 0 becomes X20Ygt0Q0RX We can also use the laws of algebra to manipulate other assertions The assertion is algebraically equivalent to R20Ygt0X20Q0XR Assignments R x Yes EXIT Loops Unlike other statements a loop like the one in the example has to deal with multiple incoming flows of control That is there are two ways of entering the loop One from the start of the program One after going around the loop at least once The statements inside the loop must be true in both circumstances In fact they need to be true no matter how many times the loop is executed Loops 2 For this reason they are called loop invariants Normally you think of loops behaving differently on each iteration But the assertion has to stay the same That is the loop invariant has to generalize over all iterations They can do this because they are expressed in terms of the loop variables The analyst has to invent this generalization More on Loop Invariants A loop invariant has to satisfies three properties It must be true the first time execution reaches it If it is true after some number n of iterations it must be true after n 1 iterations It must be strong enough to imply the postcondition Loop Invariants 2 Let s start with the postcondition we have to establish YgtR20AX20AQZOAXQYR We already have Y gt 0 Y gt R X 2 0 Let39s try R2Ygt0X20QZOXRQY l Rlt R Y l Mu Invariants 2 Let39s try our first test Is the invariant true the first time through Condition before entering the loop R20Ygt0X20Q0XR Loopinvanant R2Ygt0X20Q20XRQY R20andYgt0and RzYimpliestYgt0 so we are okay so far X still nonnegative If Q equal to 0 then it is certainly greater than or equal to it Finally ifQ 0andX RthenXdoes equal RQYR0YR Assignments Again The algorithm includes the assignment statement R lt R Y inside the loop What is interesting about this statement is that the variable on the left hand side R also occurs on the right hand side If we 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 Q Y and the assignment statement R lt R Y First using the assignment statement annotate the left hand R with a prime R39 R39 can be read as quotthe value of R after the assignment Assignments 3 Now solve for R in terms of R39 R39RYR39YR Substitute this expression R39 Y into the precondition for all occurrences of R XR39YQY Simplify to produce the postcondition and drop the prime XRQ1Y The general rule is to solve for the variable without the apostrophe and plug that expression into the precondition More 0 Assignments X20Ygt quot39X20Ygt0Q0 R20Ygt0X20Q0XR YR20X20Q20XRQY Yes No R 2Ygt0X20Q20XRQY Rs R Y l 1 R20X20Ygt0Q20XRQ1Y Qt Q1 l Last Assignment Let39s try this procedure on the last assignment statement in the algorithm Q lt Q 1 The precondition of the assignment is R20 X20Ygt0Q20XRQ1Y Set Q39 Q 1 Solve for Q Q Q39 1 Substitute into precondition R20 X20Ygt0Q39120XRQ3911Y Simplify R20 X20Ygt0Qgt0XRQY Last Assignment Q60 1 mi gunR20Ygt0X20Q0XR YR20X20Q20XRQY N Y gt 0 X a 0 Q 2 0 X R Q Y I R R Y l 1 RzQszYgtszQXRQnY gquot R2QX2mYgtmQgtmXRQY Generalization We now have two preassertions for theloop Rgt0Ygt0Xgt0Q0XR Rgt0Ygt0Xgt0Qgt0XRQY We need to find a logical expression that generalizes over both Rgt0Ygt0Xgt0Qgt0XRQY Generalization 1 X20 Ygt0 H I H i R20 Ygt0 X20 Q0 XR quotREO Ygt0 X20 Q20 XRQ Y YgtR20 X20 Q20 XRQY N0 R2350 x20 Q20 XRQY l R lt R Y I 1 R20 X20Ygt0 Q20 XRQ1Y 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 from this test R lt Y can be conjoined with the assertions coming into the conditional Similarly for the No branch Conditional X20 Ygt0 H I 00 R20 Ygt0 X20 Q0 XR quot1120 Ygt0 X20 Q20 XRQY YgtR20 X20 Q20 XRQY R lt Y E HALT N R2350 x20 Q20 XRQY R R Y l Qt Q1 Implications Notice that the postcondition of the last assignment labels the arc that returns to the top of the loop We can now make our second test on the loop invariant if the loop has successfully executed n times will the invariant hold on the n 1 The postcondition on the nth execution or any execution is R20 X20Ygt0Qgt0XRQY The loop invariant is R2Ygt0X20Q20XRQY Surely Q gt 0 implies Q 2 0 And R 2 0 Y gt 0 and the loop condition R 2 Y imply R2Ygt0 So the second test of our loop invariant is passed Third Test It is easy to come up with invariants After all 1 1 2 is a loop invariant It is true for every execution of any loop But it is not much good in proving programs We need to have loop invariants that imply the program39s postconditions This is just another way of saying that the loop computation has to contribute to the producing the intended program result Third Test 2 For the example program the result of the loop is R20 X20Ygt0Qgt0XRQY We also know from the conditional that R lt Y The program post condition is Ygt R20X20QzOXQY R So the third test is passed as well Summary of Example Preconditions for successful execution Postconditions Examination of all possible paths Assignment Conditionals Loop Invariant First execution Induction 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 terminates We have to also prove termination 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 as follows Define a function with the following properties lts domain is the set of program variables lts range is the integers The value of computed by the function gets smaller on every iteration When the loop exits the function value is negative That is you can rely on the following property of the integers Any constantly decreasing series of integer values must eventually become negative Example Revisited Q0 I What function fcan be 1 used as a termination l Rex l function R lt Y Yes Termination Termination function fX Y Q R R Y Example On the No branch R 2 Y gt R Y 2 0 gtf is always nonnegative R e R Y gets executed on every iteration R and Y are both positive at all times Hence R gets reduced on every loop iteration Consequently f gets reduced on every loop iteration OntheYes branch RltYgtRYltOgtf 060 is negative R e X while R 2 Y R e R Y QeQ1 MOTIVATION FOR METRICS Effort prediction Quality improvement Project tracking COMPLEXITY METRICS Program length lines of code Intraprocedural control flow complexity Interprocedural control flow complexity Faninfanout Module couplingcohesion Use of inheritance PROGRAM LENGTH Single best estimator of effort bugs etc Lines Whitespacecomments Statements KLOC de facto standard correlated with everything else CONTROL FLOW COMPLEXITY Loopconditional nesting Knots structure violations goto s McCabe Cyclomatic complexity One plus the number of program predicates Equals the number of linearly independent control flow graphs OTHER FACTORS All show slight advantages Use of mnemonic variable names Use of whitespaceindentation Use of comments GQM goal Question Metric Basili etal Framework for establishing a metrics program Use of Measurements Project planning Processproduct assessment Rationale for change Progress assessment and correction Requirements A metrics program must be focused on specific goals be applied to products processes and resources interpreted via organizational context and environmental goals This implies a topdown process Approach Start with organizational information needs and produce a measurement system Conceptual level goals Operational level questions Quantitative level metrics Conceptual Goals For an object Objects of measurement products processes or resources For reasons With respect to a quality model From various points of view Relative to an environment Questions Characterization of object wrt a goal Metrics Associated data Objective or subjective depending on point of view Example Change request processing Goal purpose improve process change request handling Viewpoint project manager Quality issue timeliness Questions current speed improvement Metrics average cycle time standard deviation out of range ratio wrt baseline subjective The GQM Process Data collection mechanisms Validation Data analysis Sources of Goals Organizational strategy documents Processproduct descriptions Model of the organization Groups of Questions How to characterize wrt goal How relevant is an attribute How to evaluate characteristics Cleanroom Verification In Cleanroom constructed programs can be checked by a parser for syntax errors but may not be executed by the developer No debugging gt cheap and predictable process Verification is performed by a team review driven by a set of veri cation conditions Questions to ask about the program code Specific questions are asked about each occurrence of different kinds of program statements Productivity 3x 5x improvement in verification over debugging Formal Inspections Although program proving is always an option it involves intensive work requiring mathematical sophistication An alternative used by Cleanroom software engineering is to structure a team code inspection in terms of program functions and verification conditions and then undertake an semiformal review confirming that all verification conditions are satisfied Functional Verification Steps 1 Program is specified by pre and post conditions 2 Prime program decomposition Parse program control flow into nested single entryexit constructs SESEs 3 Proceeding top down determine the program function for all SESEs Program function Description of the function of a prime program 4 Define veri cation conditions for each program point Things to check for each SESE 5 Inspect answering all verification conditions Program Function Conditions under which the prime program can legally execute preconditions Expression of the effect of program execution on the state of the system postconditions Expressed in terms of the program39s input arguments return value instance variables global variables and side effects on the environment disk writes printing etc but not referring to local program variables Sort Program Function context IntVectorsort assumes that IntVector is represented with an OCL sequence post thispre gtasBag this gtasBag and forAlli Integer 1 lt i and i lt this gtsize and this gtati lt this gtati 1 Program Parse Modern programming languages support the concept of nested blocks A block is normally enclosed in braces or keyword pairs begin end ln structured programs programs without GOTO statements the nesting is always well formed That is there is only ever one way for control to enter the block and one way to exit That is they have the property of being singleentry single exit SESE Programs with GOTOS can be handled using special methods The process of determining the SESEs for a program involves parsing its control flow graph 4 Typical SESEs Conditional Composition Iterative Composition Composition of SESEs Each SESE can be thought of as being itself a small program with its own program func on The overall program function is the logical composition of the program functions of its constituent SESEs The lowest level SESE is the single assignment statement Verification Conditions If we were proving a program correct we would construct the proof by composing the proofs of each of the SESEs Instead of a proof Cleanroom uses an informal review that examines each program statements to determine its logical validity In particular each type of statement has a set of questions that should be asked about it every time that it occurs in the program Verification Conditions 2 Imagine a program p with a program function f p is composed of smaller programs SESEs q r s each with their own program functions fq fr f S In general we have to devise verification conditions ch vcr vcs such that demonstrating that the verification conditions all hold demonstrates that f also holds This will depend on how the statements are composed There are three ways of composing SESEs Sequentially conditionally and iteratively Sequence The simplest control structure is a sequence of two other statements or control structures There is one verification condition per sequence Do the constituent statements together accomplish the sequence s goal That is if you come across the following situation f do g h enddo Then generate the following verification condition Does g followed by h do f This idea can readily be extended to three or more constituent statements Sequential Composition 1 Is the post assertion of the sequence equivalent to the logical composition of the first part followed by second part Conditional An if then else has two arms Does each arm acting by itself accomplish the control structure s post condition assuming the control structure39s precondition and that the tested condition is true or false That is if you come across the following situation f if p then g else h endif Then generate the following verification conditions When p is true does g do f When p is false does h do f Ifthen is treated as if then else with a null arm Case is like a multiarmed if Conditional 2Does taking the true branch imply the post assertion The predicate of the conditional can be assumed to be true 3Does taking the false branch imply the post assertion The predicate can be assumed to be false Iteration There are three questions to ask about an iterative construct such as a while loop Does it terminate in all circumstances Does it accomplish its purpose when it does not execute Does it accomplish its purpose when its body is executed followed by its own execution That is if you come across the following situation f while p do g endo Then generate the following verification conditions ls termination guaranteed When p is true does g followed by f do f When p is false does doing nothing guarantee f for loops and repeat loops can be defined in terms of while loops Iteration 4Does the loop terminate 5lf the predicate is false does the post assertion follow from the pre assertion 6lf the predicate is true is the post assertion of the loop equivalent to the post assertion of the body followed by the post assertion of the loop Recursive Implications As teams become more experienced in Cleanroom they begin to write their programs more directly This typically results in very small program segments with few control structures each Example 3300 lines 2 600 control structures 1000 correctness conditions Results Of Independent Empirical Evaluation 15 3person teams 10 of them used Cleanroom 610 delivered 91 of functionality Requirements better met and less failures More comments less dense control flow Better adherence to schedule Developers expressed satisfaction with process Example Consider the following program segment What are its pre and post conditions SUMbO n int returns t int int bO n i l t bO while i lt n do t t bi i i 1 end end Program Function Signature SUMbO n int returns t int Precondition n 2 O quotn is nonnegativequot n Postcondition t gomk quott is the sum of the elements of bquot Program Parse Seq Seq i 1 t b0 Loop Seq t t bi i 1 Program Decomposition Program Function lt n 2 0 int bO n i l t b0 While i lt n d0 t t bi i i 1 end Informal Specification B1 Sum the contents of the vector b of length n B1 1 Initialize program variables Initialize loop counter Initialize partial sum B12 Loop through tail of vector adding elements B1 21 Process each element Increase partial sum Increase loop counter Formal Specification lt n gt 0 int bO n 1 l t bO lt n gt 0 A i l A t bO i lt 1 lt i lt n A t k 0 t tbll lt 11lt i lt2 n A t t39 bi I i 2 bk bi 2biki k0 k0 1 ll i4 lt 1 lt2 i 1 lt2 n A t 2 bk k0 end n lt Verification Conditions B1 Sum the contents of the vector b of length n 1 Does initializing the program variables followed by looping through the remaining vector elements compute the sum of all elements B1 1 Initialize program variables 2 Does initializing the loop counter followed by initializing the partial sum successfully initialize the program variables Initialize loop counter 3 Does setting 1 to 1 successfully initialize the loop counter Initialize partial sum 4 Does setting t to b O compute the initial partial sum Specification 2 812 Loop through tail of vector adding elements 5 Does the loop terminate in all circumstances 6 Does the loop add up all the elements of an empty tail 7 After the loop has successfully added some number of elements in the tail does the next iteration add in the next element B1 21 Process each element Increase partial sum 8 Does adding the current element to the partial sum increase the partial sum appropriately Increase loop counter 9 Does adding 1 to i successfully complete the iteration The Process Process Mary Jean Harrold 1 What is Software Engineering The study of systematic and effective processes and technologies for supporting software development and maintenance activities to improve quality to reduce cost Process Mary Jean Harrold W What is Software Engineering Software engineering is layered Process Mary Jean Harrold Software En gineering Phases Definition Focuses on what 0 Development Focuses on how Maintenance Focuses on managing change Umbrella activities Used throughout lifecycle Overview slide Process Mary Jean Harrold 4 Definition Requirements definition and analysis Developer must understand Application domain Required functionality Required performance User interface Process Mary Jean Harrold 5 Definition co nt Project planning System analysis Allocate resources Allocate system Estimate costs reSOUFCGS t0 Define work tasks 39 Hardware Define schedule 39 SO W lre Users Process Mary Jean Harrold 6 Development Software design 0 User interface design Highlevel design Define modular components Define major data structures 0 Detailed design Define algorithms and procedural detail Process Mary Jean Harrold 7 Development cont Coding Integration 0 Develop code for each 39 Combine mOdUIGS module Integration testing 0 Unit testing Process Mary Jean Harrold Maintenance Correction Fix software defects Adaptation Accommodate changes New hardware New company policies Enhancement Add functionality Prevention Make more maintainable Process Mary Jean Harrold 9 Umbrella Activities Reviews assure quality Documentation improve maintainability Version control track changes Configuration management integrity of collection of components Process Mary Jean Harrold 10 Software Engineering Costs I Maintenance Development I Definition Process Mary Jean Harrold 11 Software E ngineering Costs I Prevention Enhancement I Adaption I Correction I Integration I Coding Design I Specification I Requirements Process Mary Jean Harrold 12 Relative Costs to Fix Errors Process 20 40 60 80 Mary Jean Harrold I Requirements I Design I Coding Testing I After Delivery KWIC Exercise D Parnas quotOn the Criteria to be Used in Decomposing Systems into Modulesquot Communications of the ACM 151210531058 December 1972 Key Word in Context KWIC The KWIC index system accepts as input an ordered set of lines each line is an ordered set of words and each word is an ordered set of characters Any line may be circularly shifted by repeatedly removing the first word and appending it at the end of the line The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order of the keyword used to shift the line Common stop words may be omitted CIRCULAR SHIFTS Original title Gone with the Wind Circular shifts key words underlined gn with the Wind with the Wind Gone the Wind Gone with Wind Gone with the Stop word removal gn with the Wind Wind Gone with the EXAMPLE WITH MULTIPLE TITLES Gone with the Wind War and Remembrances 0The Winds of War KWIC EXAMPLE and Winds of with the The gone Bemembrances ar ar Kind Hinds with the Wind War The and Remembrances Gone of War EXERCISE Parnas Assume that you had to implement KWIC Decide how you would break it into approximately six pieces even if you don39t think it is big enough to have pieces Use a box for each piece and give it a label Ignore stopword removal Decide how the pieces communicate Use a line between two boxes to indicate some form of communication Label the line to indicate the type of communication Come up with at least two solutions For each give circumstances when that solution would be advantageous SHARED DATA DECOMPOSITION Break into components based on functions computed Also Known As Functional Decomposition All components share access to data in memory Usually contain a mastercontroller routine Dependencies realized with function calls MODULES Input reads titles stores in memory Circular shifter constructs array of pairs ltine index word indexgt Alphabetizer batch sorting of circular shifts Output Master controller SHARED DATA h Direct Mum Amos Subpogrlm Call Smquot U0 4 I 3909 I cm ar Shift Alphabetizer J Output fquot Charmer Index A39 gdb uud x Input Modlum Medium Figure 6 KWIC Shared Data Solution ABSTRACT DATA TYPES ADT DECOMPOSITION Organization based on data structures Representation hiding Modules holding data structures also provide services Basis for object orientation MODULES Line ADT Input reads titles hands to Line Characters ADT Circular shifter ADT Alphabetic Shifts ADT lth circular shift Output Master controller ABSTRACT DATA TYPE a 30mg Can System V0 Mamr Central Charactan Figure T KWIC Abstract Data Type Solution IMPLICIT INVOCATION Client modules express interest in state changes in server modules registration Server announces changes to all registered listeners broadcast Server does not know identity of clients Unit of notification is the event MODULES Input of new line Update line data structure Invoke circular shifter Update second line data structure Invoke alphabetizer IMPLICIT INVOCATION Irmlcit Invocation Smram Call System V0 Master Carmel Input thlurn I Figure 3 KWIC Implicit Invocation Solution PIPE AND FILTER System organized into independent programs lters Each filter takes in input stdin and produces output stdout Filters are connected together via FIFO queues pipes Common assumption of sequential files containing lines of ASCII characters Can you think of a nonASCII example MODULES Filters for circular shift and alphabetizer Pipe connections with files of FIFOs No common data storage PIPE AND FILTER quot Pips Smim HO Arphabnlmr Output I Output I Medium Figure 9 h W1C Pipe and Filter Solution EVALUATION Shared data Intuitive efficient access Brittle to changes in representation ADT with no data sharing Maintainability reuse Performance Implicit invocation active data Enhancements data representation changes reuse Difficult to controlthink about inefficient Pipe and filter Intuitive reuse Interactivity space efficiency EXERCISE CONTINUED List at least three possible enhancements improvements that could be made to KWIC For each of the four styles shared data ADT implicit invocation pipe and filter indicate how well it would cope with each of your changes Use the categories brittle moderate easy to label your choices KWIC CHANGES Input format Reuse Processing algorithm Shift each line as it is read Shift lines after all are read Shift lines on demand Incremental versus batch sort New functionality Stopword elimination Interactive line deletion Use of external storage Performance optimization Data representation Line storage Explicit circular shifts Indexoffset circular shift Process Mistakes McConnell Overly optimistic schedules Insufficient risk management Contractor failure Insufficient planning Abandonment of planning under pressure Wasted time during fuzzy front end Shortchanged upstream activities More Process Mistakes Inadequate design Short changes quality assurance Insufficient management controls Premature or overly frequent convergence Omitting necessary tasks from estimates Planning to catch up later quotCodelikehellquot programming McConnell Fixes Identify and fix classical mistakes Miniature milestones Milestonebased schedule Track schedule meticulously Record reasons for missed milestones Recalibrate early and often Don39t commit to a new schedule until you can do so meaningfully Manage risks painstakingly Process Improvement Shewart Cycle Plan What and why Act Plan Do How when and how much Cheek Check Do Act How will you know it worked How do you plan to fully adopt The Dilbert Cycle Blame mm 6186 f0f Make Wild guess 2amp0th at what is wrong Adopt unproven j process or technology Plan Identify problem or opportunity Vision Where do you want to be Describe the current process Is the process in control Is it repeatable Identify possible weaknesses Strategic impact Cost benefit analysis how effort supports core competence risk of not doing Do Determine what changes might help Develop or purchase an evolution plan Implementation tactics Major deliverables organization maturity considerations key role of infrastructure coordination with other groups timing to match user projects handoff criteria Select and implement a change on a pilot project People and resources Sponsor and champion roles user partners people and expertise needed hardware software space Schedule risks contingency plans Check Measure effect of change Baseline measurement prechange environmental characteristics expected effect Postproject review degree of adoption Percentage of engineers using improvement range of uses maturity of usage Act Adopt across organization Support strategy Infrastructure changes documentation training consulting packaging maintenance feedback Continue cycle Metrics and Measurement Ge r The do ro first Then dis ror r i r wi rh your39 judgment quotMark Twain You can39T con rr39ol who r you can39T measure Tom Demor39co If you don39T know where you are going any map will do If you don39T know where you are a mop won39T help Wo r rs Humphrey Getting the data How do we decide what data to collect Goal Question Metric GQM Basili Goal eg reduce defects to 6KLOC in code Question eg what is the defect rate now Metric eg defect count per KLOC Key Metrics Lines of code Staff months Calendar months Defects Defect Analysis Origin where Requirements specification design code environment support documentation Type what Next slide Mode why Missing unclear wrong changed better way Defect Types Requirement I analysis functionality Specification design HW SW User interfaces functional description Design Communication data definition module design logic description error checking standards Code Logic computation data handling module interface implementation standards Environment Test SW Test HW development tools integration SW Root Cause Analysis Determination of the underlying process deficiency that causes a class of product defects Collect defect data Determine causes Organizational buyin tie to business goals Assign responsibility Variations Oneshot postproject continuous OneShot Root Cause Analysis Requires prior defect data collection but no prior causal analysis Train on defect analysis indicate goals Select 5075 defects randomly Classify pie chart Pick top two defect types fishbone diagram Improvement recommendations Present results assign responsibility implement change Postproject Root Cause Analysis Prior understanding of defect patterns Premeeting Identify primary business goal Data analysis champion and facilitator Select two defect types for brainstorming Invitations to engineers Bring examples of their faults in selected categories Guess at root cause Suggested prevention mechanism Meeting State meeting goal and rules Select issues Review defectscausessolutions brought to meetings Analyze defects fishbone diagram Brainstorm solutions Assure organizational commitment Plan for change responsibilities and dates Postmeeting Champion and facilitator review meeting Prepare meeting summary Champion captures process baseline data Before and after process description and data Fishbone Diagram Cause and Effect Diagram Write suggested causes of a class of defects on note cards Organize into af nity groups Use lines to indicate quotis a cause ofquot or quotis a prerequisite ofquot Spine is major defect class Major branches are affinity groups GUIDELINES NOT FOLLOWED LACK OF FEEDBACK LACK OF GUIDELINES E X a m p I e Prddype Hcustnmers m cheicb basedcn 39M No fuminlity rms Users rd Lack I focused 1 Dan read SKII39D raw paint TOO b5on da 39lm tram San pm parts dun IN quotRI aa yfefgack resemble has no Ion Some pamls rd used as much Ib good mochl Tests n mothl user emirurmerl a qntely r JSER INTERFACE Toomanyatails many canII39nIIims dfeaiues Deeithdbasedm 39rnom at custcmer base 95 d quotWES Camrcases pa iehlar Itsouce limits DIFFERENT PERSPECTIVES OOPS FORGOTT EN Third Party Audits Assessments CMM maturity model ISOQOO1 international standard SQPA business practices functional model QMS business model Baldridge Department of commerce weighted criteria CMM V Continuously Improving Quantitative strategic goals Processes improved IV Improvement based on data Quantitativer Controlled Definition of quantitative gojals III Process metn39cs captured Wequot De ned Managing processes by data so Develo mentof or std rocess II Projects use org std process Planned amp Tracked Sharing organizational learning I Work is planned amp managed performed Informauy Projects using de ned process Individual heroicS Controlling local chaos 0 Essential elements performed I Legend Not performed Doing systems engineering I Level Title SE process area not being done NA Characterized by Organizational starting point Achieved when Primary Concept SA 11 ISO 9000 Series Actually a series of specifications that allow companies to be certified Doesn t focus on improvement just current state Addresses minimum criteria for a quality system Strongly papertrail oriented Checklist assessment Generic not software specific Principle Every important process should be documented Guidelines for Process Improvement Incremental rather than bigbang implementation Contrast with Paradigm Shiftquot quotBPRquot Use data Treat root causes not symptoms Workers know best how to do a process Avoid consultants More Guidelines Today s problems come from yesterday s solutions The harder you push the harder the system pushes back The easy way out usually leads back in The cure can be worse than the disease Statistical Usage Testing Black box random testing Certification of reliability Statistical process control Costeffective orientation Guidelines for test completion desired reliability reached or redesign too many failures found Stratification mechanism for dealing with critical s ua ons Questions exist on how to feed back the results of testing to the development team CostEffective Testing kmrmrmmmmemiummmMmMm Rm Group I 2 3 a s a 7 WITHyeats 50m use 500 58 so 58 s Pzrltrm mum mtlndurpmduu 1 u I ms 103 so 2 12 2 m 30 w 97 45 32 KS 1 m 285 man 97 as 3 I4 4 u 285 W n9 44 0 03 s u 295 m 94 u 9 I4 2 311 3 01 us 50 2 as 7 Jan 35 m 99 a 7 m x u 9 v xx 1 l lt75 7 n 9 n IN IN 13 55 x9 05 vengepermnagc m as nu H70 51 25 yo lmluru V u Pmmbvlm 0mmquot I0 um Irmuruu mm o 02 w n mu 0 121 0 m o v n m CostEffective Testing Tobie 2 Soan me For nine mnjor BM product charmed from m to frequent Ran v Frequcm koup E 2 3 4 5 6 7 8 MTTF yearsi 5003 I530 500 58 50 58 5 58 Pcrc cm fmiurcs m L39Ea fm prudut39l I 1 342 333 E73 303 50 ll 12 04 w 5 j 50 182 97 35 32 L5 07 3 13 39 185 380 3 155 38 Ex 4 1 342 285 3 m 44 20 03 01 5 343 235 184 94 44 39 4 7 b 310 332 2E1 ILS 50 3 1 03 03 T 340 185 85 99 15 37 4 Pf 3 349 371 33 1 455 3 i1 1 9 3 36 204 133 515 9 05 10 Artrage pentnag 334 283 l8 106 31 25 9 0d lmlures i t Probabilin of fattm f a t Fm 3115 from11039 HHS U 03 044 0979 0123 0 I8 0 33 131 Rows correspond to projects CostEffective Testing Tab 2 Soan me For nine mnjor BM pnevducu charmed from m to frequent Ran v Frequcm koup E h 3 4 5 6 7 8 MTTF yearsi 5003 I530 500 58 50 58 5 58 Pcrc cm fmiurcs m L39Ea fm prudut39l 1 342 333 E73 303 50 ll 12 04 3 34 3 330 182 97 45 32 I 5 07 1 13 39 135 380 3 155 28 Ed 04 1 342 285 3 m 44 20 03 01 f 343 235 184 94 44 39 4 7 b 310 332 3E1 ILS 50 3 1 03 03 T 340 185 85 99 35 37 4 96 3 349 371 33 511 455 3 i1 1 9 3 30 204 133 515 9 05 NJ Artrage pentnag 334 283 l8 106 31 25 9 0d lmlures t Probabilin 0E2 fattm f t E39m Gm gut11039 01113 0 ON 044 099 0123 0 I8 0 33 131 Columns correspond to bug execution occurrence likelyhood in years CostEffective Testing Tab 2 Soan mm For nine xiifor BM products charmed was run to frequent Ran v Frequent Group E 2 3 4 5 6 7 8 MTTF yearsi 1003 I580 500 58 50 58 5 58 Prrc cm fmiurcs m L EES SIUI39 prudut39l 1 342 273 303 50 ll 12 04 3 34 j 182 97 45 32 L5 07 3 13 39 135 380 37 155 38 EA 04 1 343 285 ES m 44 20 03 01 f3 342 235 184 94 44 39 4 7 b 310 332 2E1 ILS 50 3 1 03 03 J 340 185 35 99 35 3 4 96 3 319 331 33 511 455 3 i1 1 9 3 30 204 133 515 9 05 10 Menage perueruagc 334 283 l8 106 31 23 9 Us lmlures i Probabilin ofquot fattm f a t Fur Gm frequcncv 01113 U 03 044 0979 0123 0 I8 0 33 131 Cell contents indicates the percentage of bugs on a project with a given MTBF CostEffective Testing Tab 2 Soan mm For nine xiifor BM products charmed was run to frequent Ran v Frequcm Group E 2 3 4 5 6 7 8 M I IF yearsi 1003 I580 500 58 50 58 5 58 Pcrc cm fmiurcs In L39Ea fm prudum 1 213 303 50 ll 12 04 3 132 97 45 32 L5 07 3 330 37 55 28 m 04 1 E3 H9 44 20 03 0 5 184 951 44 39 4 7 6 2H ILS 50 3 1 03 03 339 33 99 55 37 4 96 3 33 511 455 3 i1 1 9 204 139 3 5 6 9 05 10 Menage perueruagc l8 106 31 33 9 Us lmlures w 4 Probabilin of fattm f a Fur Gm frequcm39v 01113 U 03 044 0979 0123 0 I87 0 23739 3 300 616 of bugs on these project were ones unlikely happen in a 1500 years Testing Process Usage distribution models From competitors earlier versions analysis Markov usage chain State transition probability matrix Statistics H proportion of time spent in each state n number of states visited before a given state is reached 3 number of tests needed to reach a state Random test generation Design required Test execution and test chain generation including failure states Statistics R reliability MTBF mean time between failures D divergence of test chain from usage chain 1 Initial Usage Model Fig 1 Top level view of software usage Refined Usage Model Fig 3 Structural phase constructing the usage Markov chain 2 Probabilities from Scenarios Tm n Smusuul Fins mm me Tmmuan Pmrxmlma ms mqmc mum at mm mm quuw l lt1vo gt L nwgtltMmmzcgtltWmdnwgtltClw N s 3 2 Y s a 3 a K a A 3quot v i 9 ltannnn gtlt Window Mow Du Mamcgt ltDiwugtltDng Hume a hxgtltDng MuuzgtvDawngtltDng MahegtltWnu gt mas ltTu1vmllangt lt Mam lt Wmdawgtlt5izegtltDmg mmx and Mann A gt lt Dug Mau5qgtlt1 itgt Dug Mame ltw am lt Clan Temmuuqngt lt n n ngtltWrdwgtltMavcgtltDrIg MausltDmmgtlt3ng a gtltDu VIauxegtltDwnltDmg Mutscgtltwmdnwgt lt Cimelt39 manna a IrmanonltWn owgtlt5ugtlthra5 McmgtltDuwngtltDng nuscgtltRigmgtlt3ng Vin lt winmx am lt mum lnmcmiun mm Wm w VIImu iznimizc Mm 5m Cinsc Wmmw Drag mm Dug mm Mom w w Dr 0 my Up Drag u awn 1 Ag MW 1 Drag Mom my nag Mn cm Ternum Trnmmtmn anunn 3 Usage Model Statistics Table III Analyucal Results for me Example Usage Model State lnvomuon W W t Mlmmxze Icon Restore Move Sn Drag Mouse UP Down Len Rtghl Close Termmauon 7 0093750 n u 39A u umug mowwcnmmop N 5 Usage and Testing Chain Fig 4 a The usage Markov chain b The testing Markov chain Path Frequency Measurement Inquencc12ABBCD CW 1 bx C tequm22ACBBCD 12 1 I KI D 0N Fig 5 The evolution of the testing chain Dealing V th Failures 2 Fig 6 Creaung a failure Slate 6 Testing Model Statistics Table w Analytical Results for the Emmple Usage M6051 swqusnw x R MTBF own 1 1 m m 2 1 I1 3 M11018 1 0750000 37000000 0000000 53000000 0051781 5 011101 2 0714286 34 500000 0066337 6 0750000 33000000 0 7 0 777773 40001150 0058756 3 44000000 0053571 0 0 1313132 46000000 0 050339 10 0 033333 56500000 0 052332 11 0346154 53500000 0050433 12 0 357143 68500000 0 052500 13 3 7 70500000 0 051166 4 3 375000 72500000 0 050313 15 16111116 3 0323523 50000000 0059133 16 0 333333 52333333 0 059069 17 0842105 54666667 0060906 13 0 35 56000000 0060327 19 0357143 59000000 0062373 20 0 863635 64000000 0033177 25 0888889 32000000 0026981 30 0906250 113333333 0023453 35 0913919 134333333 0022276 40 0928571 153 333333 0 019938 Testing Example COBOL SF parser generator Four increments 120 random tests Last 115 executions correct 12 failures in first five executions 39 faults KLOC No new failures in four years of use Regression Tes ing Regression Testing Mary Jean Harrold Evolving Software W Microsoft WindowsNT S eNer 351 Microsoft WindowsNT seQ Sr p Far East 351 351 Patches Regression Tes In 6 Features 9 Far East 40 40 Patches 41 Features Mary Jean Harrol Evolving Software Regression Tes ing Mary Jean Harrold Given Program P Test Suite T Identlfy Modify P changes to P 39 Find faults F P correct in P for T F W P correct for T Mary Jean Har Regression Tes ing Regression Testing W Performed on modi ed software to provide con dence that o the changed parts behave as intended the unchanged parts are not adversely affected by the modi cations Applied To new versions ofthe software After nightly builds During development Extreme programming Regression Tes ing Mary Jean Harrold Regression Testing Program Test P Suite T l P Version of P Regression Tes ing Mary Jean Harrold Regressiontest Selection RTS Program I I T P l P Version of P Regressiontest Selection RTS W TT Program I T P T l P Version H Regression Tes ing Mary Jean Harrold Time to select T Time to run T lt Time to run T Regression Tes ing Mary Jean Harrold Safe Regressiontest Selection Execute P Record coverage Identify dangerous entities I l 1 Ent es Coverage matrix records which test cases cover each speci c program entity Dangerous entity program entity e in P such that if a test case t covers e when t is run on P P may behave differently than F when t is rerun on P due to the modi cations from P to P Regression Tes ing Mary Jean Harrold Identify Dangerous Entities W 3 1 Constructgraph G G representations for P P G 2 Associate test cases in T with entities in G Test cases in T 3 Differentiate entities in G and G to nd dangerous entities Dangerousa Regression Tes ing Mary Jean Harrold 1 Construct Controlflow Graphs CFG Procedure AVG 81 count 0 82 read n 83 Anile not EOF do 84 if n lt 0 85 return error else 86 numscount n 87 count endif 88 read n endwhile 89 avg mean nums count 810 return avg Regression Tes ing Mary Jean Harrol 2 Associate Tests in T Edges in CFG a Test Input Output t1 empty le 0 Regression Tes ing Mary Jean Harro 2 Associate Tests in T Edges in CFG W Test Input Output t1 empty le 0 t2 1 error t3 1 2 3 2 Regression Tes ing Mary Jean Harrol 2 Associate Tests in T Edges in CFG a Test Input Output t1 empty le 0 t2 1 error t3 1 2 3 2 Regression Tes ing Mary Jean Harrol Modified Version of AVG AVG CFG Procedure AVG 81 count 0 82 read n 83 Anile not EOF do 84 if n lt 0 S 5 return error else 82 Jlm CEU tE D rST count I I quote d39lfquotquot 88 read n endvmile 89 avg mean nums count 810 return avg Regression Tes ing Mary Jean Harrold 3 Differentiate Edges in CFG CFG W Regression Tes ing 3 Differentiate Edges in CFG CFG t1 t2 t3 t1 t3 Regression Tes ing Mary Jean Harrold 3 Differentiate Edges t1 t2 t3 t1 t3 dangerous Regression Tes ing in CFG CFG W Prototype Implementations W Program P T Test Suite Modified Program P Regression Tes ing Mary Jean Harrold Test Suite T Empirical Studies a Study 1 Testsuite selection using DejaVu Testsuite selection for all subjects Timings for player subject Study 2 Testsuite selection in industry Boeing Microsoft Regression Tes ing Mary Jean Harrold Regression Tes ing Subjects For Study 1 W siemens Seven C programs 300LOC Siemens Labs 742 versions 10005000 tests calc Microsoft NT Calc C program 2KLOC 9 versions 388 tests space European Space Agency C program for satellite antennae adjustment 11KLOC 33 versions 10000 tests avionics Avionics Ada83 program 22KLOC 2 versions 310 tests player Internet Empire C program 50KLOC 5 versions no tests created 1000 tests Mary Jean Harrold ArisstotlecDejaVuc Test suite Executable T P X Test History lnpuU Output AIistotle analysis system DejaVu Modi ed C Source P Selected Test Cases T Mary Jean Harrold Regression Tes ing Study 1 TestSuite Selection By DejaVu For All Subjects W 60 50 40 30 20 Tests Selected 10 siemens calc space avionics player Program Name Regression Tes ing Mary Jean Harrold Study 1 Timings For Player N I Run All Tests in Test Suite I Run DejaVu Run Tests Selected By DejaVul 6 Time in hours o Dl N 13 IF UI V1 V2 V3 V4 V5 Versions of Player Regression Tes ing Mary Jean Harrold Study 2 TestSuite Selection In An Industrial Setting What we did Integrated DejaVu into Rational Apex development environment Performed experiments on 20KLOC Level A software Regression Tes ing Mary Jean Harrold ApexTestMateAda83lDejaVuAda83 Test Suite EXSIEHAtable Test T History InpuU Output W Rational Apex New DeriaVu Modi ed Ada Source P DejaVu Ada Selected Test Cases T Regression Tes ing Mary Jean Harrold Study 2 TestSuite Selection In An Industrial Setting W What we found Good reduction But still expensivereduced from 7 weeks to 21 weeks Regression Tes ing Mary Jean Harrold Testsuite Reduction W T999 Ram39s n T inn What if T T T grows too big as new tests are added Mary Jean Harrold Testsuite Reduction W T999 Regres What if T T T grows too big as new tests are added Weight test cases in T according to some criterion C where C is usually coverage and then also consider cost importance errorproneness etc or combination Mary Jean Harrold Testsuite Reduction Reduce T so that it still meets C T999 T999 Regres Mary Jean Harrold Study 2 TestSuite Selection In An Industrial Setting W What we found Test suite could be reduced by 30 and still get the coverage required by the FAA Regression Tes ing Mary Jean Harrold Study 2 TestSuite Selection In An Industrial Setting W What we did Integrated DejaVu into Microsoft development environment Performed experiments on Microsoft Word and Of ce DLLs Regression Tes ing Mary Jean Harrold Microsoft SystemDejaVuc InpuU Output Microso analysis system DejaVu Mary Jean Harrold Regression Tes ing Study 2 TestSuite Selection In An Industrial Setting W What we found High percentage oftests selected Core functionality and startup code often changed Regression Tes ing Mary Jean Harrold Testsuite Prioritization W What if T is still too big to run in the time allowed T9 mZHH Regression Tes ing Mary Jean Harrold Unified Software Development Process UDSP or USP Complement to UML Rational Unified Process RUP IBM owns Rational now No OMG involvement Organizational vocabulary plus use of UML Key Elements quotUsecase driven Architecture centric Iterative and incrementalquot UseCase Driven A use case is a sequence of actors and actions Related to user stories and scenarios The set of use cases form the use case model Represented in UML with a UseCase diagram They serve as a usercentered functional specification Similar to a data flow diagram They drive the development process They are developed in tandem with the system architecture ArchitectureCentric Highest level of system design Comprises different views including static and dynamic Can include the platform framework reusable resources deployment and nonfunctional requirements May describe usecase independent components Eg those mandated by the platform Key use cases suggest structural units Components and classes The architecture is refined as use cases are refined Iterative and Incremental Iteration is a unit of process eg a subproject Increment is a unit of product such as a partial system Each iteration is based on a set of use cases selected for risk mitigation May refine improve or add to provide additional functionality to existing increments Vocabulary from Jacobsen et al Project A development effort taking a system through a software life cycle Comprises a set of cycles Software Life Cycle A cycle over four the four phases in the following order inception elaboration construction transition Each cycle releases a productionready version of the project Vocabulary 2 Phase The span of time between two major milestones of a development process Comprises a series of iterations Each phase addresses each of the five workflow albeit not equally Terminates in a milestone Iteration A distinct set of activities conducted according a devoted iteration plan and evaluation criteria that results in a release either internal or external Vocabulary 3 Workfow A realization of a part of a business use case Can be described in terms of activity diagrams that include participating workers the activities they perform and the artifacts they produce Comprises a set of Activities UDSP has five kinds of workflows requirements analysis design implementation testing Vocabulary 4 Activity A tangible unit of work performed by a worker in a work ow that 1 implies a well defined responsibility for the worker 2 yields a welldefined result a set of artifacts based on a welldefined input another set of artifacts and 3 represents a unit of work with crisply defined boundaries that is likely to be referred to in a project plan when tasks are assigned to individuals Finergrained than what we have used so far Vocabulary 5 Software Development Process A concept that works as a template that can be reused by creating instances of it The de nition of a complete set of activities needed to transform users requirements into a consistent set of artifacts that represent a software product and later to transform changes in those requirements into a new consistent set of artifacts Should be specialized to an organization and project39s needs Workflows Phases amp Iterations Phases core Work ows Inception I Elaboration I Construction Transition I I I I 1 i I I I l I I Requirements I I An iteration In the I I I I J Ielaburatton phase I I I I Analysis Design Implementation Test Iterations Requirements Workflow from Jacobsen et al Work to be done Resulting Artifacts List candidate Feature list requirements Understand system context Business or domain model Capture functional Usecase model requirements Capture nonfunctional Supplementary requirements requirements or individual use cases for usecase specific requirements Requirements Workflow 2 Artifacts Usecase model actor architecture description glossary user interface prototype Workers system analyst usecase specifier user interface designer architect Activities find actors and use cases prioritize use cases detail a use case prototype user interface structure the usecase model Analysis Workflow Conceptual structural model UML Boundary control and entity persistent information classes Refinement and structuring of requirements Added precision First cut at design 1 5 ratio of classes Artifacts analysis model usecase realization analysis package architectural description Workers Architect usecase engineer component engineer Activities architectural analysis analyze a use case analyze a class analyze a package Design Workflow Understand nonfunctional requirements specify implementation decompose implementation work specify interfaces create diagram create seamless abstraction metaphor Design Workflow 2 Artifacts design model design class use case realization design subsystem interface architecture description design deployment model architecture description deployment Workers architect usecase engineer component engineer Activities architecture design design a use case design a class design a subsystem Implementation Workflow Plan integration of increment determine physical deployment implement classes and subsystems unit test Artifacts implementation model subsystem interface architecture description build plan Workers architect component engineer system integrator Activities architecture implementation system integration subsystem implementation class implementation unit test Test Workflow Iteration test plan test implementation test performance Artifacts test model test case test procedure test component automation test plan defect test evaluation Workers test designer component engineer integration tester system tester Activities plan test design test implement test perform integration test perform system test evaluate test Overall Work Products Requirements Architecture UML Use cases Visual models UML Nonfunctional Analysis specification Design static and Test cases dynam39c Implementation Source code packages Manuals Deployment machines and processes Phases Inception Conception vision business case risk analysis initial project planning vague use cases and architecture Elaboration Use cases and architecture refined modeling selection of key use cases refined plan Construction Development Transition Beta release minor revisions manufacturing user training etc 59quot XP Methods httpwwwextremeproqramminqorqruleshtml Planning Designing Coding Testing 39 7 1 Extreme Programming Project A Test Scena os New User Story User Storie Load Facton or Rxsk Bugg Use Cases Requh quot78715 gt Latest Cem ed Commumem S stemProm e Twme Plannin SchedMe Verswon Functlpnal Verswon y Metaphor typ ESUmates Gameg Tesung 439Dellvery sV m Technology Spike 9 Evaluation Next terauon WNQWPWN 1 Planning User stories are written Release planning creates the schedule Make frequent small releases The Project Velocity is measured The project is divided into iterations Iteration planning starts each iteration Move people around A standup meeting starts each day Fix XP when it breaks 11 User Stories Used for time estimation and planning 1 2 or 3 weeks of ideal development time Replace requirements documents Written by the customer Three sentences Source of acceptance tests Focus on user needs 12 Release Planning Release iteration Iteration user story Time or scope feature boxed Project velocity Justintime iteration planning quotscope resources time and qualityquot Management sets 3 of 4 development the other b v 4 1 PlanningFeedback Loops Release Plan A Extnmo Programmmg Months gt Iteratlon Plan ff Weeks Ir Acceptance Test lt Days l quotx39 f Stand Up Meetlng A f One Day zquot x r gt Palr Negotlatlon d fa x r Hours r gt Unit Test Minutes Pair Programming Seconds Code 1 4 Project Velocity Add up estimates for the user stories that were finished during an iteration Use this as a limit for the next iteration actual timeuserstory estimates fantasy factor Available timefantasy factor estimated time allowed Total up the estimates for the programming tasks finished during the iteration Same adjustment as above Must still make an initial uninformed estimate 15 Iterative Development Each iteration 13 weeks Constant over the course of the project Heartbeat Promotes accurate velocitybased estimates 16 Iteration Planning 13 weeks per iteration Based on prioritized user stories and failed acceptance tests Snow plowing Project velocity from the last iteration is used to determine how much to do Programming tasks written on index cards Each task is 13 ideal programming days Developer selection and time estimation Iteration v gt 4 39 ma winnmmmd N w User Stmy Un mshed Tasks Load Factor or Risk Snuw Maw ear n and commune 7 Commmcate Schedule asks New Funcuonahty Iteration terauon anningmr Development Latest VVerslon A Pl ad I i n ms s Meetmg Wm Bug xes Bugs ay by Day 17 Move People Around Cross training Risk reduction strategy Pair programming