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 Jon Rugaber in Fall. Since its upload, it has received 26 views. For similar materials see /class/234034/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.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 11/02/15
Sort Exercise Sorting is a wellunderstood concept that is surprisingly hard to specify precisely For this exercise try to formally specify a SORT routine that takes a vector of integer values as input and returns a sorted vector of integer values as output You may assume the routine sorts in ascending order To do this try the following steps 1 2 First give a signature for the routine Then try to describe the relation between the input and the output in English Now try to specify the relation in predicate calculus use pre and post conditions 1 Signature Vectorltintgt Y SORTVectorltintgt X X and Y are explicitly named so we can use them in the pre and post conditions int could actually be any data type which supports a comparison gt operator Alternatively a relational form could be used SORTVectorltintgt X Vectorltintgt Y 2 English Specification Trouble Spots What does your specification do in the following situations lt1 lt1 lt1 lt1 lt1 2gt gtlt4 1 I N 2 3 2 I 5gt 3gt gtlt1 3gt 3gt 2 2 2gt gt 3gt 2 3gt gtlt1 l 3 2 2 2 3 3 2 English Specification Y is an ordered version of X Y is ordered Y and X have the same elements With the same numbers of occurrences 3 More Precise Specification Now express the same behavior more precisely a First give a signature parameter and return types Should be the same as what you have already done Next determine the situations in which you expect the program to work its preconditions Then try to describe the relation between the input and the output in English postconditions Finally translate your specifications into predicate calculus b Preconditions b Preconditions For SORT any input vector of integers X qualifies The preconditions assume the types are correct Thus SORT is always able to run This precondition is designated as true c Postconditions c Postconditions 1 Y must be the same length as X c Postconditions 1 Y must be the same length as X 2The output vector Y must be ordered c Postconditions 1Y must be the same length as X 2The output vector Y must be ordered 3The contents of Y must be the quotsame asquot the contents of X c Postconditions 1 Y must be the same length as X 2 The output vector Y must be ordered 3 The contents of Y must be the quotsame asquot the contents of X Everything in X must be in Y Everything in Y must have come from X The number of occurrences of each item in Y must be the same as its number of occurrences in X Another term used to express these properties is to say that Y is a permutation of X Yet another way is to say that if the contents of X and Y are treated as bags the two bags are equal A bag is like a set except that multiple instances of an element are allowed and that a count is kept of the occurrences d Predicate Calculus for SORT Vector Y SORTVector X pre true post LENGTHX LENGTHY A ORDEREDYA PERMUTATIONX Y 1 Y is the Same Length as X X and Y are Vectors Vectors as a datatype have properties one of which is their length IXI IYI Xlength Ylength X Y This raises the question of who is responsible for allocating the space for Y Caller preallocates or SORT does the allocation 2 Y is ordered Try to express this property using the predicate calculus 2 Y is ordered 39Vizl silt Y Yi sYi 1 For all positions in Y from the first through the one before the last the value stored in the vector at that position is no greater than the value at the next position Vectors have an indexing operation Counting starts from 1 V reads quotfor allquot 3 The Contents of Y is the quotsame asquot the Contents of X Try to express this in the predicate calculus 3 The Contents of Y is the quotsame asquot the Contents of X Two vectors with the same contents but in which the values may be ordered differently are called permutations Y is a permutation of x PERM x Y Precondition IXI lYl Postconditions X 0 gttrue Xl Yll gtPERMtailX tailY oElj 1ltj Y Xl Ylj A PERMtail concatYl j l Yljl Y Explanation 2 is an if expression with the condition on the left and the consequent on the right There is an implicit quotelsequot between clauses tail is an operation on Vectors that returns a new Vector like the argument except that the first element has been removed concat is an operation on Vectors that creates a new Vector by pasting together the two Vector arguments El reads quotthere existsquot i j denotes the integers from itoj inclusive MUTATION TESTING Whitebox errorbased testing technique Builtin adequacy criteria Toolsuppon The goal of mutation testing is to build an adequate sets of tests Finding faults is a sideeffect ERRORBASED TESTING Devise tests that mimic the kinds of mistakes that people make when constructing programs Offbyone spelling typos etc MUTANTS A mutant is a program P that is similar to the program that you are testing P It differs by a single usually lexical mutation For example imagine that P was identical to P except that exactly one was changed to a That is the programmer had made a typo RUNNING A MUTATION TEST If you run the same test case T on both P and P one of two things can happen 1 P and P produce different results 2 They produce identical results 1 DIFFERENT RESULTS If P and P39 produce different results on T then they both can t be right Determine which version is correct If P39 is correct then you have detected a bug in P Fix the bug and restart testing If P is correct then P39 must have a bug The only difference is in the mutation we introduced That is the test has worked it has found the bug we introduced If this is the case we say that mutant P has been killed by the test case T Proceed with the next mutant on P 2 SAME RESULTS If P and P produce the same results this also might occur for two reasons 1The test case T wasn t good enough to demonstrate the difference Perhaps it didn t even execute the line of code containing the mutation In this case we need to come up with another test That is we keep adding tests until we can kill the mutant 2 P and P are equivalent programs and no tests can be devised that can distinguish them EQUIVALENT MUTANTS Let s say that the line of code we mutated was the following X YZ which we changed to x Y Z If this line occurs directly following the statement ifY2ampampZ X Y Z then no possible test can ever kill this mutant That is within the body of the if both version produce the value 4 for X MOTH RA Mothra is a suite of tools developed at Georgia Tech for performing mutation testing Mutgen generates mutants A testing harness for runs tests on a set of mutants and records the results Godzilla generates test cases USING MOTHRA Select and generate a set of mutants Compose an initial set of test cases and the corresponding outputs that they generate Confirm that the outputs are correct Repeat until all mutants are killed Kill mutants by running the test cases Detect equivalent mutants effectively killing them Generate new tests and determine expected results When you are done you have an adequate suite of tests for the set of errors for which mutants were generated PROBLEMS WITH MUTATION TESTING Performance a large number of mutants are generated Test case execution is simulated Determining expected results oracle This is a problem with all kinds of testing Generating test cases This is a problem with all kinds of testing Equivalencing mutants Forces a deep understanding of the program leading to a good set of tests ASSUMPTIONS Competent Programmer Hypothesis The program being tested is nearly correct It attempt to implement a valid specification The Coupling Effect Large faults particularly those of a semantic nature are coupled with smaller lexical syntactic faults that can be detected with mutation testing FORTRAN Comments begin with C Relational operators EQ LE etc Logical operators OR etc Numerically labeled statements and GOTOS Value returned by a FUNCTION is kept in a pseudovariable with the function name PARAMETER is used for constants On lO denotes standard inputoutput Fixed loop DO stmt var first last incr TRITYPE Categorizes triangles 1 2 scalene 2 2 isosceles 3 2 equilateral 4 2 not a triangle Statistics no loops 28 statements 28 branches 30 conditions 89 paths CATALOG OF MUTANTS AAR array reference by array reference ABS expression by absexpression NEGABS expression by absexpression ZPUSH IF expression 0 0 then killed Generate a test that forces the expression to have value 0 ACR array reference by constant AOR arithmetic operator replacement LEFTOP binary expression by left operand CATALOG 2 RIGHTOP binary expression by right operand MOD binary expression by modleft right ASR array reference by scalar variable CAR array reference by constant CNR array name by comparable array name CRP constant by constant CSR scalar variable by constant CATALOG 3 DER DO statement end label replacement ONETRIP DO statement by nonnull DO DSA DATA statement constant replacement GLR GOTO label replacement LCR logical operator replacement FALSEOP logical expression by FALSE TRUEOP logical expression by TRUE ROR relational operator substitution Refactoring Martin Fowler Refactoring Improving the Design of Existing Code Addison Wesley 1999 Refactoring Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure It is a disciplined way to clean up code that minimizes the chances of introducing bugs In essence when you refactor you are improving the design of the code after it has been written Fowler Background William F Opdyke Refactoring Object Oriented Frameworks PhD dissertation University of Illinois at UrbanaChampagne 1992 Smammk Extreme Programming Refactoring tools Process Design sanity tests quotOKquot or failures Detect design problems Bad Smells Systematically alter the source code of a program in order to improve its deggn Correctness preserving Small step at a time Test with each step Refactoring Testing Sanity test way to quickly tell whether you have broken something Design tests before you start coding add to them with each detected bug Can39t always be done a class at a time For Java place the unit tests in each class39s main method Junit CUnit SUnit testing frameworks If it stinks change it What is a bad smell in code An indication of possible problems with code Why sniff for bad smells In order to identify A source of error Design weaknesses Code that is hard to understand and maintain Code that is hard to enhance Example Duplicated Code Problems Public Enemy 1 Requires parallel changes implying defect persistence Indication of design flaw Resolution Extract and reference common code If across classes consider why two classes have similar responsibility Example Long Method Problems Hard to understand Hard to maintain More constraints assumptions Detection Section comments Too much nesting Too many temporaries Resolution Extract sections into another method Use parameter object method object find the max for int i0 i lt lenlist i compute the histogram for int i0 i lt lenlist i max Maxlist hist Histogramlist Example Data Clumps Classic example Using 3 separate ints RGB to process color Problems Method parameters take in RGB Code processes components separately When data clumps together consider as a candidate for a class Example Type Abuse 0 switch Candidate for possible extension May want to introduce 00 polymorphism Typecast Identify possible locations that can use typesafe containers improve interfaces 0instanceof Double dispatch or hack Examples Change Smells Divergent Change Updating part of class when database changes other part when finance rule changes Shotgun Surgery Change involves many locations Parallel Inheritance A change to one branch needs same change in another Examples Coupling Smells Feature Envy A method is processinginterfacing too much with an foreign object Inappropriate Intimacy Two classes are overly intertwined Message Chains Middle Man Law of Demeter quotOnly talk to your friends who share your concerns Catalog of Refactorings Name Summary Motivation Mechanics Examples Safety conditions Bad Smells Duplicate code factor it Long method split it Large class too many instance variables Long parameter list pass just enough to navigate to what you need Divergent change multiple feature categories Shotgun surgery deocaization Bad Smells 2 Feature envy have to frequently visit other classes to get access to data move to another class Data Clumps subsets of instance variables that are used together create new object Primitive obsession create your own builtin switch statements use subtypes Parallel inheritance hierarchies Bad Smells 3 Lazy class eliminate Speculative generality only used by test cases Temporary field instance variable used only in certain circumstances Message chains sequences of calls Middle man excessive delegation refer directly to delegatee Bad Smells 4 Inappropriate intimacy classes refer to each other too often Alternative classes with different interfaces rename methods to indicate similarities Incomplete library class extend Data class move behavior into class Refused bequest Comments use self documenting names Large Classes Cilluluus cum Data Classes LightWeight Visualizations Message Chains IIICOIGJ DDEI may mime comm wrnevemme M 2mm IIIOm u u ESAMDGJdamtmu 1mm Apyhmmrm dimiSJ mm non0002 a xm xmda NexiSMmg cmm i FmiChdJ Imanxi my Long Params FmszszoAnzyLms meMsg u o o o o o Cnne ulekzcoxd u I u I Examples my 11W J MIME mm lawn Case Study Software to support a video store Track rentals print reports Refactor to improve design Add enhancements Class Diagram Movie Rental Customer priceCode int daysRented int statementO Design Goals Abstraction Information hiding Flexibility Not the same as generality Clarity Irredundancy quotThriftyquot code Refactoring 1 Decompose and Redistribute Statement Method Bad smell long method Refactoring extract method Handle local variables Unmodified each passed in as a parameter Modified thisAmount returned as result Refactoring 2 Rename Variables Provide more descriptive names Avoid name conflicts to assure correctness Guidelines Refactor while reading to gain understanding Try to eliminate the need for comments Try to eliminate the need for local variables in methods Refactoring 3 Move Method 0 amountFor iS in Customer but it doesn t use any Customer data Move it to Rental 3a Give it a new name Remove references to aRental from message invocations Change method invocations to use new name 3b Test after each small change Refactoring 4 Replace Temp with Query Local variables that are only set once in a method act like constants Replace them with calls to the defining method This assumes the method call has no side effect May reduce performance Improves understandability Makes other refactorings easier Refactoring 5 Extract FrequentRenterPofnts Computation Further simplify statement computation New method getFrequentRenterPoints in Rental Some algebraic simplification as well Removes side effects Removes a local variable Refactoring and Enhancements Refactorings leave functionality unchanged This makes testing easier But sometimes refactorings can be used to prepare for an enhancement For example introduce an abstract class that will be subclassed as part of a new feature Possible Enhancements to the Video Store Program HTML version of statement Altered charging rules New classes of movies Interlude 6 Prepare to add htmlStatement One way in which this program might be extended is to add a second output format htmlStatement is a new method for formatting output in HTML instead of text It should not be concerned with the rules for computing charges just with how to format Consequently statements for computing charges should be factored into methods even if this means duplicating loop code These methods will be callable from both statement and htmlStatement Class Diagram Statement Customer valueCustom er Statement headerSmngCuslamer h 1S eachRenlalSmngCuslamer tm tatemem foolerSm39ngCuslamer 4 HtmlStatement TextStatement headerStringCust0mer eachRentalStringCust0mer footerStringCust0mer headerStringCust0mer eachRentalStringCust0mer footerStringCust0mer Refactoring 7 Steps Define a new Statement class with TextStatement and HtmlStatement subclasses Rename statement method to value within the Statement classes and pass a Customer as argument Add getRentals method to return an Enumeration of current Rentals Relax visibility of getTotalCharge and getTotalFrequentRenterPoints Refactoring 7 Steps 2 Prepare methods for all formatspecific functionality and replace existing code with calls to the new methods Remaining calling method can be pulled up into Statement class Declare abstract classes for format specific methods Refactoring 8 Replace Conditional Logic on priceCode with Polymorphism switch statements or else ifs are strong indicators of poor object oriented coding practices They should be replaced by subclasses and polymorphic methods Refactoring 8 Steps First note that the switch statement is discriminating on the type of the movie so it should really be in the Movie class Do the same with the getFrequentRenterPoints method Now the way is prepared for subclassing Movie objects into Regular Childrens and NewRelease movies Refactoring 8 Steps 2 Unfortunately this doesn t work Can you see why Refactoring 8 Steps 2 Unfortunately this doesn t work Can you see why Movies in video stores can change their categories dynamically as for example when a New Release moves into the Regular category But an object can t change its class dynamically Refactoring 8 Steps 3 There is a trick called the state pattern for overcoming this problem It involves introducing a class solely for holding type information We will use the Price class with subclasses for ChildrensPrice NewReleasePrice and RegularPrice These classes provide methods for getCharge andgetFrequentRenterPoints Class Diagram Price MOV1e getC harge days int getchargemays int getFrequentRenterPointsdays int getFre quentRenterPointsdays int A Regula rPrice Childrensprice N ewReleasePrice getChargedays int getChargedays int getFrequentRenterP01ntsdays 1nt getChargedays int Refactoring 8 Steps 4 Move type code behavior into Price class Move switch statement into Price class Replace switch statement with polymorphism Update Movie class to reflect changes Process Assessment Motivation SEI Capability Maturity Model Assessment process Case studies Critique Motivation Risk reduction Quality improvement Productivity increase Capability Maturity Model CMM Developed by the Software Engineering Institute SEI with DoD funding Designed for large organizations doing routine development Assessment and evaluation What39s the difference Five levels of maturity Key processes Extended to CMMI Capability Maturity Model Integration CMM CMM Original maturity model CMMI CMM Integration Generalization of CMM to different kinds of products and activities services acquisitions etc CMMI for Development Evolution of original CMM wrt software The SEI Process Maturity Model Level Characteristic Key Problem Areas Results Optimizing Process improvement Automation Productivity Managed quantitative Changing technology Quallty Process Measured Problem analysis Problem prevention Defined qualitative Process measurement Process defined and Process analysis institutionalized Quantitative quality plans Repeatable intuitive Training Process dependant Technical practice on individuals reviews testing Process focus standards process groups Initial ad hoc chaotic Project management Project planning Configuration management Risk Software quality assurance source SEI Levels Level 1 Initial Instable dependent on individuals Level 2 Repeatable Policies use of experience in planning discipline Level 3 Defined Documented process process group readiness and completion criteria Level 4 Managed Quantitative goals data collection Level 5 Optimized Continuous process improvement Level 1 Initial Process Illdefined inputs cost and schedule overruns Undefined process no repeatability Simple metrics of size staff effort Baseline for later comparison Level 2 Repeatable Process Identified process inputs outputs and constraints No knowledge of how outputs are produced Measures of size Lines of code LOC function points object and method counts Requirements volatility Extent of personnel experience determines success Domain applications development architecture tools methods overall years of experience turnover Key areas Requirements management project planning project tracking subcontract management QA change Management Level 3 Defined Process Activities with definitions and entry exit criteria Measures of requirements complexity design modules code complexity test paths pages of documentation Software Engineering Process Groups SEPGs Quality metrics Defects discovered error density for each activity area Key areas Organizational process definition training program integrated management product engineering intergroup coordination peer reviews Level 4 Managed Process Feedback from early activities is used to set priorities for later stages Data collected Process type extent of reuse production and consumption when are defects detected testing completion criteria configuration management change control traceability links module completion rate Key areas Process measurement and analysis quality management Level 5 Optimizing Process Measures of activities are used to change the process Analogy with Statistical Process Control SPC Key Areas Defect prevention technology innovation process change management Key Practices Level 5 Process change management Technology innovation Defect prevention Level 4 Quality management Process measurement and analysis Level 3 Peer reviews lntergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Level 2 Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Level 1 Assessment Process Selection of assessment team Management commitment Assessment agreement Preparation Training survey questionnaire Assessment Questionnaire analysis discussions with projects and functional area representatives findings feedback presentation Report Follow Up Action plan reassessment after 18 months Assessment Details 1 Assessment team has 68 members some internal some external Either SEI or a vendor Team members have gt 10 years experience team leader has gt 20 years experience Assessment itself takes 35 days 78 YES NO questions Hurdle scoring binary Assessment Details 2 Four or five projects are examined per organization Interviews with 810 functional area representatives FARs from each area QA integration testing coding and unit test requirements and design Implementation process takes 1218 months Followup at the end of this time Example Questionnaire Item 23 Data Management and Analysis Data management deals with the gathering and retention of process metrics Data management requires standardized data definitions data management facilities and a staff to ensure that data is promptly obtained properly checked accurately entered into the database and effectively managed Analysis deals with the subsequent manipulation of the process data to answer questions such as quotIs there a relatively high correlation between error densities found in test and those found in usequot Other types of analyses can assist in determining the optimum use of reviews and resources the tools most needed testing priorities and needed education Questionnaire 2 231 Has a managed and controlled process database been 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 234 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 237 Is a mechanism used for initiating error prevention actions 238 ls review efficiency analyzed for each project 239 ls software productivity analyzed for major process steps Key Process Area Profile Template LEVELS Optimizing LEVEL4 DP Managed Tl PC LEVEL3 PA MS PS FS Defined QM PF NS PS FS PD LEVEL2 Tp Repeatable IM PE IC PR RM NS PS FS LEVEL1 PP Initial PT SM QA CM NS PS FS Case Study Hughes Aircraft 1 500 people in part of one division 1987Leve21990Leve3 CostBenefit 45K assessment cost 400K improvement cost 2M savings 2 increased overhead 18 months implementation 78 staff months 5x improvement in expenditure estimation Case Study Hughes Aircraft 2 Major 1987 recommendations Central data repository Process groups More involvement in requirements process Technology transition organization Major 1990 recommendations More divisionwide data analysis Opportunities for automation SEI Survey of Organizations 1990 113 Projects 85 At Level 1 14 At Level 2 1 At Level 3 Software Process Maturity 50 49 Level Distribution 11 12 13 14 21 22 23 24 31 32 33 34 ourceSEl Maturity Level Quartile Early Results 4ampup A Problem areas Error projection 3 Test and review coverage Process metrics database Design and code reviews Software 2 Software eng training rocess Maturity Software eng process group Level Project planning Change control and CM Regression testing 2 12 28 28 21 9 Software process maturity distribution in quartiles Source lEEE Software More Recent Results CMMI 2005 Number Performance Category Median of Data Low High Points Cost 20 21 3 El Schedule 37 19 2 90 Productivity 62 1 9 255 Quality 50 20 m 132 Customer Satisfaction 14 6 4 55 Return on Investment gt 4 1 16 2 1 J 21 1 CMMI Integrated framework for maturity models Structured by Process Areas CMMI Process Areas Process Management Organizational Process Focus OPF 3 Organizational Process Definition PPD OPDPPD Organizational Training OT Organizational Process Performance OPP Organizational Innovation and Deployment OID Project Management Project Planning PP Project Monitoring and Control PMC Supplier Agreement Management SAM Integrated Project Management PPD lPMPPD Risk Management RSKM Quantitative Project Management QPM Engineering Requirements Management REQM Requirements Development RD Technical Solution TS Product Integration Pl Verification VER Validation VAL Support Configuration Management CM Process and Product Quality Assurance PPQA Measurement and Analysis MA Decision Analysis and Resolution DAR Causal Analysis and Resolution CAR mwmmmwwwwwmhwwmmmmhww Process Management Organizational Process Focus Identified person or group Organizational Process Definition Assets and standards Organizational Training Processes skills knowledge Organizational Process Performance Quantitative expectations data support Organizational Innovation and Deployment Identification evaluation selection and deployment of improvements Project Management Project Planning Activities estimates schedule resources Project Monitoring and Control Tracking corrective action Supplier Agreement Management Status checking and corrective action Integrated Project Management Inclusion of stakeholders integration Risk Management Cost schedule quality functionality Anticipation monitoring mitigation prevention Quantitative Project Management Link to performance data intensive predictions Engineering Requirements Management Allocation component definition consistency checking Requirements Development Identification analysis documentation agreement Technical Solution Design development implementation Product Integration Assembly validation Verification Reviews inspections Validation Satisfaction in customer environment Suppo Configuration Management Integrity of work products versions and changes Process and Product Quality Assurance Standards audits Measurement and Analysis Definition storage reporting analysis Decision Analysis and Resolution Established evaluation criteria adequacy relevance alternative Criterion measurement threshold Causal Analysis and Resolution Correction prevention causal analysis Generic Practices for Establishing Managed Processes Establishing policy Process planning Providing resources Assigning responsibility Training Controlling changes to the process and its work products Identifying and involving process stakeholders Monitoring and control Compliance checking Reviewing status with higherlevel management Adoption and Deployment Management buyin Compliance vs performance drivers Incremental adoption Identified resources and responsibilities Engineering process group Management steering committee Baseline measurements Deficiency identification Action plan Training Generic Practices for Optimizing Processes Establishing a defined process Collecting improvement information Setting quantitative objectives Stabilizing subprocesses Ensuring continuous process improvement metaprocesses Analyzing and correcting root causes of process problems CMM Benefits CMM encapsulates industry best practices DOD sponsorship has enforced process improvement throughout Defense community Quality movement has led to CMM being quite widely used in other sectors Enhanced understanding of the development process Increased control and risk reduction Even Level 2 leads to superior product quality Benefits 2 Migration path to a more mature process More accurate cost estimation and scheduling Objective evaluations of changes in tools and techniques Standardized training Marketing
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'