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;
15 Cards in this Set
- Front
- Back
|
Inspection Roles |
Moderator (not PM, rotates) Author (not code author) Reader Recorder Inspector mnemonic: MARRI |
|
|
Use Cases vs Design Use Cases |
Design Use Cases focused on workflow / "information essential for implementation" |
|
|
Aspect Oriented Software Development |
Code that spans/touches all aspects of the project ex: error handling |
|
|
Test Driven Development: Workflow |
Define functionality with a failing test Write code to pass test Refactor |
|
|
Test Driven Development: Why do you write code? |
To pass tests |
|
|
Test Driven Development: Name 2 pros |
o More tests are written o Programmers tended to be more productive o Less need for debuggers o Drives design via tests focusing on customer interaction with system User interface is considered before system implementation o Limits defects in code shortening implementation time o Resultant code is modularized, flexible and extensible o Automated tests cover every code path |
|
|
Test Driven Development: Name 2 cons |
o Difficult to use when functional tests determine success/failure of system User interfaces Database backends Network configurations o Not all managers are believers o Tests must be maintained as part of project overhead o Refactoring or design changes may result in many changes to tests Deleting such tests leaves system open to gaps in test coverage o Developer and test author are same leading to same blind spots o High numbers of passing tests may lead to false sense of security |
|
|
What are functional requirements? |
a function that a user wants. "The system shall..." not implementation detail |
|
|
Shall vs Will |
Shall = requirements Will = purpose Shall is usually used to state a device or system's requirements. For example: "The selected generator shallprovide a minimum of 80 Kilowatts." Will is generally used to state a device or system's purpose. For example, "The new generator will be usedto power the operations tent." |
|
|
Separation of concerns: Synonyms |
Modular programming, Layering |
|
|
Separation of concerns: Implementation |
Split code into reusable encapsulated sections |
|
|
MVC definition |
Model: data, business rules View: presentation of data Controller: The interaction between the two. |
|
|
Pair Programming: Roles |
Driver, Observer/Navigator Roles switch frequently |
|
|
Pair Programming: 2 pros |
Pros: o Produce shorter programs with better designs and fewer bugs o Reduction in defect rates o More design alternatives are consideredo Catch design defects early o Arrive at more maintainable designso Complete work faster o Difficult problems are easier when working together o Best suited for tasks with more challenge and sophistication o Knowledge passes between pair as they work Skills gained New hires brought up to speed more quickly Promiscuous pairing results in team knowledge speed o Improved discipline Less skipped tests or cut corners Less time in email Less interruptions by others o Increased morals and greater confidence in code correctness |
|
|
Pair Programming: 2 cons |
Cons: o Total programmer time increases o For simple tasks, net drop in productivity |
