Term
| For the system requirements capture and system analysis engineering workflows, in which phase of the Unified Software Development Process does the majority of their effort occur? |
|
Definition
| For both workflows, the majority of their effort occurs during the Elaboration Phase. |
|
|
Term
Which of these reasons could failing to do system requirements capture well result in a failure? System no longer needed, Lack of hardware resources, Unrealistic user expectation, lack of user involvement, high personnel turnover? & |
|
Definition
System no longer needed Unrealistic user expectations Lack of user involvement |
|
|
Term
In domain modeling, which of the following UML concepts can appear as nouns in a problem statement? class, association, generalization, attribute, role? |
|
Definition
|
|
Term
Indicate whether concept is a classifier or an instance. external system, scenario, actor |
|
Definition
external system - instance scenario - instance / use case - classifier actor - classifier |
|
|
Term
| In a use-case model, what does an <<extend>> use case represent? |
|
Definition
represents a conditional addition to a use case's flow of events represents optional behavior that is only executed when some condition is true. |
|
|
Term
| Each analysis class encapsulates and isolates changes to some aspect of a system. Indicate what Boundary, Entity, and Control class encapsulates and isolates. |
|
Definition
Boundary - system's interface Entity - system's information (data) Control - The system's control logic |
|
|
Term
| One of the best practices for analysis class interaction states that entity classes should not interact with other entity classes. Why do you think that this a good practice to follow? |
|
Definition
| The primary reason is to minimize the coupling among the entity classes. By not allowing entity to entity class interactions, entity classes do not know about any other classes in the system( note that the interaction between control and entity classes is one way from control to entity class). Therefore, it is easy to restructure the data of the system without affecting many other classes. Thus, maintenance of the data and access to it is made much easier. |
|
|
Term
Give two system requirements capture problems that could lead to the failure of a software development project and for each problem give one reason why this problem might arise. The developers fail to capture all of the requirements: |
|
Definition
The developers do not understand what the user wants due to lack of domain knowledge. The developers do not know what the user wants due to the lack of communication with the user. The developers have not obtained feedback from the users. |
|
|
Term
Give two system requirements capture problems that could lead to the failure of a software development project and for each problem give one reason why this problem might arise. Users are not involved in requirements capture. &l |
|
Definition
The developers think they know what the users want; therefore, they do not involve users. The developers do not want to talk to the users. The users are not motivated of interested in developing the system (maybe it is being imposed on them). |
|
|
Term
Give two system requirements capture problems that could lead to the failure of a software development project and for each problem give one reason why this problem might arise. Users have unrealistic expectations of what the systems |
|
Definition
The developers have promised more than they can deliver. The developers have not explained clearly to the users what is and what is not possible to implement. |
|
|
Term
Give two system requirements capture problems that could lead to the failure of a software development project and for each problem give one reason why this problem might arise. The requirements and specifications constantly change.& |
|
Definition
Users do not have a clear idea of what they want Developers do not understand what the user wants. Developers have not established control procedures for making changes to the requirements.. |
|
|
Term
Give two kinds of risk taht can arise in a software development project and for each risk briefly state one way in which it could affect a project. economic risks |
|
Definition
| The costs of developing the system may be greater than the benefit that is derived from the system resulting in the project being cancelled before it is completed. |
|
|
Term
Give two kinds of risk taht can arise in a software development project and for each risk briefly state one way in which it could affect a project. Technical Risks |
|
Definition
The required technology may not be available to implement the required functionality. We may not know how to use new technology and thus are unable to implement the system. |
|
|
Term
Give two kinds of risk taht can arise in a software development project and for each risk briefly state one way in which it could affect a project. operation risks |
|
Definition
We may not have people with the required skills to operate the system. The system may not fit with current work practices, which may require work practices to be redesigned. |
|
|
Term
Give two kinds of risk taht can arise in a software development project and for each risk briefly state one way in which it could affect a project. organizational risks |
|
Definition
The users may not accept the system if there is a loss of jobs leading to its failure. We may not be able to get the training required for users. Politics in the organization may cause opposition to the project leading to its failure. |
|
|
Term
Give two kinds of risk taht can arise in a software development project and for each risk briefly state one way in which it could affect a project. legal risks |
|
Definition
There may be liability issues if a business looses data/money due to system problems. There may be copyright infringement issues. There may be patient infringement issues. |
|
|
Term
| All verbs/verb phrases in a problem statement do no represent associations for the following reasons: |
|
Definition
In domain modeling, we want to identify relevant associations, that is, those associations that represent relationships about which the application wants to keep information. Verb/verb phrases in a problem statement can also represent concepts other than associations. For example, some verbs may represent operations while other verbs may describe implementation constructs. |
|
|
Term
Classifier Actor Use Case |
|
Definition
Instance user or system scenario |
|
|
Term
Use-case model Uses client's language External View of system Used primarily as a contract between client/developer to agree on system functionality |
|
Definition
Analysis Model Uses developer's language Analysis calsses and packages structure the internal view Used primarily by developers to understand how to design and implement the system. |
|
|
Term
Use-case Model May contain ambiguities, redundancies, inconsistencies, etc. Captures system functionality Defines use cases |
|
Definition
Analysis Model Contains no ambiguities, redundancies, inconsistencies, etc. Outlines system realizations Defines use-case realizations. |
|
|
Term
| When we do class analysis, a rule of thumb is that a class should have at most 3-5 responsibilities. why is this a good rule to follow? |
|
Definition
| This is a good rule to follow because we want a class to have high cohesion. However, if a class has too many responsibilities it is likely to have low cohesion (i.e. it is doing too many things, which may not be all that related to each other). A class is more likely to be highly cohesive if it has few responsibilities. |
|
|
Term
| What can an action node on an activity diagram represent? |
|
Definition
An action node on an activity diagram can represent either 1. the execution of a statement in a procedure (i.e, a state of a computation) 2. the performance of a step in a workflow(i.e, a state of a workflow) |
|
|
