est

Think of a system as a function and break it down into smaller, simpler functions. Then, rebuild these small functions to build system.

Use tables to store data and illustrate relationships between them. Most common type of database.

Each module turns into a class that has a name, attributes, and functions.

A drawing of an interface for testing and feedback.

A fundamental 43 principle. Removes irrelevant info and highlights relevant info. Software engineering is about constructing and elaborating abstractions / models.

Illustrate user interaction. A series of pictures that shows context of use, often with emotion. It refines requirements and interactions pre-build.

A mix of notations, formal or informal

Represent some aspect of a software system, and this is what software engineering is about.

Grouping related functionality. All things having to do with one concern are in one place.

Modules aren't tightly knit together.

Putting a variation of a feature in front of users and collect data on user's responses; see what they like best.

A fictional user of your system. Must have a picture, nickname, actual name, and characteristics that are relevant to the system.

Write a story-like description of a user using the system.

Shows what elements lead to what screens. Draw one with a given number of screens.

Draw a picture of picture of what the user interface will look like.

Include color schemes, wire frames. All for reuse, consistency, and to incorporate well-known heuristics.

Like guidelines, more focused on common usability problems. Things like how to navigate, search, display data.

Check that a system or any artifact match what the user's needs are. "Implement the proper idea."

Check that the eventual system behaves according to the specifications. "Implement the idea properly."

Human mistake in programmer's mind.

Discrepancy in code.

External behavior, execution, output is incorrect.

Test a small unit / file / section. Lots of these are used.

Testing interaction between units of a system. Less of these are used.

Testing the entire system for satisfaction of requirements. Used sparingly

Says what a program's expected output should be to know if we fail or succeed (can be a calculator, dictionary, brain, etc.)

We can't prove 100% correctness since we can't test every possible input. We can't prove anything about inputs we didn't run.

Fixed period of time, have quality requirements (98% bug free), rate of problems per unit time stabilizes, formula where fake bugs are inserted.

Based on specification, assumes no access to code.

Expects access to code, a graph model is used.

Takes all the inputs of a function and divide them into a subdomain / equivalence class.

Testing inputs that are at the boundaries of subdomains (partitions)

Every statement executed at least once

Every branch taken at least once

Char: Simple, leaves out all activities.
Pros: good for small programs
Cons: not rigorous enough for non-trivial projects

Char: linear, sequential, one drops to next, have to finish one before moving on, lots of documentation.
Pros: Lots of documentation, promotes understanding of requirements. Good for short projects.
Cons: Rigid, not amenable to change. Can't incorporate customer feedback.

Incorporates more user feedback

More of a customer feedback loop to waterfall. Iterate over small pieces and get customer feedback (Windows 10)

Char: Wants more flexibility to waterfall. What happens in each step is based off risk analysis. It's iterative and variable. Every process is different
Pros: good when things are uncertain
Cons: you need to do / understand risk analysis

Char: use case driven, architecture centric, iterative and incremental
Pros: Risk driven, incremental, lots of tool support
Cons: Complicated, heavy, requires an expert to implement.

Char: devs are volunteers, rarely meet. Starts with one person, others come to build. Many devs work on projects. More evolutionary; no deadlines
Cons: not proprietary, bad technical support and compensation is iffy.
Pros: very successful. Bugs are easily found by many eyes. Scales up well

Companies using open source software, sponsoring projects, open sourcing their own code.

Uses test driven development and pair programming.
Determine desired features, implement / deliver each task, follow values & principles.

Char: Category of XP, scrum. Very anti-waterfall; instead of having a plan, it's about responding to changes at any time. Very popular.
Cons: won't work in certain conditions.
Pros: great for customer satisfaction.

Complexity of hardware doubles every two years, so we can write more complex software

Project factors -> estimation method -> project estimates

Designs to think, talk and prescribe. Designs are developed iteratively.

Inheritance, association (multiplicity), whole part (aggregation and composition).

Student takes from teacher
Router accesses DNS

One object contains a set of other objects. They are transitive and asymmetric. I.e. bottle -> crate

A variation of aggregation that adds the property of existence dependence. I.e. room -> house

Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed.

Programmers, testers, users (alpha / beta, acceptance testing, crowdsourcing/ bug bounties).

1. Identify set of all inputs
2. Identify a base for subdividing the set of inputs
3. Use this basis to divide set of all inputs into subdomains.
4. From each subdomain, choose representatives to be test case inputs.

Whole team
Small releases
Customer tests
Simple design
Pair programming
Test-driven development
Coding standards
Open space

Visibility of system status
Match system words to real world
User control & freedom
Consistency & standards
Error prevention
Recognition rather than recall
Accelerators
Minimalistic design
Help users recognize & recover from errors
Help & documentation

Requirements
Application domain experience
Process quality
Project size
Technology support
Working environment

Effort (person months)
Duration (calendar months)
Cost (dollars)
KLOC (thousands of lines of code)

COCOMO
Function point estimation
Object oriented effort estimation
Work breakdown structure

Difficult, requires a lot of experience and intelligence. May require data that doesn't exist, design to be done, and updates.