TDDC88–SammanfattningDidrikGrip–i12didgr

REQUIREMENTS 1

PROJECTPLANNINGANDPROCESSES 6

DESIGNANDARCHITECTURE 13

TESTINGANDSCM 23

QUALITY 29

Requirements“Softwarerequirementsexpresstheneedsandconstraintsplacedonasoftwareproductthatcontributetothesolutionofsomereal-worldproblems.”-Kotonya&SommervilleRequirementengineeringisaboutclarifyingtherequirementstoavoidmisunderstandingsandspecifywhatistobedeliveredintheendoftheproject.Toavoidmisunderstandings,it’simportanttousecompletesentencesandusemodalverbssuchasshall,mustandwill.Elicitation–UnderstandingthetrueneedsofthecustomerCanbeobtainedeitherinternallyfromtheprojectsgoalsandstrategiesorexternallyfromenvironments,stakeholdersoracustomer.Someofthetechniquesareinterviews,scenarios,prototypingorobservationsofcurrentuse.Thetrickistounderstandwhatthecustomerreallyneedsandnotonlywhattheyexplicitlysaytheyneed–probethinking,understandingwhythecustomeranswersastheydo.“IfI’daskedmycustomerswhattheywanted,they’dhavesaidafasterhorse.”–HenryFordAnalysis–ClassifyingandresolveconflictsbetweenrequirementsWeclassifytherequirementsindifferentclasseswithrespecttoe.g.

- Functionalvs.Non-functional- Source- Productorprocessrequirements- Priority- Scope–Affectedcomponents- Stability

Thisisoftenaccomplishedwithconceptualmodeling,likeuse-cases,class-modelsorER-modeling:

Use-casemodeling“aparticularformorpatternorexemplarofusage,ascenariothatbeginswithsomeuserofthesysteminitiatingsometransactionofsequenceofinterrelatedevents.”–Jacobsonetal.

Ause-casediagram

Ause-caseisaspecificactivity,thecirclesabove,andisoftenaccompaniedbyadescription.Exampleofause-casewherethenounsarebeinganalyzedandsomearesetasrequiredclasses:

Ause-casewithclassesanalysed

30

Identifying classes: noun analysis

•machine – real noun handled by the system

•cup – unit for beverage

•coin – detail of user and machine

•shelf – detail of machine

•pipe – detail of machine

•button– handled by the system

•sugar – detail of coffee

•whitener – detail of coffee

•cup of coffee – handled by the system

•indicator – not discovered

A CoffeeDrinker approaches the machinewith his cup and a coin of SEK 5. Heplaces the cup on the shelf just under thepipe. He then inserts the coin, and pressthe button for coffee to get coffee according to default settings. Optionallyhe might use other buttons to adjust the strength and decide to add sugar and/or whitener. The machine processes the coffee and bell when it is ready. The CoffeeDrinker takes his cup from the shelf.

ClassmodelThisleadsustotheclassmodel,beingdrawnfromtheearlieruse-case:

Classmodeloftheearlieruse-case

ER-diagramWhenitcomestorequireddata,agoodmodelisaclassicER-diagramasisoftenusedindatabasemodeling:

ExampleofanER-diagram

31

The coffee machine class model

CoffeeCustomer

Porter

CupOfCoffee

CanOfCoffee

buys

byus

0..1

0..1

0..*

0..*

makes machine

11

1 111

10..*

Interface CoinHandler Brewer

32

Data model: ER-diagram

Student

Course

NamePersonal numberCurriculum

Enrolled-in

SubjectCourse codeMax-enrolment

SpecificationSRS-IEEEStd830-1998SpecifiesagoodSRS–SoftwareRequirementsSpecification,withthebasicissues:

- Functionality,whatthesoftwareshoulddo- Externalinterfaces,howitinteractswithe.g.peopleandothersoft-orhardware- Performance,speedoffunctionsetc.- Attributes,portability,maintainability,securityetc.- Designconstraints,language,policies,requiredstandardsorotherlimits

AnSRSshould,accordingtoIEEE830,becorrect,unambiguous,rankable,verifiablemodifiableetc.Itshouldonlyconcerntherequirementsthatthesoftwareshallmeetandeveryrequirementshouldbeopenforonlyoneinterpretation.It’salsoimportantthattheSRSrankstherequirementsbystabilityandnecessity.TheSRSshouldNOThowevergointodesigndetailssuchaspartitioningintomodulesordescribeflowsofinformation.Pros:

• Goodchecklist• Manywaystoadaptorganization• Manywaystodetailrequirements• Youdon’tneedtohaveeverything

Cons:

• Takessometimetoreadandunderstand• Verygeneral,needstobetailored• IsnoguaranteeforagoodSRS

Characteristicsofgoodrequirements

• Unitary(Cohesive)–Therequirementaddressesoneandonlyonething.• Complete–Therequirementisfullystatedinoneplacewithnomissinginformation.• Consistent–Therequirementdoesnotcontradictanyotherrequirementandisfully

consistentwithallauthoritativeexternaldocumentation.• Non-Conjugated(Atomic)–Therequirementdoesnotcontainconjunctions.E.g.,

"ThepostalcodefieldmustvalidateAmericanandCanadianpostalcodes"shouldbewrittenastwoseparaterequirements:(1)"ThepostalcodefieldmustvalidateAmericanpostalcodes"and(2)"ThepostalcodefieldmustvalidateCanadianpostalcodes".

• Traceable–Therequirementmeetsallorpartofabusinessneedasstatedbystakeholdersandauthoritativelydocumented.Itspecifiesnomoreandnolessthanwhatisrequired.

• Current–Therequirementhasnotbeenmadeobsoletebythepassageoftime.

• Unambiguous–Therequirementisconciselystatedwithoutrecoursetotechnicaljargon,acronyms(unlessearlierdefined)etc.Itexpressesonlyfactsandnotopinion.Itissubjecttoonlyoneinterpretation.Negativestatementsareavoided.

• Specifyimportance–Therequirementmustspecifyalevelofimportance.• Verifiable–Theimplementationoftherequirementcanbedeterminedthrough

basicpossiblemethodssuchasinspection,demonstration,testingoranalysis.UserstoriesAsa(actor)Iwant(something)sothat(benefit),usedalotintheScrummethodology.Example:”AsastudentIwanttobuyaparkingcardsothatIcandrivethecartoschool.”Priority:3Estimate:4Validation(Formalization)Somemeansofvalidatingrequirements:

• Prototyping• Simulation• SoftwareReviews• Modelchecking• Formalproofs• Acceptancetesting

Wordlist:

• Functionalrequirements–Describesthefunctionsthatthesoftwareistoexecute,canbeeasilytestedbygivinginputandcontrollingtheoutput.Thinkf(x)=y.Example:“Theusershallbeabletoaddanitemtotheshoppingbasket.”

• Non-functionalrequirementscanbedesignconstraintslikelanguagesorqualitymeasurementssuchasresponsetimes.Thelatterisalsocalledperformancerequirements.Example:“Theminimumresponsetimeis2.0seconds”or”ThesystemshallbewritteninJava”

• Feature–AnUSP,adistinguishingcharacteristicofasystemitem.LikeaSMSdeliverynotificationservice.

• RAM–RequirementsAbstractionModel,utilizinglevelsofabstraction.Uptoproductlevelanddowntofunctionlevel.

• Actor–Auserofasysteminause-case,canbehumanorasystem.• Stakeholder–“anindividual,group,ororganization,whomayaffect,beaffectedby,

orperceiveitselftobeaffectedbyadecision,activity,oroutcomeofaproject”Example:Projectleader,management,customer,usergroup,sponsorsetc.

Projectplanningandprocesses“Aprojectisatemporaryendeavourundertakentocreateauniqueproductorservice”,itconsistsofastartingpoint,atleastoneitemhappeningonthewayandagoal.Thereisalwaysabalancebetweengoalandprocess,eitheryouhaveaclearpurposeorgoalbutnopredefinedprocesstofolloworyouhaveastrictprocesswithanuncleargoal.SMARTgoalsSpecific–Straightforward,whatwillyoudoandwhyisitimportant?Measurable–Ifyoucannotmeasureithowdoyouthenknowifthegoalisreached?Agreedupon–AgreeduponbyallstakeholdersRealistic–Possiblewithcurrentresources,knowledgeandtime.Willingandabletodoit.Timely–AcleartimeframeDependentprojectparametersThemostimportantfourparameterstoconsiderwhensettingthegoalsforaprojectare:Calendartime–Howmuchtimedoweneed?Whencanwefinish?Resources–Whatresourcesdowehave?Personnel,knowledge,computingpower,budget?Features–Whatareourfeaturesthatwewanttoimplement?Quality–Whatqualitydowerequireonthefinalproduct?Thesefourarehighlydependentandplanningaprojectmeanstotaketheseintoconsiderationsandcreateatrade-offbetweenthem.GANTT-chartAGANTT-chartisatooltovisualizetheprocess,creatingtaskswithadurationanddependenciestocreateachartwherewecanprioritizeandmakesuretheprojectgetsfinishedontime.

ExampleofaGANTT-chart,makingiteasiertovisualizetheprocessandtimeapproximation.

SEPTEMBER 15, 2015 11Project Managment/Kristian Sandahl

Tasks, duration, and dependencies

Task/Activity Duration

Phases

Gantt-chart

DependencyPhase

Task A Task B

Task A is predecessor (precursor) of Task B

CriticalpathThecriticalpathconsistsoftheactivitieswiththemosttime-sensitivedependencies.Ifanyoftheseactivitiesgetspostponed,thecompleteprojectfallsbehindintime.Itisthereforecriticalthattheactivitiesonthecriticalpathisfinishedontime.

ThecriticalpathcanbefetchedfromtheGANTT-chartanddisplaystheactivitiesthataremostcriticaltotheprojectfinishingontime.

EffortestimationDelphi–Expertsmakeindividualpredictionsandshowthemanonymouslyfordiscussion,repeatifnotconverging.COCOMO–Analgorithmicformulawhereanumbersoffactorsareestimatedusingdatafromearlierprojects.Example:Input:Linesofcode–Output:Effort(Time)Planningpoker–Agileestimation–VariantoftheDelphimethodwhereyouhavecardsmarkedwithunitslikehoursor“effortpoints”inaFibonacci-series.Youthenplacecardsupsidedown,flipsthemanddiscusses.

- Remembertoincludebuffertime!RiskmanagementTypesofrisk:Generalrisk ProjectSpecificriskExample:“Ateammembergetssick”“Theprojectgetsdelayed”

Example:“Andersneedstovisithisfamilysincehisfatherissick”orhardwareissues.

Directrisk IndirectriskWheretheprojecthasgreatcontrol.Example:“Oursystemwillnotscale”

Wheretheprojecthaslittlecontrol.Example:“Theserversfailduetoanearthquake.”

SEPTEMBER 15, 2015 12Project Managment/Kristian Sandahl

Critical path, slack time, and real time

Real time (estimated)

Slack (float) time

Available time = Slack time + Real time

Critical Path

Generalstepsforriskmanagement:1. Riskidentification–“Whatcangowrong?”Brainstormingtofindpossiblerisks.2. Riskanalysis–“Howbadisit?”Prioritizerisksaftermagnitude

a. Probability–Low,moderate,high,veryhigh(1-4)b. Impact–Insignificant,tolerable,serious,catastrophic(1-4)c. RiskMagnitudeIndicator=ProbabilityxImpact

3. Riskplanning–“Whatdowedoifithappens?”a. Avoidance–Reorganizesotheriskdisappears.b. Transfer–Reorganizesosomeoneelsetakestherisk.c. Acceptance

i. Mitigate–Lowertheprobability.ii. Contingencyplan–Lowertheimpact.

TheprojectplanIsatoolfortheprojectmanagertogetaclearoverviewoftheprocessandgoals.It’salsoacommunicationmediumbetweenstakeholdersandspecifieswhatshouldbedone,whenandbywho.Contentsoftheprojectplan:

- Descriptiono Background,constrains,goalsetc.

- Organizationo Roles,availableknowledgeorskills,trainingplans,communication.

- TimeandResourcePlano Milestones,tollgates,deliverables,activities,resources.

- RiskManagemento Risks–probabilityandimpact.o Mitigationandcontingencyplans.

CommonrolesinasoftwareprojectTheonesappliedtoourcurrentprojectismarkedinitalics

- Projectmanager–Ensuresthattheplanisbeingfollowedandgoalsreached.- Productmanager

o Strategic(Productownerorsponsor)–Marketcommunicationandanalysis,budgetresponsibility,decidesfeatures

o Operational–Technicalmanagementandexpert,effortestimation- Configurationmanager–Selectsandmaintainstools,decidesonwhat’sinarelease- Linemanager–Thelegalemployer,ensurescompetencedevelopmentandagood

workingenvironment.- Processmanager–Decidesonprocessesandadherencetothese- Analysts–Handleseverythingthathastodowithrequirements,writesSRS- Architect–Ensuresthatrequirementsaremetandspecifiesahigh-levelarchitecture- Leaddesigner–Handlesprototypinganddesignissuesnotcoveredinarchitecture,

alsodesignstheUXanddialogueetc.- Environmentmanager–Createsandmaintainstheenvironmentsfordevelopment

andtesting- Developer–Developsthesystem

- Procurementresponsible–Buyscomponentsandlicenses- Componentadaptor–Adaptsexternalorreusedcomponentstothesystem- Integrator–Putsthepiecesofthesoftwaretogethertoasystem- Testers–Testsandevaluatesrequirements- Qualitycoordinator–Measuresqualityandorganizesreviews- Deploymentmanager–Ensuresthattheproductisinstalledandmadeavailable- Technicalwriter–Responsiblefordocumenting- Coursedeveloperandleader–Createsandpreformstrainingmaterialandcourses- Helpdesk–Helpswithanddocumentscustomerissues- Operationsmanager–Ensuresthatservicesareprovidedtothecustomer- Systemsengineer–Performsmaintenanceandmonitoringonactivesystems- Librarian–Managescomponentlibraryandidentifiesreusablecomponents- Documentresponsible–Decidesonstandardsanddatabasemodeling

ProcessesProcessesareawaytoreachthegoal,theyareanorderedsetofactivitieswhereeachactivityhasentryandexitcriteriaandsomeconstraints.V-modelTheV-modelisorderedbyabstractionandtime,whereweoftenstartandendinahighlevelofabstractionandimplementinthemiddle.

AnexampleoftheV-modelwherewehavealevelofabstractionontheY-axisandtimeontheX-axis

WaterfallIfweremovetheY-axis,thatistheabstractionlevel,fromtheV-modelwegettheclassicalwaterfallmodel.Thisisoneoftheoldestmodelsfordevelopmentandincludesastrictconstraintthateveryphaseistobecompletelyfinishedbeforemovingontothenext.

SEPTEMBER 17, 2015 6Processes/Kristian Sandahl

… also known as the V-model

Time

Maintenance

Acceptance Test(Release testing)

System Testing(Integration testing of modules)

Module Testing(Integration testing of units)

Unit testingImplementation

of Units (classes, procedures, functions)

Module Design(Program Design,Detailed Design)

System Design(Architecture,

High-level Design)

Requirements

Verify System Design

Validate Requirements, Verify Specification

Verify Implementation

Verify Module Design

Problemswiththewaterfallmodelincludeschangesduringtheprocessbeinghardtoimplementduetothestrictorderofphases.Alsofeedbackishardtoimplementandweneedtohaveareallygoodtimeestimateforthephasestofinishontime.Advantageswiththewaterfallmodelincludeitssimplicityandeasinesstounderstand.Canbeapplicabletoshortprojectsorstableprojectswheretherequirementsarenotexpectedtochangee.g.fixed-pricecontracts.Iterative“Iftherequirementschange,whydon’twedoitagain?”Roycesaidin1970andmarkedthebirthoftheiterativemodel.Inthismodelweutilizeeitherwaterfallorv-modelandapplyittoanumberofiterationswherewegetfeedbackintheendofeach.Herewefixthetwoprojectparametersoftimeandresourcesandrevisitfeaturesandqualitytoupdatethesetocurrentneeds.Wecanalsocallthemodelofaddingfeaturesindifferentiterationsanincrementalmodel,whereyoukeeponaddingtowhatyouhavetogetclosertothegoal.Problemswiththeiterativemodelincludetheproblemswithmappingrequirementstodifferentiterationsandprioritizingthefeatures,somemightbeforgotten.Advantagesismostlyabouttheflexibilityandthespreadoutworkloadofthemembers.Theteamcancontinuouslyimprovetheprocessandmisunderstandingsaremadeclearearly.Inanincrementalmodeltheprioritizationofrequirementsisimportant,acomparisonbetweencustomervalueanddevelopmenteffortisoftenusedasaguideline.

Exampleofachartwithcustomervalueanddevelopmenteffort.

SEPTEMBER 17, 2015 16Processes/Kristian Sandahl

Prioritization of requirements

Development Effort

Customer Value

HighLow

High

Low

Sweet Spot

Avoid

RUP-RationalUnifiedProcessRUPisaniterativesoftwaredevelopmentmethodologydefinedin1997.IthassomescaleddownversionsincludingOpenandUPwithagilecomponents.Itvisuallydescribestheworkloadofdifferentareasandhasfourmainphasesthatconsistsof:Inception–Requirementspecification,prototypingElaboration–Architecture,projectplanConstruction–DevelopmentandtestingTransition–Deliverytocustomer

AnexampleofavisualRUP-representation

AgiledevelopmentmethodologiesAgiledevelopmentincludesacoupleofvaluesthatincludesagilitytochangesintheplanningandhavingaworkingsoftwareratherthancomprehensivedocumentation.Italsoincludesagradeofcustomerparticipationratherthanhavingfixedcontracts.Anumberofmethodologiesfallundertheagileumbrella,suchas:eXtremeProgramming(XP)XPisamethodologythatdescribesindetailhowthesoftwareshouldbeimplemented,someofthemainelementsarepairprogramming,extensivecodereviews,testdrivendevelopmentandaflatorganizationwithfrequentcommunicationbetweenpersonnel.SomecriticsclaimthatXPistoounstableandlackoveralldesignanddocumentation.ScrumScrumdefinesamethodologywherecrossfunctionalteamsdevelopaproductinacoupleofiterations,alsocalledsprints.Itincludesacoupleofrolessuchasaproductownerandascrummaster.Thetypicalusageofscrumistofirstuseaproductbacklogtowriteuserstoriesandfromthesedefineanumberoftaskstospreadoutoverthesprintsinasprint

SEPTEMBER 17, 2015 21Processes/Kristian Sandahl

RUP – Disciplines and Phases

Business Modeling

Requirements

Analysis and Design

Implementation

Test

Deployment

Change & Config. Mgm.

Project Mgm.

Environment.

CoreTechnicalDisciplines

CoreSupportingDisciplines

Inception Elaboration Construction Transition

backlog.Alsofrequentscrummeetingsandanextensivereviewandretrospectiveattheendofallsprintstodefinelessonslearned.KanbanKanbanisavisualsystemderivingfromtheJapanesewordforbillboard(看板).Atthecentreofthemethodologyisabillboardwherefeedbackispostedforthemanagementandtakenintoconsiderationwhenimplementingchangesthroughouttheprocess.Oneofthemainprinciplesareleadershipatalllevels,makingeveryoneresponsibleforchangesintheprocess.LeanSoftwareDevelopmentAnadaptionoftheleanprinciplesforsoftwaredevelopment,oftenfavouredbystart-upcompaniestryingtopenetratethemarket.Someprinciplesaretoeliminatewaste,decideaslateaspossibleandtoempowertheteam.Wordlist:

• Task/Activity–Ataskthatistobefinishedintheprogressforthegoal,isrepresentedintheGANTT-chart.

• Phases–Agatheringoftasksintoaphasemakesoverallviewsoftheprojecteasier.Oftenendswithamilestoneoratollgate.

• Milestone–Apredefinedsub-goalduringtheprojectthatleadsonestepclosertothefinalgoal.E.g.analphaversionortestsfinished.ShouldbedefinedinSMART.

• Tollgate–Anexternaldecisionpointwhereastakeholderorothercanaborttheprojectorchoosetocontinue.E.g.afirstprototypeorinspection.

• Slacktime–Theamountofbuffertimebeforethetaskaffectsothertasksandtheoveralltimefortheproject.

• Realtime–Estimatedtimefortheactivity/project.• Availabletime–Slacktime+Realtime.• Statusreports–Asummaryofthecurrentstatus,whathashashappenedsincethe

lastreportandwhatshouldhappennext.Italsodetailscurrentproblemsandrisksandshouldbecompiledregularlythroughouttheproject.

• Brooks’law-"Addingmanpowertoalatesoftwareprojectmakesitlater"becauseofe.g.training

• Timebox–Afixedtimeperiodtoaplannedactivity,deliverablesatadeadline• Softwarelifecycle–Thelifecycleofthesoftware,fromspecificationto

implementationtotestingtomaintenance.• Productbacklog–Arequirementlistforascrumteam.• Productowner–Thepersonresponsiblefortheproductbackloginthescrumteam.• Scrummaster–Chairmanofthescrummeetingsandresponsibleforplanning

sprints.

DesignandArchitectureThedesignandarchitectureofasystemisadescriptionofhowthesystemis/willbeimplemented.Anumberofwaystodothisisdiscussedbelow.Thedesignprocessstartswithdecomposingthesystemintomodulesthroughcommunicationbetweenstakeholders.Animportantconceptinsystemdesignisreusability,tobeabletoreusecomponentsinmultiplemodules.Box-and-linediagramPrototypingofthesystemoftenstartswithdrawingmodulesinabox-and-linediagram,shortlydescribingthemodulesandtherelationsbetweenthese.

Asimplebox-and-linediagramofasystem.

ViewsAfterthebox-and-linediagramanumberofarchitecturalviewsareoftencomposed,thesedescribethesysteminmoredetailandisoftendrawnupusingUML.Thethreeviewsdescribedinthiscourseare:

- Implementationview,showspackages,componentsandartifacts.- Executionview,showscomponents,connectorsandsub-systems.- Deploymentview,showsthephysicalmachines.

UMLUnifiedModelingLanguageisamodeling-languageinsoftwareengineeringthatvisualizesthedesignofasystem.Itcontainsofanumberofspecifieddiagrams,shownbelow,andinthiscoursewespecifyanumberofthem.

11

Box-and-line diagrams...

Logging

Identification &Authentication

UserDatabase

Encryption / Decryption

Packet Handler

SessionHandler

Module, Subsystem, Element, Entity, Component... (many names)

Interface

Relationship, shows data and/or control flow

ThehierarchyofdiagramsinUML2.0.

StructurediagramsClassdiagramAclassdiagramisoneofthemostcommonUMLdiagrams,itshowsclassesofasystemwithit’sinternalattributesandoperations.Classesarealsotiedtogetherwithassociations.

Aclasswithattributesandoperations(functions).

Therelationshipsbetweenclasses.Foramoredetaileddescriptionseelecture6.

5

+getNoOfOrders():Integer+getOrderStatus():String+ addEmail(email:String)

name: String[1]email: String [0..2]

Customer

A Single Class Class name

attributes

operations

visibility+ public- private# protected~ package

Multiplicity1 exactly one0..1 Zero or one* Zero or more

(same as 0..*)2..8 Between 2 and 8

Return typeParameter

Relationships - overview and intuition

25

Association(with navigability)

BA "A" has a reference(s) to instance(s) of "B". Alternative: attributes

AggregationBA

BA Composition

Avoid it to avoid misunderstandings

An instance of "B" is part of an instance of "A", where the former is not allowed to be shared.

BA1) "A" inherits all properties and operations of "B".2) An instance of "A" can be used where a

instance of "B" is expected. Generalization

BA Realization "A" provides an implementation of the interface specified by "B".

"A" is dependent on "B" if changes in the definition of "B" causes changes of "A".BA Dependency

DeploymentdiagramConsistsofartifactsthatutilizescomponentsandrelationshipsbetweenthesethroughcommunicationpathstocreateaoverviewofthesystem.

AcomponentdiagramconsistingofartifactsthatutilizethecomponentsShoppingCartandOrders.

Asystemwithserverandaclientwithcryptographyartifacts.

Acoupleofcentralconceptsofdesigningthedeploymentviewis:

- Coupling,dependencybetweenmodules–wewantlowcouplingdueto:o Replaceabilityo Enablechangestosinglemoduleswithoutaffectingthesystemo Testabilityandisolatingerrorso Understandability

- Cohesion,relationsbetweeninternalpartsofthemodule–wewanthighcohesiono Easiertounderstando Easiertomaintaino Everypartdoeswhatitissupposedto,withlowcohesiontheyhavenothingin

commonandaresupposedtobeinseparatemodules

Deployment view in UML

18

<<artifact>>clientCrypto.jar

<<artifact>>serverCrypto.jar

<<use>>

<<protocol>>TCP/IP

Node, physical hardware

Communication path

<<client>> <<server>>

PackagediagramShowsthepackagestosupportthesystem.Togetaviewofwhatdoweneedtodesignandwhatalreadyexistsandalsotoknowwherethingsareforfutureusage.

BehaviourdiagramsUsecasediagramThesehavebeencoveredinthepreviouschapteraboutrequirements.ActivitydiagramsRepresentanactivityfromstarttoend,likeabrainstormingprocessshownbelow.Theshapesofanactivitydiagramare:

• roundedrectanglesrepresentactions.• diamondsrepresentdecisions.• barsrepresentthestart(split)orend(join)ofconcurrentactivities.• ablackcirclerepresentsthestart(initialstate)oftheworkflow.• anencircledblackcirclerepresentstheend(finalstate).

Anactivitydiagramofabrainstormingprocess.

StateMachinediagramsQuitesimilartotheactivitydiagrambutrepresentscurrentstatesandactionsbetweenthese.Ahollowcirclerepresentstheend,ifany.

Statemachinediagramofacoinhandlerinavendingmachine.Noticenohollowcircle,thereforenoend.

SequencediagramAsequencediagramisaninteractiondiagramthatshowstheoperationofprocesseswithoneanotherovertime.Blocksrepresentthetimelineoftheobjectsspecifiedatthetop.

Asequencediagramforacoffeemachine,withthecustomerasanexternalactor.

State machine diagram

checking idleinsertCoin()/checkCoin(self)

For class CoinHandler:

state trigger event, causing transition

action, reaction to the event

start state marker

this objecttransiton

falseCoin()/returnCoin(self)

7

Sequence diagram with several objects

: CoffeeCustomer

: Interface : CoinHandler : Brewer

insertCoin transport

{ 0 < 5s}

litIndicatorscoinAccepted warmUp

pressButton(b1)makeOrder(o1)

pourCoffeepourCoffee

Timing constraint

Return message

13

Fragmentsofasequencediagramcanbegroupedtoenableloops.

Orconditionalbranches.

DesignpatternsAdesignpatternisastandardsolutiontoasystemdesigntoenablereuseofinformationandcomponents.Anumberofpatternsarecommonuse,ine.g.thethreebelow.StrategyIfyou’regoingtoimplementanobjectthathasabehaviorthatdependsonanumberofconditionals.E.g.asuperclassofanimalsandsubclassesthatcaneitherflyornot,youcanmakeaninterfacethatisFlysthatimplementsIsFlyingorCantFly.Thenyousettheindividualanimaltoeitheratruntime.

Combining fragments of sequence diagrams

:Order :TicketDB :Account

SD processOrder

create

Get existing customer dataref

loop

[get next item]reserve(date,no)

add(seats)

answer destruction

loop condition

loopgate

14

More fragments of sequence diagrams

:Order :TicketDB

loop[get next item]

reserve(date,no)

add(seats)alternate branches

reject

alt [available]

[unavailable]

nested conditional

guard condition

17

AStrategypatternwithanimalsthatcaneitherflyornot.flyingTypeissettoeitheratruntime.

ObserverIsapatternbetweenasubjectandoneormoreobserversthatneedanupdateeverytimesomethingchangesinthesubject.Thinkofitasasubscriptiontoastockmarket(subject)andobservers(investors)thatgetsnotifiedwheneverthepricechanges.

Theobserverpatternwithinterfacesforthesubjectandobserver.Thesubjectsavesobserversinanarray.

FaçadeAunifiedinterfacetoasubsystemtomakeiteasiertouse,thisistoprotectthecontentsofthesubsystemandmakeitabletochangepartsofitwithouthavingtochangetheentiresystem.

Asystemwithoutfaçade,thesubsystemiswithinthesquareandexternalpartsareconnectedwhereneeded.

Example: Facade

Thesamesystemwithafaçadeapplied,toenablechangesinthesubsystemwithoutaffectingexternalparts

ArchitectureStylesAnumberofarchitecturestylesalsoexistsandshouldbetakenintoconsideration,thesearemorerelatedtothearchitectureofasystemratherthanthedesignpatternsdescribedabove.Client-serverDescribesdecisionsofhowmuchcodeandworkloadshouldbedistributedbetweentheclientandtheserver.

Threecommonstructuresofclient-serverarchitecture,two-tierwithfatorthinclientandthethree-tierstructure.

Example: Facade

Facade

32

1. Client-Server

Presentation layer

BusinessLayer

Client

Server

Datamanagement

Two-Tier, Fat-client

Presentation layer

BusinessLayer

Client

Server

Datamanagement

Two-Tier, Thin-client

Presentation layer

Client

Middle-ware

BusinessLayer

Server

Datamanagement

Three-Tier

- Heavy load on server- Significant network traffic

+ Distribute workload on clients- System management problem, update software on clients + Map each layer on separate hardware

+ Possibility for load-balancing

LayeredAlayeredarchitecturehasaclearstructurebetweenhigh-leveltolow-levelinterfaceswherecommunicationisonlybetweendirectlylinkedlayers.Somebridgingcanbeaccepted.

Alayeredarchitecture.

Pros:- Easyreuseoflayers- Supportstandardization- Dependenciesandmodificationsarekeptlocal- Supportsincrementaldeveloping

Cons:- Couldgiveperformancepenalties- Layerbridgingoverridesmodularity

Pipe-and-filterConsistsofdecomposingcomplexprocessesintofiltersthatperformaprocessandthensendsthedataforwardthoughpipes.ThinkofthisasthestagesinapipelineCPU-architecture.

Anexampleofapipe-and-filterarchitecture.

SOA-Service-orientedarchitectureConsistsofdecomposingthesystemintocomponentsthatprovideservicesforothercomponentsviacommunicationprotocols.Hereweviewthesystemnotasacollectionofhardwareorsoftwarebutasacollectionofservices.Thisiscommononmostmodernweb-platforms,aprimeexamplebeingAmazonthatspreadouttheirservicesonpartnercompaniestoenableeasyscalingoftheirsystem.

33

2. Layers

layer 3

layer 2

layer 1

layer 3layer 1

layer 3

HighestAbstraction

DefinedInterfaces

Client

IP

Ethernet

Application

Transport

Network

Data link

SSL

HTTP

Server

TCP/UDPTCP/UDP

IP

Ethernet

SSL

HTTP In a “pure” layered model, only the immediate below layer can be accessed

Layer bridging – can access lower than the closest one

Documentationofdesign- Systemoverview,abriefdescriptionstating

o Whotheusersareo Themainrequirementsandconstraintsincludingqualityfactorso Anyimportantbackgroundinformationo A“mental”modelofthesystem

- Structuralviews,giveanoverviewanddescribeeachelementandallrelations.o Implementationviewo Executionviewo Deploymentview

- Mappingbetweenviews,describehowtheviewsrelatestoincreaseunderstanding.- Behaviourviews,todescribebehaviorforelementsbye.g.texts,sequencediagrams

orstatemachines.- Rationale,amotivationtowhythedesignisasitisandwhatwouldhappenifyou

changeit.Wordlist:

• Module–Adecomposed,atomicpartofthesystem.• Prototyping–Aniterativeprocessofdecomposingthesystemintomodules.• Artifact–Physicalcode,afileoralibraryinacomponentdiagram.• Component–Theartifactimplementsacomponent.Liketheartifact

“clientcrypto.jar”implementsthecomponentEncryption.

TestingandSCMTestingAfterwebuiltthesystemweneedtotestit,twocentralconceptsare:Validation:Arewebuildingtherightsystem?Verification:Arewebuildingthesystemright?Testingisaboutmakingsurethatwegetthecorrectoutputfromthedifferentmodulesandthatwegettheresultthatweexpectedfromthesystem.Thesystemisexecuted,theresultsareobservedandanevaluationismade.Eitherthedevelopersdothetesting,theyhaveaunderstandingofthesystembuttheriskisthattheywouldtesttoogentlywithfearofnothavingdeliverablesattheendoftheproject.Or,independenttesterscanlearnaboutthesystem,theywilltryhardtobreakthesystemandisdrivenbyquality.BlackboxtestingFunctionaltesting,giventheinput,thesoftwareshallprovidethecorrectoutput.Establishconfidenceforthecompletesystem,butthesystemcanstillcontaininternalbugs.Includesthreetypesoftesting:

- Exhaustivetesting–Testingwithallpossibleinputvariablestotheprogram- Equivalenceclasstesting–Testingallequivalentsetsofdata,withequivalent

meaningthatitistreatedthesamebythesystem.E.g.iftheruleisthatifyouare18yearsorolderyoucanborrowmax100,000,butnolessthan10,000.Theequivalentclassesare:

o EC1:age<18o EC2:age>=18o EC3:sum<10,000o EC4:10,000<=sum<=100,000o EC5:sum>100,000

- Boundaryvaluetesting–Focusesontheboundariesbetweenequivalentclasses.Sowetestonepointontheboundary,onelowerandonehigher.

WhiteboxtestingSeeksfaultwithinthesystem,tryingtofindinputsandoutputssothatacertainoperationinsidethemoduleisexecuted.Seeksoutbugsactively.

UnittestingTestsbeingrunwhendevelopingsinglecomponents,beforeacceptingthemintothesystem.

Unittestsarebeingrunonsinglecomponents,whileintegrationtestingtakesplacebeforeintegrationintomodules..

IntegrationtestingAretestsrunwhenintegratingsinglecomponentsintointegratedmodules.Havefourmainstrategies:

Eachletterrepresentsacomponent;thecompletetreeistheintegratedmodule.

Big-bangIntegratesallcomponentsinonebig-bang,thereafterteststhecompletemodule.Providesdifficultytoisolatedefectsfoundandhadapossibilitytomisscriticaldefects,butisquick.Bottom-upTestsfromthebottomup,i.e.(E,F,B)&(D,G,H)istestedbeforeintegrating.Pretendcomponentscalleddriversareusedtomimic(A)andtestthesesub-systemsindividually.Disadvantagesisthatwecancatchverybiginterfacedefectslateandwerequiregooddriversfortesting.Advantagesincludeeasyuseofincrementaldevelopment.

43

Com

pone

nt c

ode

Com

pone

nt c

ode

Tested components

Tested components

Unittest

Unittest

Integrationtest

Design Specification

Integrated modules

Top-downTestsfromthetopdown,i.e.(A,B,C,D)aretestedbeforeintegratingwith(E,F)&(G,H).Hereweusepretendcomponentscalledastubtomimictheoutputoflowerlevelsubsystems.Stubsareeasiertowritethandriversandwecandiscovergeneraldesigndefectsearlybutwerequiremanystubsandthebasicfunctionalityofthemoduleistestedlate.SandwichAcombinationofbottom-upandtop-downtestingwherewetest(A,B,C,D),(E,F,B)&(G,H,D)inparallel.Isgoodifyouhaveabigsystemwithmanylayersbutrequiremoreresourcesanddoesn’ttesttheindividualsubsystemsthoroughly.SystemtestingBeforeintegratingthemodulesintothecompletesystem,weneedacoupleoftestsbeforeit’sacceptedandinuse.

Thefourstagesofsystemtesting.

FunctiontestTestsfunctionalrequirements.Testingonefunctionatatime,usefultohaveanindependenttestteamwhoknowstheexpectedactionsandoutput.PerformancetestTestsnon-functionalrequirements.Consistsofanumberoftestsbasedontherequirements,e.g.timingtests,volumetests,securitytests,maintenancetestsandusabilitytests.Oftenrunbygatheringstatisticaldata.AcceptancetestTestthattheusersorcustomersneedsarefulfilled.Consistsof:

- Benchmarktests–Speciallydesignedtestcases- Pilottests–Ineverydaywork

o Alphatest–Atdeveloper’ssite,inacontrolledenvironmento Betatest–Atoneormorecustomersites

- Paralleltests–Testingthenewsysteminparallelwiththepreviousone.

InstallationtestThoroughtestingatthecustomerssite,ifthebetatesthasbeensuccessfullyrunatthecustomerssitethistestmightnotbeneeded.Typicalfaultsinthesystem:

- Algorithmic–Divisionbyzero- Computation&Precision–Wrongorderofoperations- Documentation–Documentationdoesn’tmatchcode- Stress/Overload–Datasize(dimensionsoftables,sizeofbuffers)- Capacity/Boundary–xdevices,yparalleltasks,zinterrupts- Timing/Coordination–Real-timesystems- Throughout/Performance–Speeddoesn’tmatchrequirements- Recovery–Powerfailure- Hardware&SystemSoftware–Externalconnections- Standards&Procedure–Doesn’tmeetorganizationalstandard-difficultfor

programmerstofolloweachother.TerminationproblemHowdoyouknowwhentostoptesting?Itisinfluencedby:

- Deadlines- Testcaseswithadecidedpercentagepassed- Testbudgetdepleted- Coverageofcode

Fullpathcoveragehasbeenreachedwhenallpossiblepathsthoughasystemhasbeenexecuted.SoftwareConfigurationManagement(SCM)Whendevelopingalargesizesoftware,youneedtohavesomesortofsystemtokeeptrackofchangesthroughouttheprocess.Ifonedevelopermakesachangeandanotherdevelopermakesanotherchangeweneedsomesortofsystemtomergethesetogether.ThisiswhereSCMisutilized.ContinuousintegrationThepracticeofcontinuousintegrationmeansthatyouintegratechangesfrequently(mostoftendaily),importantpracticesare:

- Automatedbuildingofthesystem- Automatedtestingofthesystem- TheuseofSCMsystemsforintegratingcode

RevisioncontrolRevisioncontrolsystemsarecentralinSCM,wehaveaunifiedrepositorywithatrunkandanumberofindependentbranches.Ifyoumakealocalchangeyoumergethiswithaunifiedbranchandthencommitsthechangestothetrunk.

Theversionsofarevisioncontrolsystem,withthemaintrunkandtwobranches.

Centralized(SVN)Subversion(SVN)isacommoncentralizedrevisioncontrolsystemwherethecoderepositoryiscentralizedonaserver.Youthendownloadalocalworkingcopy,makeyourchanges,andmerges,solvinganyconflictsbeforeyoucommitanduploadyourchangestotherepository.Allchangesarekeptcentrallyontheserverandthelocalversionisjustacopyofthecurrentworkingversion.Distributed(Git)Gitishoweveradistributedrevisioncontrolsystemwheretherepositoryislocallyonyourowncomputerandthecentralizedworkingversionisthecurrentone.Hereyoukeepalltheversionslocallyandcancommittoitseveraltimesbeforepushing(uploading)tothecentralserver.Wordlist:

• Error–Whenpeoplemakemistakeswhilecoding.• Fault–Adefectthatistheresultofanerror.Faultsofcommissionoccurswhenwe

entersomethingcorrectintoanincorrectrepresentationwhilefaultsofomissionarewhenwefailtoentercorrectinformation.

• Failure(anomaly)–afailureoccurswhenafaultexecutes,i.e.onlyonfaultsofcommission.

• Oracle–Theonewhodecideswhatisapassedtest,caneitherbeanexperthumanoranautomatedsystem.E.g.“Valuesbetween0.99and1.01isacceptedoutputs”.

• Regressiontesting–Thepracticeoftestingthecompletesystemwhenanewcomponenthasbeenintegrated.

• Smoketesting–Testonlythemostcriticalpartsofasystemquickly.• Jenkins–Atoolforautomatedtesting.

• Trunk–Themainworkingcodethatisbeingdevelopedinarevisioncontrolsystem.• Branch–Asmallerpartbeingbranchedoutfromthetrunktoimplemente.g.a

functionoracomponentbeforeintegratingintothemaintrunk.• Merge–Theprocessofintegratingcodeintoabranchorthemaintrunkfromyour

localrepository.• Commit–Uploadinglocalchangestothecentralrevisioncontrolsystem.

QualityFactorsAnumberofmeasurablesoftwarequalityfactorsexist;theseare:

• Correctness• Reliability• Efficiency• Usability• Integrity• Maintainability• Flexibility• Testability• Security

• Portability• Reusability• Interoperability• Survivability• Safety• Manageability• Supportability• Replaceability• Functionality

Softwarereviews-InspectionSoftwareinspectionisimplementedthroughouttheprocesstofinddefectsandimprovetheprocessitself.Itisasystematicpeerexaminationandnottesting.EverythingfromtheSRStodesign,sourcecode,processdescriptionsandinstallationprocedurescanandshouldbeinspectedtoensurequality.Participants(Roles)ofaninspection,shouldbe2-6persons:

- Leader(moderator)-planningandorganizingtheprocessofinspection.- Recorder-documentstheinspectionsdefects,resultsandrecommendations.Canbe

thesamepersonasleader.- Reader-informsthesoftwareproductandhighlightsimportantaspects.- Author-performsreworktomeetcriteria.Shallnotbeleader,recorderorreader.- Inspector-identifiesanddescribesdefects,canbeassignedspecifictopics.All

participantsareinspectors.Processofaninspection:

- Input–responsible:Authoro Objectivestatemento Softwareproductsorartifactstobeinspectedo Inspectionprocedureso Reportingformso Knowndefectso Sourcedocuments–SRS,descriptions,documentation

- Planandoverview–responsible:Leadero Identifyingtheteamandassigningresponsibilitieso Schedulemeetingso Distributematerialo Specifyscopeandprioritieso Introducetheproduct(Author)

- Individualchecking–responsible:Inspectorso Examtheproductindividuallyandreportalldefectstoleader

§ 2–3pagesperhouror100-200linesofcodestandardrate- Inspectionmeeting–Leader,Recorder,ReaderandInspector

o Inspect,produceadefectlisto Reviewlistandmakeanexitdecision:

§ Acceptwithnofurtherverification§ Acceptwithreworkverification§ Reinspect–redotheprocess

- Editandfollow-upo Authorresolvesitemso Inspectionleaderverifiesthatallitemsareclosed

- Collecteddatao Generalinspectiondatao Classification–e.g.logicproblem,sensorproblemo Categories–e.g.missing,extra,incorrecto Ranking–e.g.catastrophic,marginal,negligible

Othersoftwarereviews:

- Managementreviews–Checkdeviationsfromplans,performedbymanagement.- Technicalreviews–Evaluateconformancetospecificationsandstandards,

performedbytechnicalleadershipwithahighvolumeofmaterials.- Walk-though–AninformalatmospherewheretheAuthorpresents,leadsand

controlsthediscussion.- Audit–Externalevaluationofconformancetospecificationandstandards.

SoftwaremetricsThepracticeofsoftwaremetricsistomeasurethepreviouslymentionedqualityfactors.Wedothisviametrics,i.e.combinationsofmeasurements;measurementscanconsistof:

- No.ofpagesinadocument- No.ofelementsinadesign- No.oflinesofcode- Iterationlengthoftheprocess- Avg.no.ofhourstolearnasystemtodecidequality

MeasurementsonQualityFactorsWeoftencalculatereliabilitywithMeanTimeToFailure(MTTF).Reliability=MTTF/(1+MTTF)(Estimatedprobability)OrFailureintensity=(1-R)/t(Morestraight-forwardmeasurement)Similarpatternsare:Availability=MTTF/(MTTF+MTTR)whereMTTR=MeanTimeToRepairMaintainability=1/(1+MTTR)

CyclomaticcomplexityTheCyclomaticcomplexityV(G)ofaflowgraphGiscalculated:V(G)=E-N-2P,where:

- E=Num.ofedges- N=Num.ofnodes- P=Num.ofdisconnectedpartsinthegraph

Acontrol-flowgraphwithcyclomaticcomplexityV(G)=9-8-2*1=3.Thiscanrepresente.g.twoif-statements.

Anumberofspecificmetricsalsoexist:

- Usagebasedmetrics-Exampleo Description:Numberofgoodandbadfeaturesrecalledbyusers.o Obtaindata:Setupatestscenario.Lettestusersrunthescenario.Collect

numberofgoodandbadfeaturesinaquestionnaireafterwards.o Calculatethemetric:Taketheaverageofnumberofgoodandbadfeatures.o Relevantqualityfactor:Relevance–manygoodandfewbadfeatures

indicatesagoodmatchwiththeusers’mind-set.- Verificationandvalidationmetrics–Example

o Description:Rateofseveredefectsfoundininspectionofdesigndescription.o Obtaindata:Performaninspectionaccordingtoyourprocess.Makesurethat

severityisintheclassificationscheme.o Calculatethemetric:Dividethenumberofdefectsclassifiedwithhighest

severitywithtotalnumberofdefectsintheInspectionrecord.o Relevantqualityfactor:Safety–ahighproportionofseveredefectsindesign

indicatesfundamentalproblemswiththesolutionand/orcompetence.- Volumemetrics–Example

o Description:Numberonnon-commentedlinesofcode.o Obtaindata:Countnon-commentedlinesofthecodewithatool.o Calculatethemetric:Seeabove.o Relevantqualityfactor:Reliability–itisoftenhardtounderstandalarge

portionofcode;thefaultdensityisoftenhigherforlargemodules.- Structuralmetrics–Example

o Description:Maximumdepthofinheritancetree.o Obtaindata:Countthedepthoftheinheritancetreeforallclasses.o Calculatethemetric:Takethemaximumvalueoftheclasses.o Relevantqualityfactor:Understandability–Itishardtodeterminehowa

changeinahigherclasswillaffectinherited/overriddenmethods.

Control-flow

11

E = 9N= 8P= 1

Basic block

V = 3

B = 2

- Effortmetrics–Exampleo Description:Timespentintesting.o Obtaindata:Makesurethattestingactivitiesaredistinguishedintime

reportingforms.Makesurethatallprojectactivitiesarereported.o Calculatethemetric:Sumthenumberofhoursforallactivitiesintestingfor

allpeopleinvolved.o Relevantqualityfactor:Testability–acomparablylongtestingtimeindicates

lowtestability.SoftwareQualityAssurance(SQA)Qualitycanbothbesomethingintheeyesofthebeholder,somethingwelearntorecognizeorvalue-basedonthemarketwhereweoftencanmeasureitobjectively.Anumberoflevelsofqualityassuranceexists:

- Appraisal–Detection- Assurance–Prediction- Control–Adjusting- Improvement–Reducevariation,increaseprecision

UsabilityengineeringThroughouttheiterativeprocessweincreasethematurationandknowledgeoftheprojectgroupandthereforedecreasetherisk,thisisdonebyevaluatinggoalsof:

- Relevance- Effiency- Attitude- Learnability

MatureorganizationAmatureorganizationhasahigherlevelofworkaccomplishedandwelldefinedroleswheretheydothingswell,notnecessarilygood.CapabilityMaturityModelIntegration(CMMI)CMMIisusedtodecidethelevelofmaturationofanorganization,themodelhavefivestages,eachwithanumberofprocessareastofocuson.

1. Initial–Over-commited,norepetitionofsuccess.2. Repeatable–Processadherenceisevaluatedandwecanrepeataprevioussuccess.3. Defined–Tailoredfromownstandards,improvedprocesseswithdetailed

descriptions.Originallytheminimumlevel.4. Managed–Frequentmeasuresandstatisticsiskeptforgoals,productsand

processes.Haveahighpredictivecapability.5. Optimising–Everyonecommittedtocontinuousimprovementandaninnovative

climateispairedwithevaluationofnewtechnology.Performancegapsareknown.

ExampleprocessareasofCMMI:RequirementsManagement(REQM)–Level2(Requirements)Purpose:Managerequirementsoftheproject’sproductsandproductcomponentsandtoensurealignmentbetweenthoserequirementsandtheproject’splansandworkproducts.RequirementsDevelopment(RD)–Level3(Requirements)Purpose:Elicit,analyze,andestablishcustomer,product,andproductcomponentrequirements.TechnicalSolution(TS)–Level3(Design)Purpose:Selectdesignandimplementsolutionstorequirements.Solutions,designs,andimplementationsencompassproducts,productcomponents,andproductrelatedlifecycleprocesseseithersinglyorincombinationasappropriate.ProjectPlanning(PP)–Level2(ProjectManagement)Purpose:Establishandmaintainplansthatdefineprojectactivities.RiskManagement(RSKM)–Level3(ProjectManagement)Purpose:Identifypotentialproblemsbeforetheyoccursothatriskhandlingactivitiescanbeplannedandinvokedasneededacrossthelifeoftheproductorprojecttomitigateadverseimpactsonachievingobjectives.ProcessandProductQualityAssurance(PPQA)–Level3(SQA)Purpose:Providestaffandmanagementwithobjectiveinsightintoprocessesandassociatedworkproducts.OrganizationalProcessDefinition(OPD)–Level3(Process)Purpose:Establishandmaintainausablesetoforganizationalprocessassets,workenvironmentstandards,andrulesandguidelinesforteams.ConfigurationManagement(CM)–Level2(Process)Purpose:Establishandmaintaintheintegrityofworkproductsusingconfigurationidentification,configurationcontrol,configurationstatusaccounting,andconfigurationaudits.Verification(VER)–Level3(Testing)Purpose:Establishandmaintaintheintegrityofworkproductsusingconfigurationidentification,configurationcontrol,configurationstatusaccounting,andconfigurationaudits.Validation(VAL)–Level3(Testing)Purpose:Demonstratethataproductorproductcomponentfulfillsitsintendedusewhenplacedinitsintendedenvironment.

ISO9000-3IsaguidelinefromtheInternationalOrganizationforStandardizationwhichisbuiltontheprinciplesof:

- Customerfocus- Leadership- Involvementofpeople- Processapproach- Systemapproachtomanagement- Continualimprovement- Factualapproachtodecision-making- Mutuallybeneficialsupplierrelationships

TotalQualityManagement(TQM)isasetofmanagementpracticesthroughouttheorganization,gearedtoensuretheorganizationconsistentlymeetsorexceedscustomerrequirements.TQMplacesstrongfocusonprocessmeasurementandcontrolsasmeansofcontinuousimprovement.Has7mainprinciples:1.Qualitycanandmustbemanaged2.Processes,notpeople,aretheproblem3.Don’ttreatsymptoms,lookforthecure4.Everyemployeeisresponsibleforquality5.Qualitymustbemeasurable6.Qualityimprovementsmustbecontinuous7.Qualityisalong-terminvestmentSoftwaresecurity

CIA–Confidentiality,AvailabilityandIntegrityiscentralforsoftwaresecurity.

23

Security

CIA

Confidentiality • Only authorized users can read the information• E.g. Military

Integrity

• Only authorized users can modify, edit or delete data.

• E.g. bank systems

Availability

• Right information is available at the right time• Important for everyone