Project Management & Software Project Management & Software Engineering Techniques to Achieve High Engineering Techniques to Achieve High

Software QualitySoftware Quality

IntroductionIntroduction

• What is Quality?What is Quality?• Project Management PracticesProject Management Practices• Software Engineering PracticesSoftware Engineering Practices

– PurposePurpose– WorkflowsWorkflows– TemplatesTemplates

• Process Improvement PracticesProcess Improvement Practices• Review Case Studies to Reveal TechniquesReview Case Studies to Reveal Techniques

Software EngineeringSoftware Engineering

• Best PracticesBest Practices• Business ModelingBusiness Modeling• Requirements AnalysisRequirements Analysis• DesignDesign• Coding & Unit TestingCoding & Unit Testing• Software TestingSoftware Testing• Software ReleaseSoftware Release

• ModelingModeling– Simplification of realitySimplification of reality– Enough Detail to develop and review effectivelyEnough Detail to develop and review effectively

Engineering Best PracticesEngineering Best Practices

• Analyse the ProblemAnalyse the Problem• Qualify the SolutionQualify the Solution• Break up the SolutionBreak up the Solution• Control the RelationshipsControl the Relationships

Quality Assurance Best PracticesQuality Assurance Best Practices

• What are they?What are they?

QualityControl

ConfigurationManagement

Validation &Verification

Testing &Evaluation

PlanningProduct

VisibilityTraceability

ProductIntegrity

Business ModelingBusiness Modeling

• Purpose:Purpose:– Understand Business Domain of an organizationUnderstand Business Domain of an organization

• Identify Business Actors and Business ObjectsIdentify Business Actors and Business Objects

– Communicate a common understanding to stakeholdersCommunicate a common understanding to stakeholders– Derive system requirementsDerive system requirements– Justify Business CaseJustify Business Case

• Decreased CostsDecreased Costs• Increased RevenueIncreased Revenue

• WorkflowWorkflow– Find Business Actors and Use CasesFind Business Actors and Use Cases– Develop Business Use CasesDevelop Business Use Cases– Review & Update Business Use CasesReview & Update Business Use Cases

Business ModelingBusiness Modeling

• TemplateTemplate– Context and ScopeContext and Scope– Business Use CasesBusiness Use Cases

• Business Use Case ModelBusiness Use Case Model• ActorsActors

– Name, Role, Description, Use Case ListName, Role, Description, Use Case List

• Business Use CasesBusiness Use Cases– Goal, Main Scenario, Alternate ScenarioGoal, Main Scenario, Alternate Scenario

– Business Object ModelBusiness Object Model• Business Workers, Business EntitiesBusiness Workers, Business Entities• How BUCs are performed in terms of theseHow BUCs are performed in terms of these• Class represents organisational responsibilityClass represents organisational responsibility

– Supplementary Business SpecificationSupplementary Business Specification

Business Modeling LessonsBusiness Modeling Lessons

• Identifying Use Cases that aren’t Business Use CasesIdentifying Use Cases that aren’t Business Use Cases– Business Actors are external to businessBusiness Actors are external to business– BUCs are business processesBUCs are business processes

• Identifying Business Objects that aren’t Business Identifying Business Objects that aren’t Business ObjectsObjects

• Doing it when not necessaryDoing it when not necessary– Not for all new featuresNot for all new features– Do for new projectsDo for new projects– Do when lots of people involvedDo when lots of people involved– Do when lots of information to handleDo when lots of information to handle

• Business Justification not being done yetBusiness Justification not being done yet

Requirements AnalysisRequirements Analysis

• PurposePurpose– To come to an agreement with the customer and the To come to an agreement with the customer and the

users on what the system should dousers on what the system should do– Basis for estimation and planning the technical contents Basis for estimation and planning the technical contents

of iterationsof iterations– Define a User Interface for the SystemDefine a User Interface for the System

• Classic DefinitionClassic Definition– A Requirement is a condition or capability to which a A Requirement is a condition or capability to which a

system must conformsystem must conform

• Definition for UseDefinition for Use– WHAT the system does, NOT HOWWHAT the system does, NOT HOW

Requirements AnalysisRequirements Analysis

• WorkflowWorkflow– Requirements InputRequirements Input

• PrototypingPrototyping• Business modelingBusiness modeling• Joint application developmentJoint application development• Request for CommentRequest for Comment

– Develop RequirementsDevelop Requirements• TemplateTemplate

– Requirements Review & UpdateRequirements Review & Update• ReviewReview

– Quality control mechanismQuality control mechanism– Requirements under configuration managementRequirements under configuration management– Review checklistsReview checklists

» Appropriate scope, ambiguous, clear, missing requirementsAppropriate scope, ambiguous, clear, missing requirements

Requirements AnalysisRequirements Analysis

• TemplateTemplate– ScopeScope

• Assumptions, Dependencies, ConstraintsAssumptions, Dependencies, Constraints

• Use case diagramUse case diagram

– Use CasesUse Cases• ActorsActors

• ScenariosScenarios

• Activity DiagramsActivity Diagrams

• Screen LayoutsScreen Layouts

Requirements AnalysisRequirements Analysis

• TemplateTemplate– RequirementsRequirements

• FunctionalFunctional

• UsabilityUsability

• ReliabilityReliability

• PerformancePerformance

• SupportabilitySupportability

• EnvironmentalEnvironmental

• DocumentationDocumentation

• SecuritySecurity

• OtherOther

– ConsequencesConsequences

Requirements AnalysisRequirements Analysis

– Object ModelingObject Modeling• AttributesAttributes

• ResponsibilitiesResponsibilities

• RelationshipsRelationships

• Boundary, Control or EntityBoundary, Control or Entity

Requirements Analysis LessonsRequirements Analysis Lessons

• Understand Needs - the WhyUnderstand Needs - the Why– Allows prioritisationAllows prioritisation– Allows trade-offs & good design decisionsAllows trade-offs & good design decisions

• Requirements that aren’t requirementsRequirements that aren’t requirements– Propose or lean towards a solutionPropose or lean towards a solution– Describe the HOWDescribe the HOW

Requirements Analysis LessonsRequirements Analysis Lessons

• Use casesUse cases– Over reliance on a main scenario…not enough alternative Over reliance on a main scenario…not enough alternative

scenariosscenarios– Weak expression in scenario stepsWeak expression in scenario steps

• Don’t allow steps to become too long or descriptiveDon’t allow steps to become too long or descriptive• Prefer active voice…a verb is said to be in the active voice if its Prefer active voice…a verb is said to be in the active voice if its

subject is the agent of the actionsubject is the agent of the action

– Use activity diagrams when use descriptions become complex Use activity diagrams when use descriptions become complex and repetitiveand repetitive

• Gives give clear definition of scope and level then use casesGives give clear definition of scope and level then use cases

– User Interface PrototypesUser Interface Prototypes• Good visual feedback for user by capturing interactions with systemGood visual feedback for user by capturing interactions with system

– Don’t let it become the end of requirements analysis thoughDon’t let it become the end of requirements analysis though

DesignDesign• PurposePurpose

– Translate requirements into a specification that describes how Translate requirements into a specification that describes how to implement the systemto implement the system

– HOW we do requirement XHOW we do requirement X

• WorkflowWorkflow– Design Input and Preliminary Design ReviewDesign Input and Preliminary Design Review

• PrototypesPrototypes– Good risk mitigationGood risk mitigation– Examines non-functional requirementsExamines non-functional requirements

• Request for CommentRequest for Comment• PDRPDR

– Good for junior engineersGood for junior engineers

DesignDesign

• WorkflowWorkflow– Design DevelopmentDesign Development

• 4+1 view of Architecture4+1 view of Architecture– Use cases (+1)Use cases (+1)– Logical ViewLogical View– Process ViewProcess View– Deployment ViewDeployment View– Implementation ViewImplementation View

• Detailed DesignDetailed Design• TemplateTemplate

– Design ReviewDesign Review• Quality control mechanismQuality control mechanism• Design under configuration managementDesign under configuration management• Verification of RequirementsVerification of Requirements• Design EvaluationDesign Evaluation

– ReuseReuse– MaintainabilityMaintainability– ReliabilityReliability– PerformancePerformance– Consistent with ArchitectureConsistent with Architecture

DesignDesign

• TemplateTemplate– ScopeScope– DesignDesign

• Use Case viewUse Case view• Logical Object ModelLogical Object Model• Process viewProcess view• Deployment viewDeployment view• Implementation viewImplementation view

– Design AssessmentDesign Assessment• Design AlternativesDesign Alternatives• MaintainabilityMaintainability• ReliabilityReliability• PerformancePerformance

• Architecture and Detailed Design drill down on these at Architecture and Detailed Design drill down on these at different levelsdifferent levels

Design LessonsDesign Lessons

• Object ModelsObject Models– Finding Objects and Classes that aren’tFinding Objects and Classes that aren’t

• Betrand Meyer “The Grand Mistake”Betrand Meyer “The Grand Mistake”

• ““This class performs…” and Single function classesThis class performs…” and Single function classes

– Remember, classes are usually a noun or adjectiveRemember, classes are usually a noun or adjective

• Non-functional requirementsNon-functional requirements– Design for these, DON’T test them inDesign for these, DON’T test them in

• 4+1 Architecture4+1 Architecture– Only do necessary viewsOnly do necessary views– Architecture that is NOTArchitecture that is NOT

Coding & Unit TestingCoding & Unit Testing• PurposePurpose

– To implement classes and objects in terms of To implement classes and objects in terms of componentscomponents

– To test the developed components as unitsTo test the developed components as units– To integrate into an executable system the results To integrate into an executable system the results

produced by individual implementers or teamsproduced by individual implementers or teams

• WorkflowWorkflow– Code (at last!!!!)Code (at last!!!!)– Code review & unit testCode review & unit test

• Which one firstWhich one first• Quality Control mechanismQuality Control mechanism

– Coding standardsCoding standards– Path Flow CoveragePath Flow Coverage

• Once reviewed under configuration managementOnce reviewed under configuration management• Verify DesignVerify Design• Validate requirementsValidate requirements

Coding & Unit TestingCoding & Unit Testing

• Template & toolsTemplate & tools– C++ & Header templatesC++ & Header templates– Automated Testing InfrastructureAutomated Testing Infrastructure

• TstlibTstlib• Run nightlyRun nightly• Results publishedResults published

Coding & Unit TestingCoding & Unit Testing

• Template & toolsTemplate & tools– Path Flow Coverage (PFC)Path Flow Coverage (PFC)

• White Box TestingWhite Box Testing• Unit Testing should result in high PFCUnit Testing should result in high PFC

Coding & Unit TestingCoding & Unit Testing

• Template & ToolsTemplate & Tools– Path Flow CoveragePath Flow Coverage

Coding & Unit TestingCoding & Unit Testing

• Templates & ToolsTemplates & Tools– Revision Control System (RCS)Revision Control System (RCS)

• Maintenance of a tree of revisionsMaintenance of a tree of revisions– Trunk revisions are on central lineTrunk revisions are on central line– Branch revisions are to the sidesBranch revisions are to the sides– Trunk revisions, branches and branch revisions can be labeled symbolicallyTrunk revisions, branches and branch revisions can be labeled symbolically

• Resolution of access conflict and merging of revisions and resolution of conflictsResolution of access conflict and merging of revisions and resolution of conflicts• Release and configuration controlRelease and configuration control

3.0 3.48 4.0 4.12 4.36 ...

3.48.1 3.48.1.1

4.12.1

4.36.1 4.36.1.7

trunk

d420p6d420p7

d410d350

CPE branch CPE branch

branch

rev.

d420

d350p1

d300 d400

4.12.1.1

Product: OpenUI DevelopmentFile: windows1.cxx

Coding & Unit TestingCoding & Unit Testing• Templates & ToolsTemplates & Tools

– Revision Control System (RCS)Revision Control System (RCS)• Nightly BuildsNightly Builds• Daily RCS logsDaily RCS logs

• *** /src/forms/master/src/eqlib/common/fxform.cxx,v ****** /src/forms/master/src/eqlib/common/fxform.cxx,v ***revision 3.2revision 3.2date: 1996/04/12 04:25:39; author: shaun; state: Exp; lines: +4 -4date: 1996/04/12 04:25:39; author: shaun; state: Exp; lines: +4 -4DTS 9001. Previous change wasn't quite correct. Reviewers: pca, agw.DTS 9001. Previous change wasn't quite correct. Reviewers: pca, agw.==============================================================================================*** /src/forms/master/src/eqlib/common/text1.cxx,v ****** /src/forms/master/src/eqlib/common/text1.cxx,v ***revision 3.33revision 3.33date: 1996/04/12 06:07:20; author: joeca; state: Exp; lines: +4 -3date: 1996/04/12 06:07:20; author: joeca; state: Exp; lines: +4 -3DTS9001: added member initialization for copy constructor to stop purifyDTS9001: added member initialization for copy constructor to stop purifyUMR's. Rev michaelUMR's. Rev michael==============================================================================================*** /src/forms/master/src/eqlib/common/browser.cxx,v ****** /src/forms/master/src/eqlib/common/browser.cxx,v ***revision 1.11.3revision 1.11.3date: 1996/04/12 06:09:17; author: michael; state: Exp; date: 1996/04/12 06:09:17; author: michael; state: Exp; lines: +38 -29lines: +38 -29DTS14306:Fixed msie i/f to work with dde calls. rev joeca.DTS14306:Fixed msie i/f to work with dde calls. rev joeca.==============================================================================================

Coding & Unit Testing LessonsCoding & Unit Testing Lessons

• Keep modules smallKeep modules small– Reduces complexityReduces complexity– Makes code easier to understandMakes code easier to understand

• Develop Unit tests as you codeDevelop Unit tests as you code• Avoid evil hack and slash temptation when you Avoid evil hack and slash temptation when you

uncover significant design and requirements uncover significant design and requirements defectsdefects

Software TestingSoftware Testing

• PurposePurpose– To execute a program with the intent of finding an errorTo execute a program with the intent of finding an error

• To Break the ProgramTo Break the Program

– Verify that all requirements have been correctly implementedVerify that all requirements have been correctly implemented

• WorkflowWorkflow– Develop Test Plan & reviewDevelop Test Plan & review

• TemplateTemplate• Review for Team resource plans, test case selection, risk reduction Review for Team resource plans, test case selection, risk reduction

strategies, release criteria applied, conformance to standards, inter strategies, release criteria applied, conformance to standards, inter team interactions are planned and coordinatedteam interactions are planned and coordinated

– Develop Test Procedure & reviewDevelop Test Procedure & review• TemplateTemplate• Review for clarify, completeness, usability, reusability, traceability to Review for clarify, completeness, usability, reusability, traceability to

requirements, satisfies plan, conformance to standardsrequirements, satisfies plan, conformance to standards

Software TestingSoftware Testing

• WorkflowWorkflow– Develop Test Scripts & reviewDevelop Test Scripts & review

• TemplateTemplate• Review for satisfaction of test case, test script coding standardsReview for satisfaction of test case, test script coding standards• Testing toolsTesting tools

– Perform TestsPerform Tests• FormsForms• Testing toolsTesting tools

– Summarise and Review Test ResultsSummarise and Review Test Results• FormsForms• Review for release readinessReview for release readiness

Software TestingSoftware Testing

• Templates & ToolsTemplates & Tools– Test PlanningTest Planning

• ScopeScope• ApproachApproach• EnvironmentEnvironment

– Test ProcedureTest Procedure• ScopeScope• Test case designTest case design

– Equivalence PartitioningEquivalence Partitioning– Limits TestingLimits Testing

• Test casesTest cases

Software TestingSoftware Testing

• Templates & ToolsTemplates & Tools– Test scriptsTest scripts

• Regression suitesRegression suites• Common Testing Infrastructure Library (CTIL)Common Testing Infrastructure Library (CTIL)• SilkTestSilkTest

– Perform TestsPerform Tests• Manual TestingManual Testing• Efficiency - Purify & QuantifyEfficiency - Purify & Quantify• Reliability - Volume Testing & Limits TestingReliability - Volume Testing & Limits Testing• Memory Usage TestingMemory Usage Testing• GUI Testing - UsabilityGUI Testing - Usability

– Test SummariesTest Summaries

Software Testing LessonsSoftware Testing Lessons

• Thoroughly inspect the result of each testThoroughly inspect the result of each test• Test cases must be written for the invalid and unexpected Test cases must be written for the invalid and unexpected

(as well as the valid and expected)(as well as the valid and expected)• Make test cases and data repeatableMake test cases and data repeatable• Do NOT plan a testing effort on the tacit assumption that no Do NOT plan a testing effort on the tacit assumption that no

errors will be founderrors will be found• Don’t automate everythingDon’t automate everything

– Automate where there is a benefitAutomate where there is a benefit

• Apply coding workflows to Test ScriptsApply coding workflows to Test Scripts• Recognise that Testware is as much a deliverable as Recognise that Testware is as much a deliverable as

softwaresoftware

Software Testing LessonsSoftware Testing Lessons

• Regression test suitesRegression test suites– Ensure they are maintainedEnsure they are maintained– Build capability to recover from errorsBuild capability to recover from errors– Structure tests so that success is not dependent between test Structure tests so that success is not dependent between test

casescases– Start each test from a known base stateStart each test from a known base state

Software ReleaseSoftware Release

• PurposePurpose– To determine if the product is ready for use by our To determine if the product is ready for use by our

customers by ensuring that all requirements and release customers by ensuring that all requirements and release criteria have been metcriteria have been met

• WorkflowWorkflow– Product Development Testing is complete and Release Product Development Testing is complete and Release

Criteria metCriteria met• Dependent on release typeDependent on release type

– Alpha, Beta, Manufacturing releaseAlpha, Beta, Manufacturing release– Update, General AvailabilityUpdate, General Availability

Software ReleaseSoftware Release

• WorkflowWorkflow– Defect Density severity measuresDefect Density severity measures

• CriticalCritical

• SeriousSerious

• MediumMedium

• LowLow

– Coverage measuresCoverage measures• For new and modified codeFor new and modified code

Software ReleaseSoftware Release

• WorkflowWorkflow– Customer Care release criteria metCustomer Care release criteria met

• Customer usability and upgrade impactCustomer usability and upgrade impact

• Release notes and documentation usabilityRelease notes and documentation usability

– Manufacturing releaseManufacturing release• Master source and build CD’s cutMaster source and build CD’s cut

• Master product CD cutMaster product CD cut

• Escrow cutEscrow cut

• CD autorunCD autorun

Software Release ChecklistSoftware Release Checklist

• Release ChecklistRelease Checklist– All stakeholder groups sign-off that release criteria have been All stakeholder groups sign-off that release criteria have been

metmet– Guides developers through the release processGuides developers through the release process– Records notes about the releaseRecords notes about the release– Identifies:Identifies:

• Product nameProduct name• Package Name and Build NumberPackage Name and Build Number• Release Platform/sRelease Platform/s• Product Distribution DetailsProduct Distribution Details• Product Changes & Defect FixesProduct Changes & Defect Fixes

Process ImprovementProcess Improvement

• Best PracticesBest Practices• Standards & Process FrameworksStandards & Process Frameworks• Continuous ImprovementContinuous Improvement• Process for Process ImprovementProcess for Process Improvement

Process Improvement Best Process Improvement Best PracticesPractices

• Put effort into PreventionPut effort into Prevention• Detect and Correct EarlyDetect and Correct Early• Eliminate the CauseEliminate the Cause• Audit the WorkAudit the Work

– Process and Project LevelProcess and Project Level

Standards & Process FrameworksStandards & Process Frameworks

• ModelsModels– ISO 9001ISO 9001– SEI CMMSEI CMM– RUPRUP– MentorMentor– Extreme ProgrammingExtreme Programming

• Xerox - “Steal from others but Adapt”Xerox - “Steal from others but Adapt”

Continuous ImprovementContinuous Improvement

• Wedge and Ball model for continuous improvementWedge and Ball model for continuous improvement

Quality

Plan

DoCheck

Act

QA

Process for Process ImprovementProcess for Process Improvement

• Specify Goals of ProcessSpecify Goals of Process– SimpleSimple– Meet customer and market requirementsMeet customer and market requirements– Reduce development timeReduce development time– Produce high quality products by putting effort into preventionProduce high quality products by putting effort into prevention– Identify & remove wastesIdentify & remove wastes

• WaitingWaiting• Inappropriate processingInappropriate processing• Unnecessary actionsUnnecessary actions• TransportingTransporting• DefectsDefects• OverproductionOverproduction• Unnecessary inventoryUnnecessary inventory

Process for Process ImprovementProcess for Process Improvement

• Identify & prioritise current process issues & select headingsIdentify & prioritise current process issues & select headings– Brainstorm on issuesBrainstorm on issues– Fishbone diagram (Cause-Effect Diagram)Fishbone diagram (Cause-Effect Diagram)

• Analyse issues & propose solutions to address issuesAnalyse issues & propose solutions to address issues– BrainstormingBrainstorming– Why-WhyWhy-Why– How-HowHow-How

• Define process and review including selection of methods and Define process and review including selection of methods and development standardsdevelopment standards– Activity DiagramsActivity Diagrams

• Develop and review templates and work instructions to support Develop and review templates and work instructions to support processprocess

• Trial new processes, methods, templates and tools as appropriateTrial new processes, methods, templates and tools as appropriate• Training of peopleTraining of people

ConclusionConclusion

Use Software Engineering and Process Improvement Use Software Engineering and Process Improvement techniques to produce high quality software and techniques to produce high quality software and improve your own personal practices as well as improve your own personal practices as well as

that of your organisationthat of your organisation

Closing RemarksClosing Remarks

• Blessing by Patron Saint of Technology, St. DogbertBlessing by Patron Saint of Technology, St. Dogbert

InfoInfo

• OSA - OSA - http://www.http://www.osaosa.com.au/common/.com.au/common/pptppt/missile./missile.pptppt– ACS Presentation on 4P’s of Short Cycle Product ACS Presentation on 4P’s of Short Cycle Product

DevelopmentDevelopment

• Rational – Rational – http://www.rational.com/http://www.rational.com/– Unified Software Development ProcessUnified Software Development Process

• Constantine & Lockwood – Constantine & Lockwood – http://www.http://www.foruseforuse.com/.com/– Software for UseSoftware for Use