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;
146 Cards in this Set
- Front
- Back
|
Waterfall Process: Emphasis, Weakness, Style |
Emphasizes: Simplicity, Traceability Weakness: Requirement design mistakes costly Style: Highly controlled, High Ceremony |
|
|
Spiral Process: Emphasis, Weakness, Style |
Emphasis: Risk management Exploring alternatives Weakness: Exploring alternatives Costly Style: Moderately controlled, Moderate Ceremony |
|
|
Agile Process: Emphasis, Weakness, Style |
Ephasis: Flexibility, Immediacy Weakness: Continual rework costly Style: Rapid low control, Low ceremony |
|
|
traceability |
document relationships between requirements and system elements |
|
|
immediacy |
getting some sort of working system to the customer as fast as possible |
|
|
rework |
redesigning the architecture/refactoring the code |
|
|
controlled |
conformance to process is highly valued even if it slows project |
|
|
ceremony |
how much analysis, documentation and planning involved |
|
|
iterative |
WHOLE system working PRETTY well, then add feature in system |
|
|
incremental |
get PART of system REALLY well, then add more |
|
|
T/F You can mix/match iterative and incremental with spiral/waterfall/agile? |
true |
|
|
When is incremental good to use? |
Most of a system's value is tightly concentrated in small # of components |
|
|
When is iterative good to use? |
When you need to implement most of a system BEFORE you can get much value |
|
|
Waterfall process: What are the 5+1 steps? |
Requirements analysis +1 Prototyping Design Implementation Testing Operation |
|
|
Spiral process: LOTS o steps |
Generic each time: draft, analyze, plan, establish For each requirements, architecture, program designs Finally implementation, testing, operation |
|
|
Agile process: 7 steps |
1 Cust provides stories 2 do spike to evaluate & control risk 3 prioritize stories, plan 4 write/run/modify unit tests 5 implement, can reiterate unit testing 6 system and acceptance tests 7 operation |
|
|
When is waterfall used? a. small systems, fully understood b. larger systems with vague req and many alternatives c. rapidly create small but useful, and expand from there |
a. |
|
|
When is Spiral Used? a. small systems, fully understood b. larger systems with vague req and many alternatives c. rapidly create small but useful, and expand from there |
b. |
|
|
What are Functional Requirements? |
Tell what the system can do |
|
|
How can functional requirements be presented? |
Written as unstructured text -External Viewpoint (requirements definition) -System Viewpoint (requirements specification) Written as structured use cases |
|
|
What is Requirements Definition? |
Stated from an external viewpoint emphasis on role of the system |
|
|
What is Requirements Specification? |
Stated from internal viewpoint emphasis on how system works |
|
|
Requirements Definition External Example: Sprinklers |
"The sprinkler never runs on rainy days" |
|
|
Requirements Specification Internal Example: Sprinklers |
"The controller will not engage the water pump any time the ambient water sensor is triggered" |
|
|
Define Non-Functional Requirements |
How well the system should do stuff -unstructured text -written in terms of Fit Criteria |
|
|
What is Fit Criteria? |
-Based on customer needs -Exactly how good does system need to be? -Related to Quality Attributes |
|
|
Here are the Quality Attributes: |
-Reliability -Portability -Efficiency -Reusability -Integrity -Interoperability -Usability -Flexibility -Testability -Maintainability |
|
|
Fit Criteria Example: Sprinklers |
"The system must be compatible with the following ambient water sensors X, Y, Z" |
|
|
What is a Use Case |
Structured requirement definition Describes a way to use the system. More formal and precise. |
|
|
What is in a basic Use Case? |
Use Case Name Actor Pre-conditions Post-conditions Flow of Events |
|
|
UML Class diagram |
Shows: Entities, attributes, relationships *=unlimited cardinality Lines w/o arrow = Reference Lines with OPEN arrow = Specialization Lines with REG arrow = Dependencies |
|
|
ERD diagram: Entity Relationship Diagram |
Shows: Entities, attributes, relationships Diamond lines show Relationships One box per entity Numbers on lines show Cardinality |
|
|
Dataflow Diagram |
Ovals: Function provided by the system Rectangles: Actors Half-Rectangle: Data Store Arrow in = Parameter Arrow out = output *Often clearer 1 diagram per use-case |
|
|
Message Sequence Diagram |
One box per entity Dashed vertical line = lifeline of entity Arrows: Messages, arrow back if return val Conditionals: Written with Brackets [] Loops: Shaded box |
|
|
State Chart: Change over time |
One box per state Arrow: Possible state transition (Annotated: To show when trans occurs) Filled Circle: Start Nested Filled Circle: Stop |
|
|
What are the 3 parts to prototyping general idea? |
1. Depict how you think system should look 2. Test the prototypes with users 3. Fix Up the prototypes with your learning |
|
|
Throwaway Prototypes vs. Evolutionary Prototypes |
Throwaway: -Paper Proto: Sketches -Low-Fidelity: Use tool Photoshop Evolutionary: -High-fidelity: Implemented on platform |
|
|
Paper Proto |
Doesn't: Need beauty Worry much about color, font etc Does: Show all important UI Intelligible by User |
|
|
"Testing" Proto |
Let UI speak for itself The user is always right in proto |
|
|
Stakeholder Review |
1. Meet stakeholders 2. Devs present their understanding of Reqs 3. Stakeholders correct understanding 4. Discuss (focus on risk mgmt) 5. Devs revise requirements |
|
|
Manual Analysis |
Systematically check consistency |
|
|
Formal Analysis |
Provable guarantee |
|
|
Order these in terms of: Good for Validation as 1 Good for Verification as 4 Paper Proto, Manual Analysis, Formal Analysis, Low and high fidelity proto |
1. Paper 2. Low/High fid 3. Manual 4. Formal |
|
|
Wk4 Architecture |
Shows piece of system and their relationships |
|
|
Component |
Self Contained piece of system, clearly defined interfaces |
|
|
Connector |
Link between components via interface |
|
|
Architectural style |
Common kind of architecture, typical |
|
|
Client-Server |
Client: Interacts with user, calls server Server: Provides services |
|
|
Peer to Peer |
User<-->Clients<-->itself |
|
|
Publish-Subscribe |
Publish: send events Subscribe: Receive certain events |
|
|
Classic Repository Blackboard Ropos |
client-server publish-subscribe |
|
|
Pipe and Filter |
Filter: Component that xforms data Pipe: Connector that passes data between filters |
|
|
Layer |
Component that provides services to the next layer, hide lower layers |
|
|
Decomposition |
Detailed view of a component |
|
|
Types of Decomposition |
Functional Data-oriented Object oriented Process-oriented Feature-oriented Event-oriented |
|
|
Functional Decomp |
Break into functions, then sub-functions |
|
|
Data-oriented Decomp |
Data structs contains part of the data |
|
|
Object Oriented |
Data Orient + Functional Decomp One class component per data function package |
|
|
You can mix and match Decompositions |
TRUE |
|
|
Event Oriented |
Break requirements into systems of events, receives and sends events components like stateful agent state notifies state notifies state |
|
|
Feature oriented |
Break req into services, then services into features Service 1, sub: feature 1-3 Service 2, sub: feature 1-3 |
|
|
Process oriented |
Break into steps, then sub-steps |
|
|
3 ways to evaluate architectural design |
1. Compare against QA quality attributes 2. Check for failure modes 3. Go through use cases Goal: identify improvement areas |
|
|
Quality Attributes |
Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability |
|
|
Maintainability |
How hard will it be to modify? |
|
|
Efficiency |
Can sys respond quickly, do a lot of work, and scale? |
|
|
Reliability |
Perform properly under most conditions |
|
|
Integrity |
Possible to get system in bad state? Security features |
|
|
Usability |
Can users complete goals with system? |
|
|
Testability |
Can you semi-auto test if system is good? |
|
|
Flexibility |
Can system adapt to unusual conditions |
|
|
Portability |
Run on different platform |
|
|
Reusability |
Can parts of code be used in new system |
|
|
Interoperability |
Can system talk to other systems (API like) |
|
|
Fault tree |
And: this and this flat half circle Or: this or this concave half circle |
|
|
All code should have a... |
purpose, concern |
|
|
Coupling |
Module involved in another module concern |
|
|
Cohesion |
Module devoted to its concern |
|
|
Levels of coupling |
Content: A mods B WORST Common: A/B read/write same data Control: A call B Stamp: A provides structured data to B Data: A provides unstructured data to B Uncoupled: best |
|
|
Advanced Coupling How to evaluate coupling |
Count the number of lines cross package boundaries Determine what worst kind is |
|
|
Levels of cohesion |
Functional/informational (best): A/B work together Communicational: A/B use same data Procedural: A execs, then B execs. vaguely related Temporal: A execs, then B execs. NOT related Logical: Either A or B exec Coincidental: (worst) |
|
|
What is the Law of Demeter? |
Don't talk to stranger's kids |
|
|
What does Sandwiching do? |
Breaks cycles into pieces |
|
|
Object oriented design tips |
Move code to where it is used, reducing inter-package coupling |
|
|
OOP use composition to: |
reuse code add features |
|
|
OOP Use inheritance to: |
add a new version of an entity |
|
|
Example of Polymorphism using an interface Printer Controller |
Print by Email Controller Print by Printer Controller Print by Web Controller |
|
|
OOP An interface is a... |
Promise: "I can do eeeet!" |
|
|
Polymorphism: |
A/B/C/D each implement interface -All make same "I can do eeet!" promise |
|
|
Suppose you want another version, Z, of some component Y. X accesses Y. You want X to access Z and Y |
Implement Z Create interface V Make Y and Z Implement V Modify X to access V only |
|
|
OOP Incremental vs Iterative |
Incremental: Make one, add more later Iterative: Make all, improve all as you go |
|
|
OOP: You want to reduce X and increase Y |
X: Coupling Y: Cohesion |
|
|
OOP Design Patterns Builder |
Big Complex object Use when instantiating an object requires filling it with lengthy configuration |
|
|
OOP Design Patterns Adapter |
Converts one interface to another by wrapping overcomes incompatibility |
|
|
OOP Design Patterns Facade |
Provides high-level interface to subsystem Use when calling subsystem requires frequent use of complex lines of code |
|
|
OOP Design Patterns Memento |
Snapshot of system / State save /Undo and redo example |
|
|
OOP Design Patterns Interpreter |
Parses and acts on instructions in certain syntax Scriptability IE business rules in Justware or something like JWXML |
|
|
OOP Design Patterns Observer |
Listen for state change Event driven Like email notifications in JW |
|
|
OOP Design Patterns Template method |
Skeleton algorithm can be used by classes to make slightly different versions with the same underpinnings -Subdivision home builder example |
|
|
OOP Design Patterns Factory Method |
Interface for creating objects, like template for objects Example: ToyCarMold, ToyDuckMold both call InjectionMold to create object |
|
|
OOP Design Patterns Strategy |
Set of algorithms that can be used interchangeably IE Modes of transportation to airport |
|
|
OOP Design Patterns Decorator |
Add new stuff to an object dynamically Wrap a gift, put in a box, wrap the box |
|
|
OOP Design Patterns Composite |
Tree-like structure of object expanded ..can contain composite within composites |
|
|
OOP Design Patterns Visitor |
this visits this, then loses control Cab company Iterate over existing data structure, TREE or GRAPH |
|
|
Purpose of Design patterns? |
ideas for organizing code in response to common problems |
|
|
Agile 4 Forms of Agile? |
Scrum XP Crystal DSDM Dynamic Systems Dev Method: Users come from all over to test stuff facilitated workshop |
|
|
Agile Agile Iterations |
Few small problems instead of one big Scrum: 1 month XP: 1-2 weeks Iterations have releases Sub-iteration. Iteration can have sub |
|
|
Agile XP Principles of XP |
Communication: talk w customer Simplicity: KISS Feedback: get user feedback often Courage: speak truth with respect |
|
|
Agile XP Role of realisim |
Be realistic about meeting needs Small increments No superheroes |
|
|
Agile XP Role of design |
Simple design Improve as needed Metaphor: Design around coherent Idea Continuous integration: check if system on track |
|
|
Agile XP Role of teamwork |
Pair Prog Test driven dev: TDD Test first, code 2nd Collective code ownership Coding standards, pick format |
|
|
Agile A user story can fit.. |
on a 3x5 notecard Name+ short desc |
|
|
Agile T/F A user story can be revised |
True, expected |
|
|
Agile User story Minimalism |
Don't add stuff the customer didnt ask for |
|
|
Agile Do what with a user story? |
Break it down now |
|
|
Agile - User Story Estimates done in... |
Units based on experience OR Do a simple Spike to estimate difficulty BE CONSERVATIVE HONEST |
|
|
Agile - User Story Release dates don't... |
slip. Functionality slips |
|
|
Agile - Acceptance tests Each user story can have... |
multiple acceptance tests |
|
|
Agile - Acceptance tests Who writes acceptance tests? |
Ideally, customer does, but devs sometimes |
|
|
Agile - Acceptance tests How often to run? |
once a week or more |
|
|
Schedule What is the critical path? |
Longest route through the activity graph |
|
|
Schedule What is Slack Time? |
latest a proj can be done minus earliest 2mon, 4 month = 2 month slack time |
|
|
Schedule Activities on the critical path always have __ slack time |
ZERO |
|
|
Schedule Gant Chart |
Diamond = milestone Arrows show dependencies 1 bar per activity |
|
|
Testing Code 2 focus points |
Functional Correctness: Does code ever do right thing Reliability QA: Does code almost always do right thing |
|
|
Testing Code Black box testing |
tester cannot see code |
|
|
Testing Code White box testing |
tester can see code |
|
|
Testing Code Stages of testing |
Unit testing Integration testing: interaction system testing: whole acceptance testing: customer/users |
|
|
Integration testing |
combines unit tested modules and tests how they interact |
|
|
System testing |
try to break the system |
|
|
acceptance testing |
meet requirements of customer user? |
|
|
regression testing |
changes may break old code |
|
|
TDD test driven dev |
new test that fails until new feature implemented implement feature test again |
|
|
TDD problems |
difficult for waterfall lots of time taken false confidence |
|
|
most effective way of finding bugs? |
Code inspection |
|
|
Refactoring YAGNI |
you arent gonna need it Only meet business needs |
|
|
Refactoring Rules of simple design |
In ORDER 1 System must communicate everything u want 2 no duplicate code 3 fewest classes 4 fewest methods |
|
|
What is Refactoring? |
Improve organization, not function |
|
|
Refactoring Bad smells |
LOOONG function method Duplicate Code Large classes |
|
|
When is refactoring allowed? |
When all your tests are passing |
|
|
COCOMO cost estimation |
Rate Programmer Ability Rate Component Difficulty Rate dev tools |
|
|
Professionalism What is PSP? |
Track personal time on projects to predict how long it takes in future |
|
|
Professionalism diff between law, moral, ethic |
law = jail moral = reputation ethic = conscience |
|
|
Professionalism speeding in LA 65 in 55 |
illegal, moral, maybe ethical |
|
|
Professionalism speeding 85 in 25 school zone |
illegal, immoral, unethical |
|
|
Professionalism IEEE code of ethics |
Act in pub interest Act in interest of client Produce quality Maintain indep judgement manage ethically protect integrity support colleagues pursue lifelong learning |
