Requirements engineering

Design and Implementation 

Validation-Testing

Evolution and maintenance

Requirements Engineering (20 points)

In Chapter 4 of Software Engineering. Sommerville, Pearson, 2016 (10th edition), Sommerville discusses ethnography as a method for eliciting requirements.

1.

Discuss two advantages and two disadvantages of an ethnographic approach. (5 points)

2. Suggest two contexts where ethnography might be a challenging method of requirements engineering. For each context, how would you recommend that your team elicit requirements? (15 points)

Design (20 points)

Design patterns (5 points)

Which of the following statements is (are) true? Explain.

1. StudentsDatabase is the model, StudentsManager is the controller, and WebApplication is the view.

2.  StudentsDatabase is the model, StudentsManager is the view, and WebApplication is the controller.

3.  StudentsManager is the model, StudentsDatabase is the view, and StudentsManager is the controller.

4. This is not MVC, because StudentsManager must use a listener to be notified when the database changes.

(Credit: EPFL)

Design task (15 points)

Suppose you are asked to design a time management and notetaking system to support (1) scheduling meetings; and (2) tracking the documents associated with those meetings (e.g. agendas, presentations, meeting minutes).[footnoteRef:1] The system should accommodate [1: Such a feature seems like an inevitable development in any messaging platform…]

Make reasonable assumptions as needed.

1. Create a use case for “Schedule meeting”. You might follow the style in Sommerville Figure 7.3. (5 points)

2. Identify the objects in your system. Represent them using a structural diagram showing the associations between objects (“Class diagram” – cf. Sommerville Figure 5.9). (5 points)

3. Draw a sequence diagram showing the interactions between objects when a group of people are arranging a meeting (cf. Sommerville Figure 5.15). (5 points)

1.

Implementation (20 points)

Consider the software package is-positive.[footnoteRef:2] Examine its source code (see index.js) and its test suite (see test.js), then complete these questions. [2: https://www.npmjs.com/package/is-positive]

1. Describe the API surface of this package. (2 points)

2. Describe how you would test this package. Describe how and why your approach would change if you maintained a similar package in a different programming language of your choice. (2 points)

3. According to npmjs.com, this package receives over 16,000 downloads each month.

a. Why might an engineer choose to use this package? (4 points)

b. Why might an engineer choose not to use this package? (You may find insights from the chapter about dependencies in SE@Google) (4 points)

4. Do you think npmjs should exclude such packages from its registry? Discuss.

(8 points)

Validation (20 points)

Measuring test coverage (3 points)

What coverage does this test achieve on this method?

·  100% line coverage, 100% branch coverage

·  100% line coverage, 50% branch coverage

·  66% line coverage, 100% branch coverage

·  66% line coverage, 50% branch coverage

·  33% line coverage, 100% branch coverage

·  33% line coverage, 50% branch coverage

(For this question, 1/3=0.33 and 2/3=0.66)

(Credit: EPFL)

Designing for test-ability (8 points)

Review the (brief) section titled “The Impact of Test Doubles on Software Development” from the SE@Google textbook. The authors emphasize the importance of designing a codebase to be testable.

Consider the following code snippet, which (I think) is valid in a C++/Java-esque language:

You can imagine that the code base is full of switch statements like this.

1. What is the impact of this style on the test-ability of the code base? For example, how many distinct inputs are needed to achieve full line coverage of this method? Full branch coverage? (2 points)

2. Describe how you could use polymorphism to reduce the number of inputs needed to achieve full line coverage of this method. (4 points)

3. Would this change be an improvement? Why or why not? (2 points)

Responsibility (9 points)

Some people argue that developers should not be involved in testing their own code, but that all testing should be the responsibility of a separate team.

1. Under what circumstances might it be appropriate for a developer to test their own software? (e.g. contexts or kinds of tests or phases of development or…) (3 points)

2. Under what circumstances would it be inappropriate? (3 points)

3. Does your answer depend on whether a team follows a waterfall process or an incremental process (e.g. incorporating TDD)? Discuss. (3 points)

Evolution & Maintenance (20 points)

1. Discuss two reasons why software systems tend to degrade over time. For each reason, identify a strategy a team could take to fight entropy. (10 points)

2. If you were working as a software engineer, would you have a professional responsibility to develop code that can be easily maintained even if your employer does not explicitly request it? Discuss why or why not. (5 points)

3. Suppose you are tasked with optimizing the performance of a critical object in a large project. The bottleneck is due to calling an expensive function as part of a conditional check. You cannot understand the purpose of the conditional statement. Identify and then discuss the approaches suggested by Google’s Beyonce Rule and Chesterton’s Gate. In what circumstances might you choose to remove the conditional? When might you decide to keep it? (5 points)