SENG 301 Cheat Sheet by brownie5

Title = Should be a verb descri­ption (Ex. View a product location)
Goal = "As a {type of user}, I want to {perform some action} so that I can {achieve some goal}"

Story Maps add narrative structure to a backlog
-Top Level: Main features. Also know as a project backbone
-Second Level: important tasks or related stories. Also known as a walking skeleton.
-Addit­ional tasks are added to flesh out intera­ctions

Types of Protot­ypes:
Throwaway = Example is a paper one. Will be used only for evalua­tion; Increm­ental = created a separate compon­ents; Evolut­ionary = refined to become actual product
Prototype Fidelity:
Low = Omit details (Rough, no code, easy to trash) - Paper, Storyb­oard, Wizard of OZ (evalu­ation) High = Looks like a polished product (looks of product, comment on aesthe­tics, GUI powerpoint etc are used)
Protot­yping can help answer:
- Crowded UI, Knobs versu slider for contro­lling volume, Navigation = Transp­arent or solid menu?

White = AKA glass box, struct­ural; Tester know the source code and can debug at runtime = Develo­per's perspe­ctive
Unit Testing = Do discrete parts of my system work as expected?
- Does an individual method work as expected?
- Necessary calls to other methods should be mocked out where possible
-Always white box
Black = Tester gives inputs and observe outputs (No code, only focus on reqs., interacts with UI only) = User's perspe­ctive
Acceptance Testing = Is the system working from the customer's perspe­­ctive? (AKA. System testing)
- Interacts with system through GUI
- Focused in feature
Usually black box

TDD = focused on how code gets written (for work cycles of indivi­duals or small groups of developers exclus­ively)
Agile = Overall develo­pment process (focuses on project management and groups of develo­pers, as opposed to specif­ically how a given developer writes code)

A property of OO software by which an abstract operation may be performed in different ways, typically in different classes.

Implicit possession by a subclass of features defined in a subclass. Features include variables and methods

Start by sketching an outline:
- Based on the principal reqs. and use cases
- Determine the main components that will be needed
- Chose among the various archit­ectural patterns
- Sugges­tion: Have several teams indepe­ndently develop a first draft of the archi. and merge together the best ideas.
Refine the archit­ecture:
- Identify the mains ways in which the components will interact and the interfaces between them
- Decide how each piece of data and functi­onality will be distri­buted among the various components
- Determine if you can re-use an existing framework, if you can build a framework.
*Mature the archit­ecture
- All UML diagrams = useful for describing aspects of the archi. model

Do various parts of the system work together?
- Do subsys­tem­s/c­las­ses­/me­thods work as expected with other subsys­tem­s/c­las­ses­/me­thods in the system?
-Do parts of my system work with external depend­encies? (database, web services)
-Usually white box

Has neither instance variables nor concrete methods.
It is a named list of abstract operations
Every single method declared in an Interface will have to be implem­ented in the subclass

Planning = Process of deciding: What activities will be performed, when activities should be starte­d/c­omp­leted.
Project Planning = Scope of system as a whole, what order features will be done
Iteration Planning: Which features will be included in the next delive­rable?
Parts of Planning
Which features are most valuable or risky?
Which features will make it into the project or iteration?
How much effort will each feature take?
Does a given feature depend on other features?
Based on all this: in which order will features be implem­ented?
Generally the high priority tasks should be picked first for an iteration

Process of determ­ining: when and what tasks got completed.

Tracking + planning = extent to which a project in on schedu­le/cost can be monitored.

- In Java, a class only derive from one other class = no multiple inheri­tance in Java (inherit only one abstract class)
- But a class can implement multiple interf­aces.
- Abstract classes = meant for inheri­tance to form a strong relati­onship between two classes. Can have some implem­ent­ation code.
- Interface = no method defini­tio­n/only method headings
When to use?
Abstract = Inheri­tance (Gives a base class), having non-public members, to add new methods later on
Interface = The API will not change for a while, similar to multiple inheri­tance, has all public members

Design = problem solving process to find and describe a way:
- to implement the system's functional reqs.
- respect the constr­aints imposed by non-fu­nct­ional reqs. (budget, deadli­nes..)
- adhere to general principles of good quality
Design Issues = sub problems of the overall design. Each issue has several altern­ative solutions. The designer makes a design decision to resolve each issue. This involves choosing what he or she consider to be the best option from among the altern­atives.
Good design = increasing profit with reduced cost, ensure confor­mation to the reqs., accele­rating develo­pment, increasing usability, effici­ency, reliab­ility, mainta­ina­bility and reusab­ility