UNIT-V RISK, QUALITY MANAGEMENT & REENGINEERING - PowerPoint Presentation

1. UNIT-VRISK, QUALITY MANAGEMENT & REENGINEERINGByMr. T. M. Jaya Krishna M.Tech

2. Risk and Quality Management

3. Reactive Versus Proactive Risk StrategiesReactive risk strategy:Monitors project  likely risksResources r set aside  deal w themMore commonly s/w teamNothing about risks until something goes wrongProactive risk strategy:begins long before technical work - - initiatedPotential risks r identifiedProbability & impact assessedRanked by importanceEstablishes plan  managing risks

4. Software RisksRisk always involves in 2 characteristics:UncertaintyLossWn? Risks r analyzed it - - imp*  quantifyLevel = uncertaintyDegree = loss associated w each riskTo accomplish this diff. categories = risks r considered:Project risksTechnical risksBusiness risks

5. Software RisksSimple risk categorization always workRisk categories – Charette:Known risksPredictable risksUnpredictable risks

6. Risk Mitigation, Monitoring, & ManagementAll risk analysis activitiessingle goalAssist project teamDeveloping strategy  dealing w riskEffective strategy must consider 3 issues:Risk avoidance (best strategy)s/w team adopts proactive approachAchieved – developing plan  risk mitigationRisk monitoringRisk management & contingency planning

7. Risk Mitigation, Monitoring, & ManagementAll risk analysis activitiessingle goalAssist project teamDeveloping strategy  dealing w riskEffective strategy must consider 3 issues:Risk avoidance (best strategy)s/w team adopts proactive approachAchieved – developing plan  risk mitigationRisk monitoringRisk management & contingency planning

8. Risk Mitigation, Monitoring, & ManagementRMM steps incur additional project costExample:Spending time  backup every critical technologist costs moneyPart = risk management - -Evaluate wn? Benefits accrued by RMM steps r outweighed – costs associated w implementing themIn essencePerform a classic cost-benefit analysis

9. RMMM PlanRisk management strategy+ed in s/w project plan(or)Organized in  separate RMMM planRMMM plan documentsAll workPerformed part = risk analysis & - - used – project managerSome s/w teams develop formal RMMM documentRisk - - documented individuallyusing RIS (figure)

10. Software QualityDef:An effective s/w process applied in a mannerCreates a useful productProvides measurable value who produce it & use itEmphasizes 3 imp* points:An effective s/w process establishes infrastructureSupports any effort – building high quality s/w productA useful productDelivers the content, functions, & featuresEnd user desiresBy adding value  both producer & user = s/w productHigh quality s/w provides benefits  organization & end user

11. SuggestsQualityconsidered – taking a multidimensional viewpoint8 dimensions = qualityDeveloped  s/w but applied wn? s/w quality - - considered: Performance qualityFeature qualityReliabilityConformanceDurabilityServiceabilityAestheticsPerceptionSoftware QualityGarvin’s Quality Dimensions

12. Software QualityFactorsMcCall’s Quality Factors:CorrectnessReliabilityEfficiencyIntegrityUsabilityMaintainabilityFlexibilityTestabilityPortabilityReusabilityInteroperability

13. Software QualityFactorsISO 9126 Quality Factors:FunctionalityReliabilityUsabilityEfficiencyMaintainabilityPortability

14. Software QualityFactorsTargeted Quality Factors:IntuitivenessEfficiencyRobustnessRichness

15. Software QualityFactorsTargeted Quality Factors:IntuitivenessEfficiencyRobustnessRichness

16. Defect amplification ModelIllustrategeneration & detection = errorsDesign & code generation actions = s/w process (during)Model (figure below)

17. Defect amplification Model

18. Formal Technical ReviewsReview MeetingA quality control activity performeds/w engineers & othersFTR Objectives:Uncover errors – function, logic / implementation = s/ws/w meets its requirements (verify)ensure – s/w represented – predefined standardsMake projects manageableIn addition FTR servesTraining ground (junior engineers)Observe different approaches  s/w analysis, design & implementationPromote backup & continuity (reason)No. = people become familiar w parts = s/wFTRActually a class = reviews +des walkthroughs & inspectionsEach FTR - - conducted as meeting (Review Meeting)Successful only ifProperly planned, Controlled & Attended

19. FTR focusesSpecific part = overall s/w Example:↔ attempting  review entire designWalkthroughs r conducted  each component / small group = componentsWork productIndividual (producer) who developed work productInforms project leaderIt - - complete & review - - requiredcontacts Review leaderReview product & at the end = review all attendees = FTR decide whetherAccept productReject product – severe errorsAccept product provisionally (minor errors)Formal Technical ReviewsReview Meeting

20. reviewer records all issuessummarized at the end = review meetingreview issues list - - produced + FTR summary report - - completed & answers 3 questions:What was reviewed?Who reviewed it?What were the findings and conclusions?Summary report single page formbecomes part = project historical record may be distributed  project leader & other interested partiesreview issues list serves 2 purposes:identify problem areas w in productserve as an action item checklistguides the producer as corrections are madeFormal Technical ReviewsReview Reporting and Record Keeping

21. Review the product, producerAgenda (Set & maintain)Limit debate & rebuttal.Enunciate problem areas, attempt  solve every problem notedTake written notesFormal Technical ReviewsReview Guidelines

22. Limit the no. = participants & insist upon advance preparationDevelop checklist  each product i.e. likely  be reviewedAllocate resources & schedule time  FTR’sConduct meaningful training  all reviewersReview your early reviewsFormal Technical ReviewsReview Guidelines

23. Software Quality Assurance – Tasks, Goals & metricsSQA TasksAuthority = SQA group - -  assist s/w teamAchieve high quality end productS/W Engg. Institute recommendsSet = SQA actions that address:Quality assurance planningOversightRecord keepingAnalysis &ReportingActions above r performed – independent SQA group

24. Software Quality Assurance – Goals & metricsSQA actions r performedAchieve set = pragmatic goalsRequirements qualitySQA must ensure s/w team has properly reviewed the requirements modelachieve a high level = qualityDesign qualitySQA looks  attributes = design that r indicators = qualityCode qualitySQA isolate attributes that allow a reasonable analysis = quality = codeQuality control effectivenessSQA analyzes allocation = resources  reviews & testing assess whether they r being allocated in the most effective manner

25. Software Quality Assurance – Goals & metrics

26. Software Quality Assurance – Goals & metrics

27. Software ReliabilitySoftware reliability (def)probability = failure-free operation = computer prog. in a specified environment  specified timeprobability = success (theoretical def) Measures of Reliability and AvailabilityEarly work in s/w reliability attempted estimate mathematics = h/w reliability theory  prediction = s/w reliabilityHardware-related reliability models based on failure due  wear ↔ failure due  design defectsIn hardwarefailures due  physical wear Effects = temperature, corrosion, shock

28. Software ReliabilityMeasures of Reliability and AvailabilityEarly work in s/w reliability attempted estimate mathematics = h/w reliability theory  prediction = s/w reliabilityHardware-related reliability models based on failure due  wear ↔ failure due  design defectsIn hardwarefailures due  physical wear Effects = temperature, corrosion, shock

29. Software ReliabilitySoftware Safety:software quality assurance activity focuses on the identification & assessment = potential hazards affect s/w negatively & cause an entire system  failIf hazards c identified early in the s/w process S/W design features c specifiedeither eliminate or control potential hazardsModeling & analysis process - - conducted – part = s/w safetyOnce hazards r identified & analyzedsafety-related requirements c specified  s/wS/w reliability uses statistical analysis  determine likelihood that s/w failure will occur occurrence = failure does necessarily result in a hazard or mishapS/w safety examine the ways in which failures result in conditions lead  mishap

30. Reengineering

31. IntroductionMichael Hammer Foundation  revolution in management thinking about business processes & computing:Instead of embedding outdated processes in silicon & software, we shouldObliterate them & start over“reengineer” our businessesuse the power = modern information technology  radically redesign our business processes in order  achieve dramatic improvements in their performanceEvery company operates according to a great many unarticulated rulesReengineering strives  break away  old rules about h? we organize & conduct our businessSome companies [1990’s] effort  reengineer & results led  improved competitivenessToday, major companies have tens = thousands = computer prog.’s – support “old business rules”

32. Business Process ReengineeringFortune Magazine:BPR Def.:search  & implementation = radical change in business process  achieve breakthrough resultsBusiness Processes:Set = logically related tasks performedAchieve defined business outcomeW in thisPeople, equipment, material resources & business procedures r combinedProduce specified resultOverall business - - segmented in following manner:The business  business systems  business processes  business subprocesses

33. Business Process Reengineering – Model Business goals r identifiedProcesses that r critical  achieve goals defined in the business definition r identified.existing process - - thoroughly analyzed & measured.Based on information obtained during 1st 3 activities, use cases r prepared  each process i.e.  redesignedbusiness process m prototyped before it - - fully integrated in  businessBased on feedback  prototype business process - - refined & then instantiated

34. Software ReengineeringReengineeringTakes timeCosts significant amount = moneyAbsorbs resourcesAbove Reasons Accomplished in months | yearsReengineering = information system - - an activity Absorb information technology resources  many yearsEvery organizationNeeds pragmatic strategy  s/w reengineering (figure)

35. Software ReengineeringInventory analysis: Every s/w organization Inventory (spreadsheet model) = all applicationsDocument Restructuring:Weak document - - trademark = many legacy systems:Wh? You can do about it? Wh? r your options?Creating documentation - - far too time consumingDocumentation m updated, but your organization has limited resources

36. Software ReengineeringReverse engineering:Has it’s origin in h/w worldDisassembles competitive h/w productUnderstand competitors design & secretss/w - - quite similarProg.  reverse engineered - - competitorCompany’s own workSecret  understood r obscure

37. Software ReengineeringCode Structuring:Legacy systemsStable prog. ArchitectureButIndividual modules were codedMakes them difficult  understand, test & maintainCode w in suspect modules c restructured

38. Software ReengineeringData Structuring:Prog. W weak data architectureDifficult  adapt & enhanceForward Engineering:ApplicationsRebuilt using automated “reengineering engine”Old prog. W fed  engineAnalyzed, restructured & regenerated in a formExhibits best aspects = s/w quality

39. Reverse EngineeringReverse Engineering (RE)Extract design information  source code but following r highly variable:abstraction levelCompleteness = documentationDegree which tools & human analyst work togetherDirectionality = processRE process (figure)Before RE activities commenceDirty source code - - restructuredMakes code easier  read

40. Reverse EngineeringReverse Engineering (RE)  understand Data:RE = data occurs at different levels = abstraction (1st reengineering task)At prog. levelInternal prog. data structure – REedAt system levelGlobal data structures r reengineered  accommodate new database management paradigmsReverse Engineering (RE)  understand Processing:Begins w attempt  understand & then extract procedural abstractions represented – source codeReverse Engineering User Interfaces:Sophisticated GUI’sFashion  computer based products & systemsRedevelopment = UI’s - - most common types = reengineering activity

41. RestructuringS/w RestructuringModifies source code/dataMake it amenable  future changesmodify overall prog. architecturedesign details = individual modules & local data structures (focus)Code Restructuring:Performed  yield designProduces same function w higher quality than original prog.Data restructuring:Before it beginsAnalysis = source code s conducted (RE activity)Intent - -  extract data items & objectsGet info. on data flowUnderstand existing data structuresCalled Data analysisOnce completed data redesign commences

42. Forward EngineeringForward EngineeringApplies s/w engg. principles , concepts & methods  re-create existing applicationSimply create modern equivalent = an older prog. ↔ new user & technology requirements r integrated Redeveloped prog. extends capabilities = older applicationForward engineering  client-server architectures:Many mainframe appl.’s h reengineered  accommodate client-server architecturesTypical mainframe appl i.e. reengineered  client-server architecture – following features:Application functionality migrates  each client computerNew GUI implemented – client sitesDatabase functions r allocated  server

43. Forward EngineeringForward engineering  Object-oriented architectures:Reengineering conventional s/w  OO implementation uses many techniquesExisting s/w - - reverse engineered (data, functional & behavioral models c created)