CSDP: Sample Test Answers


1. c

Rationale: As stated in the CMM, V.1.1

Reference: IEEE-EIA Standard 12207.0-1996 The Life Cycle Model and Capability Maturity Model Integration, Version 1.1, (c) by Carnegie Mellon University, SEI.

2.
d

Rationale: Software components may or may not expose source code.
Reference: Szyperski, Clements, Component Software, Addison-Wesley, 1997 p.30


3. d

Rationale: The event list is used to build the first draft of the Data Flow Diagram of the system. This draft will turn into the complete Data Flow Diagram.
Reference: Yourdon, Edward, Modern Structured Analysis, PTR Prentice-Hall. 1988, Sections 19.1 & 19.2.


4.
d

Rationale: You never want to make a decision that is not a realistic simulation of how the system will have to perform.
Rationale-a: Not a bad thing, but normally blanket coverage is too inefficient, especially with very broad COTS, platform, and technology decisions. Focus needs to be on the use scenarios the system would encounter
Rationale-b: Of the items listed this is most important.
Rationale-c: Good idea, but even better when you select the depth areas to probe based on an analysis of what your system will need
Rationale-d: Talk about getting lost in the details!
Reference: Steve McConnell, Rapid Development, Microsoft Press, 1996


5. a

Rationale-a: Cleanroom SE tries to avoid the errors instead of spending time eliminating them
Rationale-b: Also a formal verification process is needed to check the existence of errors
Rationale-c: Cleanroom SE requires a well-defined engineering process, as the status of work in progress needs to be absolutely clear
Rationale-d: It is not necessary, one member might have two or more roles
Reference: Prowell, Stacy et al. Cleanroom Software Engineering: Technology and Process, Addison-Wesley, 1999, Pages 3-4


6. c

Rationale: With no reviews, high defect rate, and iterative lifecycle, things will only get worse as new code is written with the same injection rate, and new defects are injected fixing old ones, and existing code with undetected defects is built upon
Rationale-a: First sentence of case study indicates there shouldn't be major kinks to be worked out, so there is no reason to think given other factors that things will get better
Rationale-d: Maybe not precisely, but it can be predicted
Reference: McConnell, Steve, Code Complete, Microsoft Press, 1993 p 563-566, and McConnell, Steve, Rapid Development, Microsoft Press, 1996 p 69-73


7.
b

Rationale-a: A requirements error is cheaper to correct when detected during the requirements phase.
Rationale-b: Requirements errors are more expensive to correct as the development lifecycle advances. Typical estimations predict than Error-2 will be 10 to 20 times more expensive than Error-1
Rationale-c: Logical inference from rationale-a and rationale-b
Rationale-d: Several studies have proved the cost amplification effect when errors are detected late in the development lifecycle
Reference: Davis, A. Software Requirements: Objects, Functions and States. 3rd ed. PTR Prentice-Hall. 1993. Section 1.3.


8. a

Rationale: The question clearly specifies that the engineer's job is verify a mission critical application, thus the best route for the engineer is to stick to their responsibility of verifying the system. The c, and d distractors may be necessary actions, but don't guarantee outcome.
Rationale-b: Common, but not right
Rationale-c: May be necessary, but not a solution in and of itself
Rationale-d: Not appropriate because the system is mission critical
Reference: McConnell, Steve, Software Project Survival Guide, Microsoft Press, 1997, p 229


9.
a

Rationale: Principle 2 of the IEEE-CS/ACM Software Engineering Code of Ethics and Professional Practice states that "software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest". This is amplified in section 2.01, which further states that software engineers shall "provide service in their areas of competence, being honest and forthright about any limitations of their experience and education".
Reference: IEEE-CS/ACM Software Engineering Code of Ethics and Professional Practice, http://www.computer.org/tab/seprof/code.htm


10.
c

Rationale: The number of test cases affects the confidence and accuracy of the measured reliability. It is essential that the user profile is very close to the actual usage since the estimated reliability is based on the usage model, but the actual reliability is measured with the actual usage. The characteristics of the code are irrelevant when estimating reliability.
Reference: Sommerville, Ian, Software Engineering, 5th edition, Addison-Wesley, 1996, chapter 18.

11. c

Rationale: Answer a is incomplete. Answer b is too detailed, all of the code is not necessary. Answer c provides enough information for the user to assess costs of usage. Answer d is irrelevant.

Reference: Szyperski, Clements, Component Software, Addison-Wesley, 1997, p. 46.


12. c

Rationale: The project has hardly started construction and has already created a low-quality set of source files (poor cohesion and coupling, no physical folder structure, files too long). These problems should be addressed to ensure future work proceeds smoothly.

Rationale a: You don't want to just combine files because that it will probably increase coupling and decrease cohesion, they are probably already too big.

Rationale b: see "a"

Rationale d: It is very unlikely that the programming language is the problem.

Reference: McConnell, Steve, Code Complete, Microsoft Press, 1993, Chapter 6; and Lakos, John, Large Scale C++ Software Design, Addison-Wesley, 1996


13. c

Rationale: Afferent and efferent flows represent physical-dependent data, produced by the input devices or consumed by the output devices. The system design should be as independent as possible of this kind of data, because the I/O devices may require different data formats.

Reference: Yourdon, E., Constantine, L. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Prentice-Hall, 1986, Section 10.2.


14. d

Rationale: Answers a, b and c are described in this reference as key forces encouraging reference architectures; answer d is incorrect because, for at least some application domains, key aspects do not necessarily remain invariant over time.

Reference: Bass, Clements & Kazman "Software Architecture in Practice", Addison & Wesley, 1997, Chapter 17.


15. c

Rationale: Schedule, Budget, Staffing are all required in support of a SPMP.

Reference: IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans, Section 4, Elements of a Software Project Management Plan.


16. c

Rationale: Architecture is complete and detailed design and construction has begun. Thus in addition to the given of integration risk going up with a new technology, test time could go up to ensure coverage of the new technology, and both performance and reliability risks go up both from the technology itself, and because it is being added on after the initial architecture is complete. Usability is not at risk, because the technology is said to allow the UI design to be implemented. General schedule risk is intentionally not mentioned, because risk to the overall schedule isn't clear with the information given (i.e., test and integration could add time, but maybe lots of construction time does get saved as implied), so even though the natural reaction would be to call this a risky gamble, I think not being specific about the type of risks would make this a trick question.


Reference: McConnell, Steve, Rapid Development, Microsoft Press, 1996, p 89, 91


17. b

Rationale: Use of metrics for personnel evaluation distorts the measurements made because people will try to make the numbers look good. This prevents the use of the measurements for all of the other mentioned purposes. Other writers also make the point that software metrics should not be used to determine personnel actions.

a, c, and d appear on a list on p449 of Project Manager's Guide to Software Engineering's Best Practices, Christensen & Thayer. Other items on that list include: Tracking project and product progress, Analyzing defects, Determining project and product complexity, and Providing a basis for estimating future projects

Reference: Christensen, Mark & Thayer, Richard, Project Manager?s Guide to Software Engineering's Best Practices, Wiley - IEEE Computer Society Press, 2002, p449


18. c

Rationale: Quality is everywhere.

Reference: IEEE/EIA 12207.0-1996, Standard for Information Technology Software life cycle processes, 6.3 Quality Assurance Process


19. b

Rationale: As described in Chapter 16 of reference

Reference: Pressman, R.S., Software Engineering a Practioner's Approach, McGraw-Hill Science/Engineering/Math, 4th Ed., 1997.

20. b

Reference: ACM and IEEE-CS Software Engineering Code of Ethics and Professional Practice (version 5.2).


21.
d

Rationale: Team members need to know when and how modules are being changed. Version control is a first step toward enabling this.

Rationale a and b: Requiring that all fixes be performed by the author may introduce bottlenecks when one module needs several changes.

Rationale c: Configuration audits are an oversight method---they won't ensure that developers know about changes that are occurring

Rationale d: Best combination of methods to use

Reference: Pressman, R.S., Software Engineering a Practioner's Approach, McGraw-Hill Science/Engineering/Math, 4th Ed., 1997, Chapter 9


22. b

Rationale: The need to generate a highly interactive, reliable product that meets user?s needs requires the use of a model that enables the user to offer ongoing feedback. The Spiral model can address the risk, while the Evolutionary model gives the developers ample time to gather user feedback via the prototyped hardware.

Rationale a: The Evolutionary model is a potential choice, but the Code-and-Fix model is too unstructured for such a new venture.

Rationale b: Both the Spiral and Evolutionary models may meet your needs. The Spiral model enabled ongoing user feedback, while addressing risk. In addition, the game is delivered all at once. The Evolutionary model also leverages ongoing user feedback of both the game itself and of the game in conjunction with the hardware. Since the schedule is not aggressive, either model will suffice.,

Rationale c: Neither the Waterfall model nor the Code-and-Fix model are appropriate for the need to gather ongoing user feedback. Both models introduce too much risk for such a new venture for your company.,

Rationale d: The Spiral model is appropriate, but the Code-and-Fix model is not appropriate.

McConnell, Steve, Rapid Development, Microsoft Press, 1996, pp. 141, 142, 147, 148.


23. a

Rationale: The unrelated collection of functions in a module is undesirable and should be corrected.

Rationale a: Coincidental cohesion is correct

Rationale b: Logical cohesion exists when functions of a similar type, but with no logical relationship, are grouped in the same module.

Rationale c: Content coupling exists when one module changes the data of another module.

Rationale d: Common coupling exists when modules share data.

Van Vliet, Hans, Software Engineering: Principles and Practice, Wiley and Sons, 2000, pp. 299-301.


24. c

Rationale a: Implementation details are hidden
Rationale b: Not the most important aspect

Referente: Cleaveland, Craig, An Introduction to Data Types, Pearson Addison Wesley, 1986, pg. 113


25. c

Rationale: Using existing coding standards allows a developer's work to be read and understood by others much easier than if developer's follow his/her own standard.

Rationale a: Improving the names of variables and methods is vague and at best only addressed part of the readability problem.

Rationale b: The organization's coding standard needs to be followed, and that standard may differ from an pre-existing industry standard.

Rationale c: Following existing coding standards will provide all-around readability for developer's code.

Rationale d: Explaining one's own work only works for a short period of time at best.

Reference: Pfleeger, Shari Lawrence, Software Engineering: Theory and Practice. Prentice Hall, 2001, p. 310.