Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
61 Cards in this Set
- Front
- Back
|
FURPS |
a requirements classification framework (acronym stands for functionality, usability, reliability, performance, and security) |
|
|
UML |
AKA Unified Modeling Language. Standard set of model constructs and notations defined by the object management group.
|
|
|
Workflow |
sequence of processing steps that completely handles one business transaction or customer request. |
|
|
Activity diagram |
describes user (or system) activities, the person who does each activity, and the sequential flow of these activities |
|
|
Synchronization bar |
activity diagram component that either splits a control path into synchronization bar multiple concurrent paths or recombines concurrent paths |
|
|
Swimlane Heading |
activity diagram column containing all activities for a single agent or organizational unit |
|
|
Five activities of systems analysis |
1) Gather detailed information 2) Define requirements 3) Prioritize requirements 4) Develop user interface dialogs 5) Evaluate requirements with users |
|
|
Three types of models |
Textual Models Graphical Models Mathematical Models |
|
|
Steps in interview process |
- Prepare questions. - Meet with individuals or group of users. - Obtain and discuss answers to the questions. - Document the answers. - Follow up as needed with future meetings or interviews. |
|
|
Preparing for interview |
most important step → establishing the objective 2nd → determining which stakeholders should be involved in the interview |
|
|
Event decomposition technique |
a technique to identify use cases by determining the external business events to which the system must respond. |
|
|
External Event |
an event that occurs outside the system, usually initiated by an external agent. |
|
|
Temporal event |
an event that occurs as a result of reaching a point of time. |
|
|
State event |
an event that occurs when something happens inside the system that triggers some process. |
|
|
Use Case Diagram |
the UML model used to graphically show use cases and their relationships to actors. |
|
|
Automation boundary |
the boundary between the computerized portion of the application and the users who operate the application but are part of the total system. |
|
|
Problem domain |
the specific area (or domain) of the user’s business need (or problem) that is within the scope of the new system. |
|
|
Brainstorming technique |
a technique to identify problem domain objects in which developers work with users in an open group setting. |
|
|
Noun technique |
a technique to identify problem domain objects by finding and classifying the nouns in a dialog or description. |
|
|
Compound attribute |
an attribute that consists of multiple pieces of information but is best treated in the aggregate. |
|
|
Association |
a term, in UML, that describes a naturally occurring relationship between specific things, sometimes called a relationship. |
|
|
Relationship |
a term that describes a naturally occurring association between specific things, sometimes called an association. |
|
|
Cardinality |
a measure of the number of links between one object and another object in a relationship. |
|
|
Multiplicity |
a measure, in UML, of the number of links between one object and another object in an association. |
|
|
Multiplicity constraints |
the actual numerical count of the constraints on objects allowed in an association. |
|
|
Binary associations |
associations between exactly 2 distinct types of things. |
|
|
Unary association |
an association between two instances of the same type of thing. |
|
|
Ternary association |
an association between exactly 3 distinct types of things |
|
|
n-ary association |
an association between n distinct types of things. |
|
|
ERD |
Entity relationship diagram. a diagram consisting of data entities (i.e., sets of things) and their relationships. |
|
|
Data entities |
the term used in an ER diagram to describe sets of things or individual things. |
|
|
Class |
a category or classification of a set of objects or things. |
|
|
Domain classes |
classes that describe objects from the problem domain. |
|
|
Class diagram |
diagram consisting of classes (i.e., sets of objects) and associations among the classes. |
|
|
Domain model class diagram |
a class diagram that only includes classes from the problem domain. |
|
|
Association class |
an association that is also treated as a class; often required in order to capture attributes for the association. |
|
|
Generalization/ specialization relationship |
a type of hierarchical relationship in which subordinate classes are subsets of objects of the superior classes; an inheritance hierarchy. |
|
|
Semantic net |
a graphical representation of an individual data entity and its relationship with other individual data entities. |
|
|
Superclass |
the superior or more general class in a generalization/specialization relationship |
|
|
Subclass |
the subordinate or more specialized class in a generalization/specialization relationship |
|
|
Inheritance |
the concept that specialization classes inherit the attributes of the generalization class |
|
|
Abstract class |
a class that describes a category or set of objects but that never includes individual objects or instances |
|
|
Concrete class |
a class that allows individual objects or instances to exist. |
|
|
Whole-part relationship |
a relationship between classes in which one class is a part or a component portion of another class |
|
|
Aggregation |
a type of whole-part relationship in which the component parts also exist as individual objects apart from the aggregate |
|
|
Composition |
a type of whole-part relationship in which the component parts cannot exist as individual objects apart from the total composition |
|
|
MOVING ON TO SCRUM |
MOVING ON TO SCRUM |
|
|
Product backlog |
Requirements are captured as items in a list in a product backlog. |
|
|
Product Noise Level |
Simple Complicated Complex Anarchy |
|
|
Scrum |
Series of sprints. constant durations 2-4 weeks |
|
|
Sequential vs Overlapping development |
Instead of doing all of one thing at a time, Scrum teams do a little of everything all the time |
|
|
No changes during a sprint |
plan duration of sprints around how long you can go without change. |
|
|
product owner |
decides features release date accepts or rejects results |
|
|
ScrumMaster |
Management Role |
|
|
The team |
5-9 people cross-functional membership should change between sprints |
|
|
The Daily Scrum |
15 minutes not for problem solving what did you do today/yesterday? Is anything in your way? |
|
|
Sprint Review |
Team presents what it accomplished over sprint. 2 hr prep time rule no slides whole team participates |
|
|
Sprint Retrospective |
Take a look at what is, and what is not working. 15-20 minutes. After every sprint |
|
|
Start/Stop/Continue (Sprint Retrospective) |
Start doing Stop doing Continue doing |
|
|
Product Backlog |
A list of all the desired work on a project. |
|
|
Sprint Goal |
Short statement of what will be focused on during the sprint |
