Last reviewed: Nov 21st, 2024.
Out-of-Date - Please contact CS Sysadmin
Click here for more information
Click here to update this page

Software Engineering Comprehensive Examination Policies

The aim of the examination to demonstrate mastery of the issues that a software engineer will confront in professional practice. No one works from memory only and without resources. No one works without familiarity of the problem at hand.

The one examination will cover all aspects of software engineering, from initial concept and requirements elicitation through to maintenance and evolution. Moreover, the responses must show an integration of the areas. For example, what metrics might an engineer assure that a particular architectural requirement has been satisfied?

The rules:

1. One 4 hour exam; personal breaks as need.
2. A reading will be provided one-week before the exam.
3. The exam will be focused on software engineering issues related to the distributed reading.
4. No computers, phones, etc or written materials.
5. One software engineering text, Sommerville's current edition, will be provided.
6. A fresh copy of the reading will distributed.

The intent of rule 5 is to prevent a mere recitation of issues. The resource is to be used to guide and inform the responses, and to mitigate the need to memorize lists of practices. Copying lists from the resources without specific relation the the problem at hand will not receive credit.

Guided thinking about the reading

The important bit is not to compartmentalize your thinking, but rather look for interactions and relationships between the various software engineering activities. The thought directions below attempt to give you some direction in integrating your thinking.

Determine key requirements with a rationale for each.
How does one apply metrics to determine the requirements have been met?

Give an architecture for the given system.
How does one apply metrics to determine that the system complies with the designed architecture?

Recommend a process model for the construction of the system.
Consider the choice of metrics for verifying the requirements and architecture with respect to the choice of the process model.

Optimize the architecture of the system with respect to one of [safety/usability/performance/etc].
Assess this optimization's impact your recommendations for an implementation process model.
Assess the impact of your optimization for validating the architecture of the system.

Assess the technical risks of the project; give strategies for risk mitigation. Do any strategies for risk mitigation impact the process model?

Here is a [code sample / API] for proposed reuse in the system. Can it be used without modification?
If it cannot be reused as-is, should it be scrapped and rewritten or just modified? Justify your response.
How would this fragment be tested?

What happens if an acceptance test invalidates a requirement?

For any additional questions, please contact Dr. Gallagher.