Software Engineering - Test 2 Flashcards Preview

Software Engineering > Software Engineering - Test 2 > Flashcards

Flashcards in Software Engineering - Test 2 Deck (47):
1

Briefly explain "Keep the interface simple."

The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging.

2

Briefly explain "Create consistency and use common UI elements."

By using common elements in your UI, users feel more comfortable and are able to get things done more quickly. It is also important to create patterns in language, layout and design throughout the application to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the application.

3

Briefly explain "Make sure that the system communicates what's happening."

Always inform your users of location, actions, changes in state, or errors. The use of various UI elements to communicate status and, if necessary, next steps can reduce frustration for your user.

4

Briefly explain "Define how users can interact with the interface."

- What can a user do with their mouse, finger, or stylus to directly interact with the interface?
- What commands can a user give, that aren't directly a part of the product, to interact with it? An example of an "indirect manipulation" is when a user hits "Ctrl+C," they expect to be able to copy a piece of content.

5

Briefly explain "Give users clues about behavior before actions are taken."

- What about the appearance (color, shape, size, etc.) gives the user a clue about how it may function? These help the user understand how it can be used.
- What information do you provide to let a user know what will happen before they perform an action? These tell users what will happen if they decide to move forward with their action. This can include a meaningful label on a button, instructions before a final submission, etc.

6

Briefly explain "Anticipate and mitigate errors."

- Are there constraints put in place to help prevent errors? The Poka-Yoke Principle says that placing these constraints forces the user to adjust behavior in order to move forward with their intended action.
- Do error messages provide a way for the user to correct the problem or explain why the error occurred? Helpful error messages provide solutions and context.

7

Briefly explain "Consider system feedback and response time."

- What feedback does a user get once an action is performed? When a user engages and performs an action, the system needs to respond to acknowledge the action and let the user know what it is doing.
- How long between an action and a product's response time? Responsiveness (latency) can be characterized at four levels: immediate (less than 0.1 second), stammer (0.1 - 1 second), interruption (1 - 10 seconds), and disruption (more than 10 seconds).

8

Define "user story".

An indisputable and clear definition of a functional requirement as specified by the client, including but not limited to, priority, effort estimation, stakeholders, and associated non-functional requirements.

9

How is priority in relation to a user story defined?

This is explicitly defined by the client according to how important the functionality is or how soon he/she needs the functionality.

10

How is effort estimated in relation to a user story?

This is based upon the members of the team carrying out the implementation of the application and their individual estimations in relation to time and effort of the individual functionality.

11

How are stakeholders determined in relation to a user story?

Stakeholders are generally any individual that will interact with and/or benefit from the system. This includes users, business leaders associated with the system, developers, etc.

12

How are requirements written as part of a user story?

Requirement should be written in the form "As a {user role}, I want to be able to {requirement}, so that I can {do something}.

13

How are associated non-functional requirements written as part of a user story?

These are typically included as quality requirements related to the applicable user story.

14

Define "scenario" as it relates to a user story.

This includes a single flow of events that can occur from a user standpoint in relation to a user story. It is typically defined with pre-conditions, triggers, steps, and post-conditions that occur before, during and after the completion of the entire flow of events.

15

What is a "pre-condition" as it relates to a scenario of a user story?

This is a condition that must be met before a scenario can take place.

16

What is a "trigger" as it relates to a scenario of a user story?

This is an event that occurs which initializes the scenario.

17

What are the "steps" as it relates to a scenario of a user story?

These are the events that occur during a scenario.

18

What is a "post-condition" as it relates to a scenario of a user story?

This is a condition that must be met after the scenario has completed.

19

Describe a "use case diagram."

This models the relationships between any actor(s) and use cases. This is in direct relation to a use case and its definition of a client requirement.

20

Describe a "class diagram."

This models the data as part of a system or an individual component of the system. This model shows relationships between classes and basic class definition and functionality.

21

Describe a "sequence diagram."

This models any actor(s) interacting with key components of the system and any applicable subsystems. Information is transferred between components in the form of messages, moving down a timeline, until all initial messages that must be replied to have been answered.

22

Describe a "state-machine diagram."

This models all flows of events of the system or subsystem from a generic starting point. This could be considered the translation from user interface workflow to a model depicting its flow of events.

23

Define "coupling."

The degree to which software components are interconnected.

24

Define "cohesion."

The degree to which the elements of a component belong together.

25

What levels of coupling and cohesion are desired in any system?

Loose coupling, high cohesion.

26

Define "software architecture."

The structure or structures of a system, which comprise software components, the externally visible requirements of those components, and the relationships among them.

27

Explain the "separation of concerns" design principle.

Divide your application into distinct features with as little overlap in functionality as possible.

28

Explain the "single responsibility principle" in relation to design.

Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.

29

Explain the "Don't Repeat Yourself (DRY)" design principle.

Specific functionality should only be implemented in one component and not duplicated in another.

30

Explain the "minimize upfront design" design principle.

Only design what is necessary because YAGNI (You Ain't Gonna Need It).

31

Give a summary of the "client/server architecture."

Segregates the system into two applications, where the client makes requests to the server.

32

Give a summary of the "component-based architecture."

Decompose application design into reusable functional or logical components that expose well-defined communication interfaces.

33

Give a summary of a "layered architecture."

Partitions the concerns of the application into stacked groups (layers).

34

Give a summary of an "N-tier architecture."

Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.

35

Summarize "data coupling."

The interface between the units is a parameter list and all parameters must be used.

36

Summarize "stamp coupling."

The interface between the units is a parameter, which is some data structure containing fields but not all fields are used.

37

Summarize "control coupling."

The interface between the units is data (e.g. flags and switches) that influences the internal logic of the unit.

38

Summarize "common coupling."

The interface between the units is a shared data structure.

39

Summarize "functional cohesion."

The elements of the program unit are grouped because the all contribute to a single, well-defined task.

40

Summarize "sequential cohesion."

The elements of the program unit are grouped because the output of one part is input into another part.

41

Summarize "communicational cohesion."

The elements of the program unit are grouped because they operate on the same data.

42

Summarize "coincidental cohesion."

The elements of a program unit are not related but are grouped arbitrarily e.g. a utilities unit.

43

Briefly explain the "single responsibility principle."

A class should have one, and only one, reason to change.

44

Briefly explain the "open closed principle."

You should be able to extend a class' behavior, without modifying it.

45

Briefly explain the "Liskov substitution principle."

Derived classes must be able to be substituted for their base classes.

46

Briefly explain the "interface segregation principle."

Make fine grained interfaces that are client specific.

47

Briefly explain the "dependency inversion principle."

Depend on abstraction, not on concretions.