Software Engineering Missed Qs

Process framework activities are populated with A) milestones B) work products C) QA points

D) all of the above

At the end of a formal technical review all attendees can decide to A) accept the work product without modification B) modify the work product and continue the review C) reject the product due to stylistic discrepancies D) reject the product due to severe errors

E) a and d

The project plan should include explicit techniques for _______ and _______ management? A) change B) cost C) error D) quality

E) a and d

Two tools for computing critical path and project completion times from activity networks are A) CPM B) DRE C) FP D) PERT

E) a and d

An architectural style encompasses which of the following elements? A) constraints B) set of components C) semantic models D) syntactic models

E) a, b, c

In the architecture trade-off analysis method the architectural style should be described using the A) data flow view B) module view C) process view D) user view

E) a, b, c

What types of abstraction are used in software design? A) control B) data C) environmental D) procedural

E) a, b, d

A useful technique for evaluating the overall complexity of a proposed architecture is to look at the component A) cohesion B) flow dependencies C) sharing dependencies D) size

E) b and c

The criteria used to assess the quality of an architectural design should be based on system A) accessibility B) control C) data D) implementation

E) b and c

In component design elaboration requires which of the following elements to be describe in detail? A) Algorithms B) Attributes C) Interfaces D) Operations

E) b, c, d

Which of these constructs is used in structured programming? A) branching B) condition C) repetition D) sequence

E) b, c, d

Encapsulation of attributes and operations inside objects makes it easy to obtain object state information during testing.

False

Which of the following is not one of the context-free questions that would be used during project inception?

Who will pay for the work?

Which of the following is not a characteristic common to all design methods? A) configuration management B) functional component representation C) quality assessment guidelines D) refinement heuristics

a

Which of these framework activities is not normally associated with the user interface design processes? A) cost estimation B) interface construction C) interface validation D) user and task analysis

a

Which of these software characteristics is not a factor contributing to project coordination difficulties? A) interoperability B) performance C) scale D) uncertainty

b

Risk projection attempts to rate each risk in two ways A) likelihood and cost B) likelihood and impact C) likelihood and consequences D) likelihood and exposure

c

Statistical quality assurance involves A) using sampling in place of exhaustive testing of software B) surveying customers to find out their opinions about product quality C) tracing each defect to its underlying cause, isolating the "vital few" causes, and moving to correct them D) tracing each defect to its underlying causes and using the Pareto principle to correct each problem found

c

Which of the following is not an example of infrastructure components that may need to be integrated into the software architecture? A) Communications components B) Database components C) Interface components D) Memory management components

c

In collaborative requirements gathering the facilitator

controls the meeting

Software risk impact assessment should focus on consequences affecting A) planning, resources, cost, schedule B) marketability, cost, personnel C) business, technology, process D) performance, support, cost, schedule

d

Which of the following is not one of the broad categories used to classify operations? A) computation B) data manipulation C) event monitors D) transformers

d

Six Sigma methodology defines three core steps.

define, measure, analyze

A stakeholder is anyone who will purchase the completed software system under development.

false

A stereotype is the basis for class reuse in UML modeling.

false

An architectural description is often documented using an architecture template.

false

Attributes are chosen for an object by examining the problem statement and identifying the entities that appear to be related.

false

Documentation does not need to be tested.

false

In agile process models the only deliverable work product is the working program.

false

In general software only succeeds if its behavior is consistent with the objectives of its designers.

false

In requirements validation the requirements model is reviewed to ensure its technical feasibility.

false

In structured analysis models focus on the structure of the classes defined for a system along with their interactions.

false

It is important to consider alternative actor interactions when creating a preliminary use case

false

Multiple class testing is too complex to be tested using random test cases.

false

Object-oriented analysis techniques can be used to identify and refine user task objects and actions without any need to refer to the user voice.

false

Product quality can only be assessed by measuring hard quality factors.

false

Program flow graphs are identical to program flowcharts.

false

Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that software is able to continue execution without interruption.

false

Risk monitoring involves watching the risk indicators defined for the project and not determining the effectiveness of the risk mitigation steps themselves.

false

Since iterative process model work best for object-oriented projects it is impossible to determine whether an increment will be completed on time or not.

false

Software quality might be defined as conformance to explicitly stated requirements and standards, nothing more and nothing less.

false

The communication activity is best handled for small projects using six distinct actions (inception, elicitation, elaboration, negotiation, specification, validation).

false

The correctness of the OOA and OOD model is accomplished using formal technical reviews by the software quality assurance team.

false

The deployment design elements specify the build order for the software components.

false

The elements of software quality assurance consist of reviews, audits, and testing.

false

The quality dilemma might be summarized as choosing between building things quickly or building things correctly.

false

The reason for refining risks is to break them into smaller units having different consequences.

false

Units and stubs are not needed for unit testing because the modules are tested independently of one another.

false

WebApp content design at the component level focuses on content objects and the manner in which they interact.

false

With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.

false

Which model depicts the look and feel of the user interface along with all supporting information?

implementation model

Which of these software characteristics are used to determine the scope of a software project?

information objectives, function, performance

Software safety is a quality assurance activity that focuses on hazards that

may cause an entire system to fail

What are the four framework activities found in the Extreme Programming (XP) process model?

planning, design, coding, testing

Which model depicts the image of a system that an end user creates in his or her head?

system perception

Classes and components that exhibit functional, layer, or communicational cohesion are relatively easy to implement, test, and maintain.

true

Component-level design for mobile apps is not any different from component-based design for Web apps.

true

Good enough software delivers high quality software functions along with specialized functions that contain known bugs.

true

In many cases there is no need to create a graphical representation of a usage scenario.

true

Interface design patterns typically include a complete component-level design (design classes, attributes, operations, and interfaces).

true

Product and process decomposition occurs simultaneously as the project plan evolves.

true

Requirements engineering is a generic process that does not vary from one software project to another.

true

Test case design for OO software is driven by the algorithmic detail of the individual operations.

true

The use of stereotypes can help identify the nature of components at the detailed design level.

true

Graph-based Testing Methods (black box)

• Black-box methods based on the nature of the relationships (links) among the program objects (nodes), test cases are designed to traverse the entire graph • Transaction flow testing - nodes represent steps in some transaction and links represent logical connections between steps that need to be validated • Finite state modeling - nodes represent user observable states of the software and links represent transitions between states • Data flow modeling - nodes are data objects and links are transformations from one data object to another • Timing modeling - nodes are program objects and links are sequential connections between these objects, link weights are required execution times

Equivalence Partitioning

• Black-box technique that divides the input domain into classes of data from which test cases can be derived • An ideal test case uncovers a class of errors that might require many arbitrary test cases to be executed before a general error is observed • Equivalence class guidelines: 1. If input condition specifies a range, one valid and two invalid equivalence classes are defined 2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined 3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined 4. If an input condition is Boolean, one valid and one invalid equivalence class is defined

Orthogonal Array Testing

• Black-box technique that enables the design of a reasonably small set of test cases that provide maximum test coverage • Focus is on categories of faulty logic likely to be present in the software component (without examining the code) • Priorities for assessing tests using an orthogonal array 1. Detect and isolate all single mode faults 2. Detect all double mode faults 3. Mutimode faults

Boundary Value Analysis

• Black-box technique that focuses on the boundaries of the input domain rather than its center • BVA guidelines: 1. If input condition specifies a range bounded by values a and b, test cases should include a and b, values just above and just below a and b 2. If an input condition specifies and number of values, test cases should be exercise the minimum and maximum numbers, as well as values just above and just below the minimum and maximum values 3. Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the minimum and maxim output reports 4. If internal program data structures have boundaries (e.g. size limitations), be certain to test the boundaries

Model-Based Testing

• Black-box testing technique using information contained in the requirements model as a basis for test case generation • Steps for MBT 1. Analyze an existing behavior model for the software or create one. 2. Traverse behavioral model and specify inputs that force software to make transition from state to state. 3. Review behavioral model and note expected outputs as software makes transition from state to state. 4. Execute test cases. 5. Compare actual and expected results (take corrective action as required).

Specialized Testing

• Graphical User Interface (GUI) - test cases can be developed from behavioral model of user interface, use of automated testing tools is strongly recommended. • Documentation and Help Review and inspection to check for editorial errors Black-Box for live tests o Graph-based testing to describe program use o Equivalence partitioning and boundary value analysis to describe classes of input and interactions • Real-Time Systems 1. Task testing - test each task independently 2. Behavioral testing - using technique similar to equivalence partitioning of external event models created by automated tools 3. Intertask testing - testing for timing errors (e.g. synchronization and communication errors) 4. System testing - testing full system, especially the handling of Boolean events (interrupts), test cased based on state model and control specification

Black-Box Testing Questions

• How is functional validity tested? • How is system behavior and performance tested? • What classes of input will make good test cases? • Is the system particularly sensitive to certain input values? • How are the boundaries of a data class isolated? • What data rates and data volume can the system tolerate? • What effect will specific combinations of data have on system operation?

Software Testability Checklist

• Operability - the better it works the more efficiently it can be tested • Observability - what you see is what you test • Controllability - the better software can be controlled the more testing can be automated and optimized • Decomposability - by controlling the scope of testing, the more quickly problems can be isolated and retested intelligently • Simplicity - the less there is to test, the more quickly we can test • Stability - the fewer the changes, the fewer the disruptions to testing • Understandability - the more information known, the smarter the testing

Control Structure Testing (type of white box testing)

• White-box technique focusing on control structures present in the software • Condition testing (e.g. branch testing) - focuses on testing each decision statement in a software module, it is important to ensure coverage of all logical combinations of data that may be processed by the module (a truth table may be helpful) • Data flow testing - selects test paths based according to the locations of variable definitions and uses in the program (e.g. definition use chains) • Loop testing - focuses on the validity of the program loop constructs (i.e. simple loops, concatenated loops, nested loops, unstructured loops), involves checking to ensure loops start and stop when they are supposed to (unstructured loops should be redesigned whenever possible)

The software equation can be used to show that by extending the project deadline slightly A) fewer people are required B) you are guaranteed to meet the deadline C) more lines of code can be produced D) none of the above

A