CSE 4904 Guidelines for Milestone ReportsSeptember 3, 2008This handout provides general guidelines for preparing the preliminary reports at different milestones ofyour CSE 4904 project1. Comments on your reports will be communicated while meeting coordinators ofeach milestone.1 Reports on Project Specs and PlansThis section suggests possible items to discuss in the first two milestone reports. Note that the projectrequirements/specifications and team members should be finalized while preparing the second milestonereport. Listed below are the suggested items to discuss.1. Introduction1.1 Background and motivation1.2 Document conventions1.3 Team members and task breakdown1.4 References2. Overall Description2.1 Product functions & perspective2.2 User classes and characteristics2.3 Developing environment2.4 User environment2.5 Design/implementation constraints2.6 Assumptions and dependencies3. External Interface Requirements3.1 User interfaces3.2 Hardware interfaces3.3 Software interfaces3.4 Communication protocols and interfaces4. System Features4.1 Description and priority4.2 Action plan4.3 Functional requirements1Template partially adopted from gantthead.com, techwr-l.com and microtoolsinc.com5. Other Nonfunctional Requirements5.1 Performance requirements5.2 Security requirements5.3 Software quality attributes5.4 Project documentation5.5 User documentation5.6 Other RequirementsAppendix A: Terminology/Glossary/Definitions listAppendix B: Others2 Implementation and Test PlansGenerally there are two phases of test plan creation. The first should be done at the time the system isdefined. The second should be created in parallel to the spec development.The first part of the Software Test Plan falls under the more conventional definition of software test plansand includes:1. Definition and Objectives of the Phases of TestingWhat are the objectives of Module Testing?What are the objectives of Integration Testing?Will there be Systems/Acceptance Testing? If so, what are the objectives?Will there be Beta Testing? If so, what are the objectives?2. SchedulesWhen will Part 2 of the Test Plan be written for each Phase?When will each of the Phases be scheduled?What are the dependencies of each Phase?How long will each Phase last?3. ResponsibilitiesFor each phase, the people who will design, write, execute, and verify test cases as well as the peoplewho correct the problems should be identified.4. Target & Test Equipment RequiredAll of the target and test equipment required for testing should be identified.The goal of Part 2 of the test plan is to define exactly what should be tested, based on the softwarespecifications. Here are the general guidelines to follow in creating this important phase.1. Create a Test Document the Way You Create the Spec ReportTake every requirement from the specs and create one or more test cases from that document. Providea check box beside each test case. This allows the Test Plan to easily become a Test Report. Createstress testing scenarios that step outside of the specs and look at the system as a whole. For example,if the system has TCP/IP Ethernet connection on it, perform certain tests with large amounts of databeing sent to the system. Or, if the system has a keyboard as input, perform testing with the keyboardbeing pounded with both valid and invalid data. Provide off-design test scenarios outside of the specsthat test the system in conditions for which the specs provide no definition. Showing that the softwaredoes what it’s supposed to do is only half the battle. The other half is determining if the software isdoing what it is not supposed to do.22. Test Case GenerationThe following are some general guidelines for creating test cases:• Every test case should define expected results as a result of the defined inputs.• Every requirement should be tested at and beyond its boundary conditions (for example: highand low limits) as well as mid points.• Mix black box2and white (or glass) box3testing.This means that some test cases are written without knowing what is inside the box (black boxtesting). Other testing should include testing based on knowing what is inside. For example, ifyou know that an algorithm for generating 10,000 different outputs is done with a formula, youwill not need to test all 10,000 outputs. However if you know that it is done with a table withsome break points in the table where different algorithms are used at each break point, you willwant to include this in your testing.3. Who should execute the Test Plan?It is essential to have a different person execute the test plan from those who created the softwarecomponents. Find individuals who like to break things! Develop a creative tension between teammembers who test each other’s software.3 Integration Plans1. Introduction• Revision HistoryRecord all revisions to the document.• Purpose and ScopeState the purpose and scope of the document.• List of Reference DocumentsList all reference documents. You might want to also include documentation on tools and testequipment, integration station, etc.2. Integration Strategy• Entry CriteriaSpecify the criteria that must be met before integration of specific elements may begin (e.g.,functions must have been unit tested).• Elements to be IntegratedIdentify all the elements to be integrated by subsystem into which they will be integrated.• Integration StrategyDescribe the integration approach (top-down, bottom-up, functional groupings, etc.) and therationale for the choosing that approach.• Sequence of Feature/Function and Software IntegrationIdentify the sequence in which the software code functions and modules will be integrated.Relate this sequence to any product features/functions being built up. Specify any hardware2http://en.wikipedia.org/wiki/Black box testing3http://en.wikipedia.org/wiki/White box testing3dependencies for early software integration activities. In addition, identify the order in whichsubsystems will be integrated.• Individual Steps and Test DescriptionFor each step of the integration process identified above, describe the type of tests used to verifythat the elements integrated in this step perform as expected. Describe in general the expectedresults of the test set.At the lower levels, these tests will focus on direct testing of interfaces between software func-tions and modules, between software functions or modules and specific electronics, etc. As moreof the system is put together, tests will