《《软件工程》Soft_Eng.ppt》由会员分享，可在线阅读，更多相关《《软件工程》Soft_Eng.ppt（120页珍藏版）》请在金锄头文库上搜索。
1、Computer Science 3061/23/03Bill BondClass CommunicationEmail your name and email address to bondwumr.eduClass Time: 6:30 - 9:10 PMWeb page is at following location: http:/web.umr.edu/umreec/web-courses/cs306/index.htmlMythical Man MonthWritten by Frederick Brooks in 1975Describes development of OS/3
2、60 in the 1960sConcentrates on people issues / organization instead of technologyProject ManagementHow do we manage a project?PeopleResourcesTasksWhat are software metrics?How are they useful?Project Management, contHow can we estimate a project?EffortDurationCostWhen should we make (versus buy) sof
3、tware?Project Management, contHow do we manage risks?How is a schedule created?Where are we?How do we assure quality software?MeasurementsDirectProcess cost, effortProduct LOC, execution speed, memory size, defectsIndirectProduct functionality, quality, complexityEstimatesProductivity KLOC/person-mo
4、nthQuality defects/KLOCCost - $/KLOCDocumentation pages/KLOCKLOCEasy to measureLanguage dependentPenalize well-designed programEstimatesProductivity FP/person-monthQuality defects/FPCost - $/FPDocumentation pages/FPFunction PointLanguage independentBased on subjective dataNo direct meaningFunction P
5、ointOriginal purpose was to measure business information systems“Feature point” system for system/engineering softwareAccommodates high “algorithmic complexity”Algorithms added to tableLOC/FPAverage LOC to build one FPAssembly300Cobol100Fortran100Pascal90Ada70Object-oriented30EstimationDecomposition
6、Empirical modelingAutomated toolsEstimationMust understand scope requirementsMust decompose to the “right” piecesIf right pieces, easy to estimateMust leverage historical dataMust be similar to past experienceComputer Science 3061/30/03Bill BondClass CommunicationEmail your name and email address to
7、 bondwumr.eduClass Time: 6:30 - 9:10 PMWeb page is at following location: http:/web.umr.edu/umreec/web-courses/cs306/index.htmlProject ManagementWhat are software metrics?How are they useful? How can we estimate a project?EffortDurationCostCOCOMOConstructive Cost Model - empirical modelMultiple mode
8、ls - increasing detailsBasicallyResource = c1 * (estimated characteristic)c2ParametersResourceEffortDurationStaff sizeEstimated CharacteristicLOCFPBasic COCOMOEffortE = a * (KLOC) b (person-months)TimeD = c * (E) d (months)ProjectsOrganic - small, simple project; team has good experience; less than
9、rigid requirementsSemi-detached - intermediate project, mixed team experience, rigid/less than rigid requirementsEmbedded - tight constraintsParameters abcdOrganic2.41.05 2.50.38Semi-detached3.01.12 2.50.35Embedded3.61.20 2.50.32Project SchedulingSchedule often more important than the costModular so
10、ftware - parallel developmentCritical path - tasks that must be completed on schedule if the project as a whole is to be completed on scheduleSchedulePictorial representation of project allows calculation of boundary times (start/finish of task , if slippage will cause delays, surplus time)Critical
11、path in boldMake /Buy DecisionOff-the-shelf used as-isOff-the-shelf modifiedCustom built by outside contractorProcessDevelop function and performance specificationEstimate internal development cost and delivery dateSelect 3 or 4 candidate packagesDevelop comparison matrixDecisionWill delivery date b
12、e sooner than internally developedWill cost of acquisition/customization be lessWill cost of support be lessComputer Science 3062/6/03Bill BondProject ManagementWhen should we make (versus buy) software?How do we manage risks?How is a schedule created?Where are we?How do we assure quality software?S
13、ystem EngineeringComputer-based system - A set or arrangement of elements that are organized to accomplish some method, procedure or control by processing informationGoalDefine system elementsBound system by identifying function and performance“What” is requiredAssign tasksAllocate to hardware, soft
14、wareMultiple allocations possible - different hardware/software mixSystem ArchitectureCan model system as “information transform”Input, Processing, OutputImportant to identify “System” boundaryWhat is system responsibility?Architecture Flow DiagramsAllocate elements toUser interfaceInputSystem funct
15、ion and controlOutputMaintenance and self-testCan support a hierarchy of detailAbstractionRequirements/AnalysisDeveloper and customer have active roleRequirements/Analysis effortProblem recognition - documentationEvaluation and synthesisModelingSpecificationReviewFocus on “what” not “how”Requirement
16、s AnalysisInputSystem specification (if exists)Software project plan (verify dont violate assumptions)OutputSoftware requirementsValidation criteria for software (requirements testable?)Preliminary users manual (possibly)Requirements AnalysisIssues(Mis) CommunicationInclude appropriate groupsSize of
17、 problem (omissions)First Law - “No matter where you are in the system life cycle, the system will change, and the desire to change will persist throughout the life cycle”Requirements AnalysisBottom LineNeed to do reasonable job of identifying requirements early in the cycle“Requirements are hard”Pr
18、ototypingMay help requirement processEspecially user interfaceDevelop initial requirementsPrototype systemModify existing systemPaper screensUser “test drives” and makes suggestionsProject SuggestionsTry FAST processPaper prototype of screensPreliminary user manualRequirements to AnalysisRequirement
19、s process results act as input to Analysis processBoundary can be unclearAnalysis process may provide feedback to Requirements process (iterate)Analysis Fundamental PrinciplesThe information domain of a problem must be represented and understoodModels that depict system information, function, and be
20、havior should be developedThe models (and the problem) must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashionThe results should be peer reviewedResult - model of system to be built - “what it does”Views of informationInformation flow - manner in which information
21、 (data) changesInformation content - individual data items that compose larger informationInformation structure - internal organization of data itemsPartitioningReduce complexityVertical - hierarchy (increasing detail)Horizontal - functional decompositionRepresentationSupports layers of detailNotati
22、on straightforward and consistentShould be easy to reviseComputer representation?Analysis Models DifferBased on Analysis methodWill examineData FlowObject OrientedDetails nextComputer Science 3062/13/03Bill BondData FlowThree componentsInformation flow model - graphicalData dictionaryProcessing narr
23、atives - PSPECApplicationInitial - “Data processing” systemsExtensions - real-time, controlKey ConceptsInformation is transformed as it flows through systemFocus on data flow - not sequence of processing (not a flow chart)Inputs/Outputs remain the same at different detail levelsGuidelinesThe level 0
24、 data flow diagram should depict the system as a single bubblePrimary input/output should be carefully notedLabel everythingInformation flow continuity must be maintainedOne bubble at a time is refinedRefine until bubbles perform a “single function” - maps to single program componentBeginningSystem
25、description started from “grammatical parse” - identify nouns and verbs in system narrativeVerbs - processes - bubbleNounsExternal entity - boxData or control item - arrowData store - double lineTo Complete ModelData represented by ArrowsData dictionaryProcess bubble descriptionProcessing narrative
26、- PSPECControlTwo approachesAdd to Data Flow DiagramConstruct “parallel” Control Flow DiagramCSPECDesignBill Bond4/3/03DesignThe process of applying various techniques and principles for the purpose of defining a device, a process or a system in sufficient detail to permit its physical realizationQu
27、ality software is goal - tolerate changesRepeatable method driven by analysisStructured DesignData structuresProgram structuresProcedural detailObject-Oriented DesignClassesObject interactionMethod detailControl HierarchyFan-out - one controls manyFan-in - many use oneCohesion / CouplingCohesion - h
28、ow related are components of a moduleCohesive module does “one thing”Want cohesive modulesCoupling - interdependence / interaction between modulesWant low couplingStructured ProgrammingSingle entry/exitConstructsSequenceConditionif - then - elseselect - caseRepetitiondo - whilerepeat - untilPDL Char
29、acteristicsFixed syntax of keywords that provide structured constructs, data declaration, and modularityFree syntax to describe processingData declaration facilitiesSubprogram definition and callingData Flow Design ProcessType of information flow is establishedFlow boundaries are indicatedDFD is map
30、ped into program structureControl hierarchy is defined by factoringResultant structure refinedFlow TypesTransformTransactionFirst-Level FactoringTop - decision makingMiddle - control / workLow - input /computation / ouputExplosionCommon ProcessImplosionReduce Control ComplexityDesign HeuristicsReduc
31、e coupling / improve cohesion through implosion / explosionMinimize fan-out - try to fan-in as depth increasesKeep scope of effect within scope of controlscope of effect - modules affected by decisionscope of control - modules subordinateDesign HeuristicsReduce interface complexity“Black box” - Info
32、rmation hidingSingle entry / exitDesign OptimizationSelect efficient algorithmsInstrument codeSmall amount of code - significant timeRe-evaluate if necessaryObject-Oriented DesignBill Bond4/10/03System ArchitectureSolution typically consists of more than just “our” classesThree-tier architecturePres
33、entation - windows, reportsApplication logicStorageApplication LogicDomain objects - represent domain conceptsServicesService objectsDatabaseCommunicationsEtcMotivationManage complexity ReuseSubdivide construction tasks among teamsDistribution to multiple processorsUML PackageGroup of elements or su
34、bsystemsLogical divisionMay be nestedPackagesGroup elements that provide a common service with relatively high coupling and collaboration, into a packageAt some level of abstraction the package will be viewed as highly cohesive - it has strongly related responsibilitiesIn contrast, the coupling and
35、collaboration between elements of different packages will be relatively lowDependenciesDashed lines indicate dependency (knowledge)Want to limit dependency between packagesDomain not dependent on PresentationPartitioningLayers - vertical tiersPartitions - horizontal division of parallel subsystems o
36、f a layerFaade PatternContext/ProblemA common, unified interface to a disparate set of interfaces - such as to a subsystem - is required. What to do?SolutionDefine a single class that unifies the interface and give it responsibility for collaborating with the subsystem.Faades Model-View Separation P
37、atternContext/ProblemIt is desirable to de-couple domain (model) objects from windows (views), to support increased reuse of domain objects, and minimize the impact of changes in the interface upon domain objects. What to do?Model-View Separation PatternSolutionDefine the domain (model) classes so t
38、hat they do not have direct coupling or visibility to the window (view) classes, and so that application data and functionality is maintained in domain classes, not window classes.Software Testing TechniquesBill Bond4/17/03OverviewThis week - examine detailed testing techniques (technology)Next week
39、 - discuss strategies that can be used to apply techniques (framework)ObjectivesTesting - executing a program with the intent of finding an errorGood test case - high probability of finding an as-yet undiscovered errorSuccessful test - uncovers an as-yet undiscovered errorA destructive processTwo wa
40、ysWhite box - Knowing internal working, verify operation of all the pieces, all the paths, early stages of testing Black box - Knowing function desired, verify that function is fully operational, late stages of testingLimitationsTesting can not prove the absence of defects only that software defects
41、 are presentIt is impossible to exercise “all” combinationsEven small programs would take yearsWhite Box TestingDerive test cases toExercise all independent paths in module all least onceExercise all logical decisions on true and false sidesExecute loops on boundaries and within operational boundsEx
42、ercise internal data structuresBlack Box TestingFocus on functionality and interfaceIncorrect, missing functionsInterface errorsErrors in data structures / external DB accessPerformance errorsInitialization / termination errorsBasis Path TestingDetermine complexityTest each execution path (execute e
43、very statement once)Flow graphNodes - one or more procedural statementsArcs - (edges) - flow of control (flow chart arrows)Edges must terminate at node (even if null)GraphsSequenceIfWhileUntilCaseMore DefinitionsRegion - Area bounded by edges and nodes (area outside “all” regions is also counted as
44、a region)Predicate node - node that contains a conditionSpecial CaseSeparate node created for each condition in “if a or b then x else y”abxxyCyclomatic ComplexityProvides a quantitative measure of logical complexityDefines number of independent paths in basis set (upper bound on number of tests)Ind
45、ependent path - introduces a new set of processing statements or new condition (moves along a new edge)Basis set - set of independent paths: all statements executed, all conditions testedCyclomatic ComplexityV(G) = number of regionsV(G) = edges - nodes + 2V(G) = predicate nodes + 1Deriving Test Case
46、sUse design or code - draw flow graphDetermine cyclometric complexityDetermine basis set of pathsPrepare test cases to force execution of each pathHow Many Test Cases?How Many Test Cases?Equivalence PartitioningDivide input domain into classes of dataSelect test that represents class of dataUncover
47、a class of errorsValid / Invalid statesRangeSpecific valueSetBooleanBoundary Value AnalysisErrors occur at class boundariesConcentrate on boundariesRange (a, b) - a, b, above, belowSet - min, max, above, belowExercise data structures at boundary - example array of 100 elementsSoftware Testing Strate
48、giesBill Bond4/24/03IntroductionDiscussed techniquesNow discuss strategies for applying techniquesApproachBegin testing at modules and work toward integrated systemDifferent testing techniques appropriate at different pointsTesting conducted by developer and other groupsDebugging must be accommodate
49、dQuestionsVerification - Are we building the product right?Validation - Are we building the right product?Overall ApproachUnit testing (module)Integration testingValidation testingSystem testingWhite / Black boxBlack boxBlack box - requirementsBlack box - performanceWhen Is Testing Complete?Never -
50、Customer performsWhen out of time and moneyUse statistical techniques to predict current statusStatistical ApproachCumulativeErrorsTimeUnit TestIndependent pathsInterfaceEquivalence classBoundary valueLocal data structureError - handlingMay require construction of drivers /stubsOverheadIntegration T
51、estConstruct program structureConduct tests to uncover interface errorsValidate functionalityValidation TestCompare requirements to system operationSystem TestRecovery from failure / restartSecurity testingStress testingPerformance testing - real-timeDelivery TestAlpha - customer with developer supp
52、ortBeta - at customer siteObject-Oriented Unit TestUnit test applied to “classes”Traditional unit test techniques applyIndependent pathsInterfaceEquivalence classBoundary valueLocal data structureError - handlingMay require construction of drivers /stubsClass BehaviorState independentMethod behavior
53、 not dependent on class stateState dependentMethod behavior dependent on class stateObject-Oriented Integration TestIntegrate necessary classes to support testMultiple classes (class cluster)Drivers / stubsTest as systemSource of test cases (specific to OOA/OOD)Use casesSequence diagrams - describe class interaction given system input
