CSC408S Software Engineering Winter 2000/2001 Comments and Solution Sketch for the CSC408S Mid Term Test In general - answers that addressed the specific issue/problems raised in the question received more marks than answers which presented some form of generic solution that didn't relate well to the specific issues in the question. - answers that regurgitated material from the lecture slides did much less well than answers that actually answered the question. 1. Over 50% part timers (PT) Effect on your project - PT less well focused on the project, will lose focus while working elsewhere. - PT harder to coordinate, may not be available when you need them - PT may be unavailable to answer questions/repair software they have written. - use of PT programmers will delay project completion. Before the Project [most answers didn't say enough about things that could be done before the project] - contact managers of the other projects your PT people work on. - understand their deadlines and crisis points so you can schedule around them. Try to establish a cooperative working relationship. You can help each other if you work together. - try to negotiate swaps to increase number of full time people on your project. e.g. two 1/2 time -> 1 full time, etc. - try to work out a schedule that lets you have PT people for longer periods of time. e.g. instead of 4/hrs a day, try for every other week or 2 weeks per month. - identify critical paths and assign them to full time people. During the project - encourage team development and/or assigning each PT person to work with some full time person. - Use design reviews to spread knowledge of the software widely within the development group. This make it easier for others to understand what PT programmers have done and for PT programmers to regain focus when they return from their other project. - monitor time spent by PT programmers, to make sure you are getting the share of their time that you should. - try to assign tasks to PT programmers that they can accomplish during one pass through your project - communication and documentation are particularly vital in this situation. Require that documentation be really current with respect to the software. Use forums (e.g. newsgroups) to encourage communication among developers. - monitor the quality of the work being done by the PT programmers (e.g. testing of their code). If a PT programmer consistently does poor quality work you are better off without them. - never let a PT person have sole responsibility for/knowledge of any part of the system that you really depend on. 2. Special Issues in Testing OO Software [most answers to this question were very incomplete] See Section 7.5 in Pfleeger for a good discussion of this issue. 3. Orthogonal Defect Classification [almost no one answered this question] This technique is described in Pfleeger pages 282-284 4. Items 2,5,6 on Boehm's List of Top Ten Risks [a good answer had to address both parts of the question, effect on a project and how to avoid/minimize the risk] 2 unrealistic schedules/budgets risks - non-completion of the project - increased stress on developers - higher likelihood of errors due to stress avoidance - use correct/good quality estimation techniques - don't attempt projects where budget/schedule is unreasonable. - schedule realistically (even pessimistically) 5 Gold Plating risks - extraneous, unwanted features will clog system poor performance, harder to test, delay completion distract from what should be done. avoidance - strict policy against Gold Plating - design/implement strictly to specification - monitor software to detect unauthorized GP - fire developers who ignore restrictions on GP 6 Continuing Stream of requirements changes risks - system never completed, must redo work due to changes budget/schedule continually disrupted developers confused about what they should be doing avoidance - try to get requirements right the first time - try to control when requirements changes occur (e.g. this will be in the NEXT release) - make client pay (heavily) for changes to try and discourage them - design development process so developers can ignore changes until they choose to accept them. 5. test toUpperCase function [a lot of answers proposed tests that were not very useful or were redundant. Most answers didn't test the conversion aspect nearly thoroughly enough. A lot of answers didn't specify the content of the test strings very well. For a complete test you have to specify the length AND the contents.] For all of the test strings described below - unless otherwise constrained, the character value should be in some random order, not some systematic order that might not detect ordering errors. ie. "AZMDJ..." instead of "ABCDE..." - the strings should have significant internal structure to test that toUpperCase can traverse a BigString correctly. [a lot of answers suggested using strings build using substring and concat. This is really testing substring not toUpperCase] My favorite way of generating a good test string is the random head and tail concatenation that was used to build T18 in Btest01.java - lengths of tests strings were choosen haphazardly so that both even and odd length strings were tested for each case. Test Conversion - strings of length 1001 and 5128 containing multiple copies of all lower case letters. [all should be converted to upper case] - strings of length 971 and 2520 containing multiple copies of all ASCII characters EXCEPT lower case letters. [output should equal input] - strings of length 128751 and 240480 containing multiple copies of all UNICODE characters. [only lower case letters should change] - strings of length 135971 and 302408 containing multiple copies of all UNICODE characters EXCEPT lower case letters. [output should equal input]. Boundary Tests - null input [should give null exception] - empty BigString [should return empty BigString] - a string of length one containing lower case letter/non-lower case letter/non-letter ASCII char. [a lot of answers obsessed about testing at/near maximum Length, this isn't well defined for BigStrings and is only (perhaps) interesting as a performance test. Any one test of an extremely long string is probably sufficient.] - one extremely long string containing all possible UNICODE characters [only lower case letters should change] [a lot of answers suggested the test below, but this is really in the same equivalence class as the conversion tests above.] - strings of length 3111 and 4222 with only lower case letter at the first character only lower case letter as the last character one lower case letter at some random position near the middle [ only the lower case letter should change] 6. Project Management Information required - existing project schedule/plan. Task breakdown and activities list - information on number and capabilites of personnel assigned to the project. - information on computer resources allocated to the project - periodic updates on progress of each team working on the project, frequency depends on overall duration of the project, but weekly or monthly is fairly common. Gather information - require progress reports from team leaders, testing and SQA group leaders Verify information [most answers were far too willing to assume that the information gathered would be honest and correct. Experience has shown the managers will lie to hide the fact that they are behind schedule.] You need to verify the information (discretely) from independent sources. - monitor logs of computer usage - monitor personnel hours from payroll system - monitor personnel working time from access security system. - monitor testing logs - monitor company web logs to see if developers are really spending their time surfing the web. - monitor CVS repository logs and activity - inter-team problems (e.g. teamGUI is still waiting for version 12 from teamLIBRARY ). - occasionally walk through the work place and see if the programmers are actually working or are they day-trading. 7 Upgrading Chief Programmer Teams [any non trivial reorganization received fairly good marks. Answers that just described CPTs with little change didn't do as well.] Librarian functions can be largely replaced by automated version control (e.g CVS), a configuration management tool and some simple shell scripts for doing compilation and testing. It might be desirable to add people with different skill sets to the team. - one or more technical writers to do the documentation. This is consistent with the original CPT concept of letting people do what they do best most of the time. - a system administrator/toolsmith. Keeps network and workstations up and running. Performs backups. Keeps software development tools working and upgrades them as appropriate. Perhaps share one person between several CPTs. 8. Development with low errors and minimum development time [This is a hard combination to deal with. Many answers did reasonable things to achieve good correctness. Very few said much that would be effective in minimizing time. In general other attributes of the software (e.g. budget) could be sacrificed to achieve these two goals.] Achieving absence of errors - Hire very skilled people to do requirements. Use enough people so you can do a very thorough job quickly. - Concentrate on getting core requirements absolutely right the first time. Try to defer/delete marginal requirements to simplify system - Try to develop requirements that are maximally independent so that it might be possible to specify and design them in parallel - Use requirements reviews to help improve correctness of the requirements - Hire lots of the best people to do the specification and design. - Use reviews/walkthroughs to keep the specification strictly linked to the requirements. - Try to maximize independence of the specification. - Use reviews/inspections to try and improve quality and reduce errors. - Hire lots of experienced, skilled designers to develop the design. - Try to design for high modularity, low coupling, high cohesion. - Try to make parts of the design separable so they can be implemented and tested concurrently. - Use design reviews improve quality of the design. - Use simple data structures and algorithms in the design. Time or memory performance is not a goal, correctness is. - design strictly to the specification. - KISS Achieving minimum development time - hire enough highly skilled developers, so that someone is available to work on anything that needs done. - try to "fast track" development so that some parts of the requirements can go through specification/design quickly and developers can start implementing part of the code as soon as possible. (e.g. requirements for some well understood part of the system could be pushed through so that implementing could start early.) - use concurrency as much as possible in these stages to try and get the job done faster by doing things in parallel (interacts with absence of errors so be careful). - if possible do software reuse using *very trusted* components.