final review
use case scope
"what", audience-friendly terminology, how use case starts/ends, sequential interactions between use case/actors, data needed/exchanged during use case, basic flow, alternative/exception flows
incrementality
add features over time
composition relationships
aggregation with existence dependency
http
all communication between user agents and origin servers, self-contained
static analysis
analyzes source code for possible defects without running code
layered architecture
application built in layers, can edit one layer instead of whole program
user interface
approximate ui
anticipation of change
awareness that software always changes, people want latest technology
usability design
based on psychology, cognitive science, aesthetics, art
assumptions
believed to be true during project life cycle, if changed project negative outcome (end-user characteristics, known technology infrastructure, resource/funding availability
ux designer
beyond programming
test cases
black-box testing, combinatorial testing, white-box models
boundary value
boundaries tend to have more errors than normal values
"potential silver bullets"
buy vs build, requirements refinement/rapid prototyping, incremental development, great designers
bugs
cannot be proven that there none (cannot reject null)
client server architecture
clients request servers, centralized data/security/access, browser -> www -> server -> memcache -> database
rigor and formality
coding standard, creates common ground for everyone
www
collection of unique resources (URL), make requests of servers for resources
essential properties of software
complexity, conformity, changeability, invisibility
software failure
complexity, conformity, progress hard to measure, "legacy" systems, "hubble psychology"
software architecture elements
components/connectors arranged into configurations
error
computed result different from correct result
peer-to-peer architecture
computers connected each other, no central source, efficient/robust
software qualities (nonfunctional requirements)
correctness, reliability, efficiency, usability, maintainability, portability, reusability, interoperability, robustness, security, scalability
other requirements
cost, documentation, manuals, tutorials, on-the-job training, miscellaneous
usage data techniques
data analytics, A/B testing, prototyping, market research used to create/prioritize/analyze/evaluate requirements
test oracle
decide if test case succeeds/fails, difficult to automate
requirements specification
defines "what", environmental requirements/constraints on software, software qualities, source of all future steps in software life cycle
glossary
definitions of terms used throughout requirements document
requirements phase
describe what not how, most costly phase, customer wants ≠ needs
functional decomposition
design process by breaking down functionality
prescriptive architecture
designed implementation
acceptance test plan
determines how each requirement is met, customer to accept delivered system if pass test
url
determines identity of machine on internet where resource is obtained
equivalence class partitioning
divide input into several classes considered equivalent, if fails/passes for one member, same for all members of class, determined by requirements specification/tester's intuition, should cover complete input domain/should not overlap
introduction
document summary/outline, audience and creators
no silver bullets by fred brooks
don't expect large improvement just through languages and tools, invest in growing great designers, accurately capture client needs with prototyping, build software in small/iterative chunks
control flow graph
entry and exit node, every line of code is another node, an paths based on branches, directional arrows
reference documents
existing processes/tools used, other similar existing software, literature
actor
external entities interacting with the system, represented by a stick figure
persona
fictional potential user to make user-centered decisions
pipe-and-filter architecture
filter components, pipe connectors, modularity, reusability, anticipation of change
testing goals
find/fix failures/faults/errors, improve confidence passes verify/validate, accurate, thorough, repeatable, systematic, reveal as many faults as possible given time period/budget, meet quality requirements for project
black-box testing (specification-based testing)
functional, specification based, "cannot see code", typical/boundary values, special cases, invalid input/combinations values
components
functionality
potential risks
future uncertain events, new methodology, new requirements, special skills/resource shortage, aggressive schedule, tight funding, security, ethicalness
alternative flow
goal achieved in another way
exception flow
goal unachieved
high cohesion low coupling
group related functionality, ungroup unrelated functionality
relational database design
grouping data and relationships between them
mistake
human action produces incorrect result, both coder and user
basic flow
ideal scenario
functional requirements
identify all concepts/functions/features/information provided to users, abstraction/characterization of properties and functions relevant to user
inspections and reviews
improve code quality/understandability, find defects, transfer knowledge, explore alternative solutions, improve development process, avoid breaking builds, increase team awareness, share code ownership, team assessment
user testing
improve designs and interfaces before showing to users
failure
incorrect result of a fault, externally visible
fault/bug
incorrect step/process/data definition
descriptive architecture
inferred from implementation
schedule
initial delivery date, acceptance period, final delivery date, prototype delivery, architecture/design/implementation/testing completion, sprint/increment completion
architecture
intellectual control, conceptual integrity, effective project communication, reusability, maintainability
connector
interaction between components
use case
interactions between actor and system, includes basic functionality/goal, precondition, flow of events, postcondition, error condition/alternative flow
user perspective
interface
engineering perspective
internal quality of software
requirements analysis techniques
interview/observe customer, create use cases/scenarios/user stories, prototype solutions, identify important objects/roles/functions/goals, perform research, construct models, data
user-oriented methods
interviews/observations of end users, personas, scenarios, storyboards, wireframes and mockups, design guidelines, heuristic evaluation, user testing
requirements document
introduction, executive summary, application context, environmental requirements, functional requirements, software qualities, other requirements, time schedule, potential risks, assumptions, future changes, glossary, reference documents
software failure causes
lack of user input/involvement, incomplete/changing/lack of discipline in requirements and specifications, lack of methodical usage of metrics, lack of resources
generality
make code versatile
model-view controller architecture
model stores data/data structures, view is what user sees, controller computes info and updates model
separation of concerns
modularity, divide and conquer, abstraction
business perspective
money
specificiation methods
natural language, diagrams, formal language, models
UML class diagram
object oriented design of code (classes) and relationships
aggregation relationships
one object contains set of other objects, transitive and assymetric
three essential ingredients of software engineering
people, processes, tools
environmental requirements
platforms (hardware, software), programming languages, standards
abstraction
presents simple interface and hides logic processes underneath
software engineering
process of constructing software, phases of development other than programming, principles/qualities of enduring value
future changes
project changes over time, structure document to easily absorb changes (define concepts once, partition separate concerns, avoid redundancy)
publish-subscribe architecture
publishers push message to connector, connector pushes to subscribers, only notifies resources you are subscribed to
waterfall method
requirements analysis, requirements specification, design, implementation, verification, maintenance must complete fully before next
recurring/fundamental principles
rigor and formality, separation of concerns, anticipation of change, generality, incrementality
storyboard
sequence of drawings, visualize user experience/interaction
flow
sequence of steps describing user-system interaction
design guidelines
set of common ui components/patterns/styles, promotes reuse and consistent user experience
software architecture
set of principal design decisions about system
executive summary
short description of product, identify main goals, key features/risks/obstacles
observations (of document)
should address fundamental principles
application context
situation of application use, identify what system affects
ziv's law
software development unpredictable, documented artifacts will never be fully understood, uncertainty inherent/inevitable in software engineering processes/products
configuration
specific arrangement of components and connectors
white-box testing
structural, code based, "can see code", statement/node coverage, branch/edge coverage, condition/method/method-call/path coverage
architectural erosion
system (descriptive architecture) evolves and prescriptive architecture not updated
combinatorial testing
treat each parameter as equivalence class partitioning, determine partitions/representative/boundary values, devise combinations for values of each parameter
levels of testing
unit testing, functional/integration testing, system/acceptance testing
heuristic evaluation
using principles based on research to access usability of system
quality assurance
verify (conform to specification) and validate (serve purpose), formal methods, static analysis of program properties, reviews and inspections, testing
nielsen heuristic evaluation
visibility of system status, match system words to real world, user control/freedom, consistency/standards, error prevention, recognition over recall, accelerators, minimalist design, help users recognize/recover from errors, help/documentation
most common software engineering job in the us
writing company software within company
