CSE2305 - Object-Oriented Software Engineering
Self Assesment Questions
For each question choose the single response which best answers the question, or which completes the statement most accurately.
| Question 95: | The testing phase of software development doesn'ts require: |
| testing that the implementation compiles correctly. |
| testing that the implementation matches the design. |
| testing that the implementation matches the requirements. |
| testing that the components of the implementation work separately and together. |
| testing that the implementation interacts correctly with the environment. |
| Question 96: | "In situ" testing is another name for: |
| Verifying that all code components fit together correctly. |
| Verifying that the code runs correctly on any platform. |
| Verifying that the code runs correctly on the specific platform it was developed on. |
| Verifying that the code runs correctly on the specific platform it is to be deployed on. |
| Verifying that the code obeys the software engineering dictum: "cum in situ doon ava quoppa te". |
| Question 97: | Integration is important because: |
| it ensures that the software is familiar to those who will use it. |
| it ensures that the software is "friendly" to those who will use it. |
| it ensures that the software works where it is to be used. |
| it ensures that the software replaces the existing system simultaneously everywhere it is to be used. |
| it ensures that the software is not installed until the old system has been removed. |
| Question 98: | System maintenance is necessary because: |
| Humans never get it right the first time. |
| The deployment platform may change over time. |
| The user's needs may change over time. |
| All of the above. |
| None of the above. |
| Question 99: | Maintenance may involve: |
| only additional coding and testing. |
| only additional analysis and design. |
| only additional design, coding and testing. |
| any of the development phases, except analysis. |
| any of the development phases. |
| Question 100: | A software process model is: |
| A representation of the way in which software is developed |
| A representation of the way in which software processes data |
| A representation of the way in which software is used |
| A representation of the way in which software may fail |
| An attractive young person used in the process of selling software |
| Question 101: | Which of the following is not a software process model: |
| The Waterfall Model |
| The Fountain Model |
| The Spiral Model |
| The Redwine Model |
| The Rainfall Model |
| Question 102: | The Waterfall Model is inadequate because: |
| Water is a continuous medium whereas code comes in discrete chunks (i.e. functions, objects, etc.), so all water-based analogies for software development are doomed to failure. |
| it incorrectly suggests that the sequence of development is a stately progression from stage to stage, with no backwards steps. |
| it incorrectly suggests that the sequence of development is a random process of rising and falling from stage to stage, with backwards progress just as likely as forwards. |
| it incorrectly suggests that the sequence of development is a process unpredictable in the details, but predictable in its overall effect, like a waterfall. |
| it incorrectly suggests that the sequence of software development is susceptible to uncontrollable external and internal forces (analogous to gravity and surface tension). |
| Question 103: | Gall's dictum states: |
| "Never give a coder an even break" (i.e. there must always be an odd number of cases in a switch statement - not counting the default case). |
| "In real systems, the whole is greater than the sum of the parts" (i.e. the interesting behaviour of real systems is emergent, deriving from the interactions of their many parts). |
| "Any sufficiently advanced software system is indistinguishable from magic" (i.e. too complex to be comprehended by an unaided human mind, without appropriate tools). |
| "A complex system that works is invariably found to have evolved from a simple system that works" (i.e. working systems must evolve into complexity, they cannot be made complex to begin with). |
| "Software expands to fill - and exceed! - the hardware available o run it" (i.e. software developers anticipate ongoing improvements in hardware, and are always be tempted to add advanced features to their systems, which will generally not work well on the hardware that is available actually at the time). |
| Question 104: | Exploratory programming is: |
| An advanced form of prototype-based development |
| The naive "code-compile-recode-recompile-recode-..." technique used by novice programmers |
| A form of programming where the system explores a "solution space" using genetic algorithms. |
| Implementing a range of different solutions and then comparing them for efficiency. |
| Implementing a solution in a variety of languages and then comparing them for efficiency. |
| Question 105: | The Fountain model differs from the Waterfall model in that: |
| It is an artificial model not a natural one |
| The various phases of the development process happen in the reverse order in the two models |
| The Fountain model allows for the development process to "fall back" to earlier phases when necessary. |
| The Fountain model always splits the development effort at each stage: some effort moves on to the next phase, some is directed back to review of earlier stages |
| There is no difference - they are two names for the same model |
| Question 106: | The Fountain model acknowledges that: |
| some development phases must begin before others. |
| any development phase may begin before any other. |
| software development is inherently a chaotic process, so nothing can be said about which phases begin before which others. |
| all phases actually proceed in parallel with feedback loops between them. |
| none of the above. |
| Question 107: | The Spiral model was suggested by: |
| Spirato Alighieri in 1792 |
| Barry Boehm in 1988 |
| Roger Pressman in 1988 |
| Ian Sommerville in 1998 |
| The ACM Advisory Committee on Software Development in 1993 |
| Question 108 | The five general phases in the Spiral model are: |
| Analysis, Design, Implementation, Testing, and Review |
| Review, Decision, Engineering, Acceptance, and Planning |
| Analysis, Design, Engineering, Testing, and Payment |
| Review, Risk-analysis, Prototyping, Engineering, and Planning |
| Review, Risk-analysis, Design, Implementation, and Planning |
| Question 109: | Which of the following are not reviewed in the various Review phases of the Spiral model? |
| Options |
| Objectives |
| Alternatives |
| Constraints |
| All of them are reviewed at some time. |
| Question 110: | The Engineering phase of the Spiral model incorporates: |
| implementation only |
| design and implementation |
| analysis, design, and implementation |
| analysis, design, implementation, and testing |
| analysis, design, implementation, testing, and integration |
| Question 111: | Which of the following increases as the Spiral model process moves "outwards"? |
| Risk |
| Profit |
| Time-to-delivery |
| Time-to-completion |
| None of the above |
| Question 112: | What did Fredrick Brooks mean when he said "There is no magic bullet..."? |
| Software engineers should be shot (but we're not allowed to). |
| The "software crisis" was an illusion that proved not to be a threat at all. |
| No one technique will magically kill all software development problems. |
| Real design problems can only be solved with real (i.e. non-magical) tools. |
| Systems that appear magical from the outside, are really just composed of simple code on the inside. |
| Question 113: | A software development model is really just: |
| a more complex metaphor for what happens in reality. |
| a theory which approximates what happens in reality |
| an exact isomorphism to what happens in reality |
| an elaboration of the abstraction of flexibility |
| a comforting lie we tell ourselves to maintain the delusion that we're developing software in some logical fashion. |
| Question 114: | A metric is: |
| an ISO standard unit (such a metre, kilogram, etc.) |
| a qualitative measure of the degree to which a system component possesses a given attribute |
| a quantitative measure of the degree to which a system component possesses a given attribute |
| a qualitative attribute which determines the degree to which a system component may be measured |
| an attributed quantity which measures a system component in degrees |
| Question 115: | Why is it useful to measure aspects of a system? |
| Because human subjective perception is notoriously inaccurate. |
| Because numbers give us a way of comparing, controlling and predicting system behaviour. |
| Because measurements give us a way of tracking progress. |
| Because it gives us an assessment of the product quality. |
| All of the above. |
| Question 116: | Which of the following is not required when developing a metric? |
| a measurable property |
| a relationship between that property and what we wish to know |
| a relationship between that property and some immeasurable dimensions of the system |
| a consistent expression of that relationship |
| All of them are required. |
| Question 117: | What are the features of a poor metric? |
| It is complex, hard-to-measure, and persuasive. |
| It is complex, consistent, and language-independent. |
| It is simple, hard-to-measure, and has no units. |
| It is complex, subjective, and inconsistent. |
| It is complex, subjective, and persuasive. |
| Question 118: | Which of the following is hard to measure? |
| Costs (effort, time, expenditure) |
| Quality (robustness, reliability, stability) |
| Remediation (errors found during coding, testing, or after delivery) |
| All of them. |
| None of them. |
| Question 119: | "Lines of code" is a poor metric because: |
| it is language independent. |
| it penalizes efficient, compact coding. |
| it measures what matters, not what can be measured. |
| it was developed as a metric in the 1960's. |
| All of the above. |
| Question 120: | In McCabe's cyclomatic complexity metric code is first represented as: |
| A syntax graph |
| A data-flow graph |
| A flow control graph |
| A control-vs-command graph |
| None of the above |
| Question 121: | The cyclomatic complexity of a graph is: |
| the number of closed paths in the graph. |
| the number of independent test cases required to reach every node in the graph. |
| the number of edges - the number of nodes + 1. |
| All of the above. |
| None of the above. |
Last updated: August 28, 2005