说明讲稿ni培训lesson requirements gathering

1、Lesson 2 Requirements GatheringIntroductionProject ManagementGathering and Managing RequirementsTime EstimationStyle and Coding StandardsDeveloping a Project PlanA. IntroductionSelect and utilize tools for managing the project Identify project requirementsEstimate the time and cost required to compl

2、ete the projectEstablish style and coding guidelines to be used during project developmentStyle GuidelinesRequirements GatheringDesignDevelopmentValidationDeploymentDeliverablesRequirements documentStyle checklistProject planB. Project ManagementProject management typically involves:Identifying requ

3、irements for the projectManaging scope, time, and costEstablishing standards to guarantee qualityProject Management The application of knowledge, tools, and processes to bring about the successful completion of specific project goals and objectives.Project Management ToolsUsually not specific to sof

4、tware developmentUseful for managing any type of project.Typical FeaturesSchedulingResource ManagementSchedulingCoordination of tasks and events based on dependenciesScheduling personnelHandling uncertainty in time estimatesArranging tasks to meet deadlinesIdentify the critical path for the projectC

5、ritical Path A sequence of tasks that depend upon one another with durations that directly determine the duration of the project.Resource ManagementTask lists for individuals working on the projectIdentification of risks related to each resourceHistorical information comparing planned and actual per

6、formance for past projectsResource Management Identification and management of an organizations resources, including financial resources, inventory, employees, production resources, or information technology.Project Management CASE Tools CASE ToolFreeWeb-basedCollaborative SoftwareIssue Tracking Sys

7、temProject Portfolio ManagementResource ManagementGanttProjectXXTracXXXXeGroupWareXXXXXXMicrosoft ProjectXFogBugzXXXXC. Gathering and Managing RequirementsProvide a mechanism to understand what the application should doFunctional requirementsNon-functional requirementsConstraints on the implementati

8、onRequirements Statements that define the needs and objectives of the software projectDefining RequirementsThe process of defining requirements includes the following items, not necessarily in this order:IdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementIdentification U

9、se the following steps to identify the software requirements:Determine software purposeElicit requirements from stakeholdersDetermine system requirementsDetermine user interface requirementsIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementDetermine Software PurposeWhat

10、 is the context of the project?What is the purpose of the software you want to create?Why create the software?What conditions must the software satisfy?IdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementElicit Requirements From StakeholdersInterviewsMeetings/brainstorm s

11、essionsQuestionnairesObserve the environment where the software will be usedIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementSample Customer Specifications DocumentOpen and review the sample specifications document for the TLC project, located at: Managing Software Eng

12、ineering in LabVIEWDemonstrationsTLC Specifications Document.docxDetermine System RequirementsStakeholders are most familiar with the system requirementsSystem requirements clearly describe the technical environmentOperating systemCPU powerSystem memoryPeripheralsDrivers and APIsIdentificationConstr

13、aintsAnalysisRepresentationCommunicationValidationManagementDetermine User Interface Requirements Define how users interact with the softwareAnalyze the tasks the user performsIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementConstraintsLimits within which the system mu

14、st operateIdentify constraintsSoftware must operate within the constraintsTypical constraintsCostHardware interface characteristicsReliabilitySafetyIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementAnalysisCompile requirements that are determined to be adequate by the s

15、takeholdersIdentify issues with the requirementsClassify requirementsDetermine risksIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementRepresentation Create a written form of the requirementsUse a specification such as IEEE-830Create a prototype that demonstrates the imp

16、lementation of the requirementsIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementRepresentation (continued)Keywords help define the degree of necessity of the requirementsIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementKeywordMeaningShall

17、Essential requirementShouldConditional requirementCanOptional requirementCommunicationAllow all stakeholders to review the requirementsOften leads to a modification of the requirementsResult of communication must be agreementIdentificationConstraintsAnalysisRepresentationCommunicationValidationManag

18、ementValidationVerifies that requirements are robustUnderstood by all, including the developersDo not illustrate implementationTestableTraceableIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementManagementActivities that manage and track the requirementsEvaluate change r

19、equests throughout the development cycleRequirements often change or are added as the project progressesVerify and track requirementsUse a software requirements management applicationIdentificationConstraintsAnalysisRepresentationCommunicationValidationManagementRequirements TrackingA project can ha

20、ve hundreds or thousands of requirementsEach requirement must be implemented and testedTrace implementation to a specific section or sections of codeTrace testing to a defined testing procedure and/or test resultsRequirements Tracking (continued)Log and maintain links between the requirements docume

21、nt, source code, and test systemsEnd result is a traceability matrix or other reportStructured requirements tracking is often a non-functional requirement of a projectRequirements tracking can be performed in one of two waysManually, using a spreadsheet or other data entry toolAutomatically, using r

22、equirements management toolsRequirements Management ToolsRequirements management tools should be considered when:The number of requirements es large enough that manual tracking es tediousMultiple documents are used to outline different sets of requirementsProject requirements are being met in more t

23、han one applicationNI Requirements Gateway is an example of a requirements traceability toolRequirements Management Tool A tool that aids in requirements gathering and trackingNI Requirements GatewayLinks development and verification documents with formal requirementsManaging Requirements Using Micr

24、osoft WordDefine styles in Microsoft Word to indicate different information about the requirementsRequirement IDs use the Requirement_ID styleRequirement text uses the Requirement_Text styleAnalyzing Requirements with Coverage AnalysisUpstream CoverageDisplays one level of covering requirement refer

25、ence materialsDownstream CoverageDisplays one level of covered requirementsExercise 2-1: Requirements GatewayExamine a requirements document and perform a traceability analysis of a LabVIEW application.Exercise 2-1: Requirements GatewayRequirements Gateway is best-suited for complex projects with ma

26、ny requirements that are covered in multiple files. What are some other methods that could be used to track coverage of project requirements for smaller projects?D. Time EstimationReasons for Missed DeadlinesTime Estimation TechniquesMapping Estimates to SchedulesQualityTimeScopeCostReasons for Miss

27、ed DeadlinesThe goal of planning is to estimate the size of the project and then fit the project to the scheduleReasons for missed deadlinesPoor planning plete idea of project goalsFeature creepPersonnel issuesSoftware Projects Often Exceed Original EstimatesPeople are usually optimisticObjectives,

28、implementation issues, and quality requirements are misunderstoodEstimates do not account for daily tasksTime Estimation TechniquesSize-Based MetricsEstimation of the amount of code needed to complete projectTime estimation based on size estimationEffort-Based EstimationProject is broken into compon

29、entsTime estimation is based upon estimations for each componentSize-Based MetricsDependent on previous work Information is easy to gatherFor LabVIEW codeBased on the number of nodesEach node corresponds to a block diagram objectFor text-based codeBased on Source Lines of Code (SLOC) measurementsMea

30、suring Nodes in LabVIEWHistorical MeasurementsHistorical measurements can be for estimating future project development effortsBuild a base of knowledge about current and previous projectsDocument amount of time it took to develop each node or line of code for existing software productsProcedure for

31、EstimationDivide the project into tasksEstimate number of required nodes for each taskProduce a total estimate of nodes and time required for developmentExercise 2-2: Size-Based Metrics in LabVIEWUse VI Metrics to determine the number of nodes in a project comparable in difficulty to a project that

32、will be developed.Exercise 2-2: Size-Based Metrics in LabVIEWWhat information should be logged along with the results of VI Metrics in order to build a useful catalog of historical data for future size estimation?Challenges of Size-Based MetricsDependent on the organizationDependent on the programmi

33、ng languageNot all code is created with the same level of qualityNot all code is equal in complexityRelies on maintaining productivity statistics for each team memberEffort-Based EstimationStart by dividing project into tasksEach task should take no longer than a week to completeEstimate the time to

34、 complete each taskAdd the results to calculate overall timeExamples:Weighted AveragePlanning PokerWideband Delphi EstimationWeighted AverageHow much time will each task most likely require?What is the worst-case estimate of time for the task?What is the best-case estimate of time for the task?Calcu

35、late the expected effort (E) using the following formula:E = Best Case + (4 x Most Likely) + Worst Case 6Planning PokerConsensus based method for estimating effort Uses a deck of cards with fixed estimates printed on them0, , 1, 2, 3, 5, 8, 13, 20, 40, 100Each estimator is given a deck of cardsDecid

36、e upon units of effort represented by the cardsPlanning Poker ProcedureTask owner gives a short overview of the task. Team asks questions and discuss to clarify assumptions and risksEach individual lays a card face-down, representing their estimateEveryone turns over their card simultaneouslyIndivid

37、uals with outlier estimates explain their estimatesRepeat estimation process until consensus is reached.Wideband Delphi EstimationInvolves multiple stakeholdersUses the knowledge and experience of the group to arrive at a consensus estimateReduces bias in the data and influence of any individual Gat

38、her StakeholdersKickoff meetingIndividual stakeholders estimate timeReconvene stakeholders for estimation sessionAchieve convergenceStep 1 Gather StakeholdersGather a team that has a stake in the success of the projectProvide the scope of the project to the stakeholdersProcess ensures trust because

39、all stakeholders are involved in the project planGather StakeholdersKickoff meetingIndividual stakeholders estimate timeReconvene stakeholders for estimation sessionAchieve convergenceStep 2 Kickoff MeetingPrerequisite: complete project requirementsMeet with all stakeholdersBreak down tasks into a l

40、ist consisting of the major tasksAvoid discussing time estimates during this early sessionGather StakeholdersKickoff meetingIndividual stakeholders estimate timeReconvene stakeholders for estimation sessionAchieve convergenceStep 3 Individual Stakeholders Estimate TimeSeparately estimate the time fo

41、r each taskList any assumptions made in forming estimatesDetermine a unit of estimation, such as 8 hour, uninterrupted work daysGather StakeholdersKickoff meetingIndividual stakeholders estimate timeReconvene stakeholders for estimation sessionAchieve convergenceStep 4 Reconvene Stakeholders for Est

42、imation SessionGraph individual estimates as a range of values8 Hour Days102030405060708090100120130140150160170Gather StakeholdersKickoff meetingIndividual stakeholders estimate timeReconvene stakeholders for estimation sessionAchieve convergenceStep 5 Achieve Convergence Stakeholders report any as

43、sumptions made in determining estimatesStakeholders reexamine and adjust the estimates as a groupGather StakeholdersKickoff meetingIndividual stakeholders estimate timeReconvene stakeholders for estimation sessionAchieve convergenceStep 5 Achieve Convergence (continued)8 Hour Days1020304050607080901

44、00120130140150160170Cycle 1Cycle 2Cycle 3Exercise 2-3: Wideband Delphi EstimationUse Wideband Delphi estimation to estimate a project.Exercise 2-3: Wideband Delphi EstimationWhat are some advantages of effort-based estimation over size-based estimation?Who should NOT be involved as a stakeholder in

45、the Wideband Delphi estimation process?Mapping Estimates to SchedulesMapping the estimate fits the development into an actual work calendarConsider meetings and other events that occur during development timeDevelop a schedule that includes all responsibilitiesTies into project management toolsGantt

46、 ChartShows the start and finish dates of each activity associated with a project.Each activity consists of individual tasks with their own start and end datesShows relationships between activities.Gantt Chart A type of bar chart that represents a project scheduleGantt ChartE. Style and Coding Stand

47、ardsInconsistent approaches to development and to creating user interfaces can be a problem with multiple developersEstablish an initial set of guidelines for your development teamVerify that each member of the development team follows the guidelinesCode reviewsUse the LabVIEW Style Checklist for me

48、ndationsStyle and Coding StandardsEstablish standards for:Disk and project hierarchiesFront panel designBlock diagram designDisk and Project HierarchiesOrganize VIs in your project and on your disk so you can easily transfer VIs to other computers and other platformsNaming conventionsCreating a proj

49、ect hierarchyFile organizationNaming ConventionsBe careful how VIs are named with a teamCreate a naming convention before the project begins Consider a unique prefix for each VI nameTop-level VIs (Capitalize prefix)SML Main.vi, SVT Main.vi, OAT Main.viSubVIs (Lowercase prefix and use underscores)sml

50、_test.vi, svt_process.vi, oat_frequency_calculate.viFile OrganizationDesign a directory hierarchy that uses separate folders forModulesShared custom controls Shared subVIsSupport files (e.g. documentation)Plug-in VIsUse project libraries to resolve cross-linking and for restricting access to SubVIs

51、or sub-librariesMaintain 1-to-1 correspondence between the disk and project hierarchyFront Panel Design ChecklistVerify that the key is assigned to an intuitive buttonVerify tabbing orderUse System colors for front panel objects when possibleText uses standard, consistent fontApplication, System, or

52、 DialogDialog boxes that commit settings have OK, Cancel, and Help buttonsDialog boxes that display information have Cancel and Help buttonsAny text on your front panel should have extra space for localization and font changesBlock Diagram Style ChecklistLabels have been created for Call Library Fun

53、ction Nodes, Code Interface Nodes, and algorithmsVerify that data flows from left to rightVerify that objects do not overlapVerify that wires do not run behind objectsMinimize use of sequence structuresMinimize nesting of structuresUse of local and global variables appropriatelyF. Developing a Proje

54、ct PlanShould be developed with all stages of the software engineering process in mindWho uses the project plan?ArchitectProgrammersStakeholdersProject Plan A document used to define a project and communicate that definition to the project stakeholdersManaging Customer ExpectationsThe expectations o

55、f the customer and the programmer are differentIt is your responsibility to determine what expectations the customer has and how to relate to him or herThe project plan provides a common ground from which you and the customer workIt should be written in a language that you both understandFramework o

56、f a Project PlanList of required meetings for the projectProject summaryDetailed project descriptionDevelopment plan impact and milestonesProject specifications and requirementsQuality planRisk AnalysisProduct distributionSupport and maintenance planSoftware Project PlanOpen and review a sample software project plan.Summary QuizWhich of