In4matx 43
Programming-Centric Model
Problem Statement -> Code -> Compile -> Unit Test -> Release; Known as code and fix model; served many early projects well.
What factors affect productivity rates?
1. Application domain experience 2. Process quality 3. Project size 4. Technology support 5. Working environment
Architectural Styles and Patterns
1. Collections of decisions that work well together 2. Named, commonly used sets of components and connections
Layered Architecture
1. Components organized in layers 2. Components in one layer make procedure calls to layer below and are independent of components in same layer
Testing Process Model
1. Decide what to test 2. select a test case input 3. determine the expected output E 4. run the system w/ the test case input 5. capture actual output of A 6. compare E and A - Different? Inform programmer 7. Loop back to 1 and 2, if time permits
Benefits of Model/View/Controller
1. Decouples model and view 2. Decouples view and controller
More about ECP
1. ECP is based on dividing input into classes that are deemed equivalent for the purpose of finding errors 2. ECP is based on looking for the best collection of test cases 3. If a program fails for one member of an EC, the entire EC is expected to fail. The converse is true as well.
Types of bugs
1. Error (in mind of programmer) 2. Fault/defect (in code) 3. Failure (in execution or output)
What are some ways to modularize a software project?
1. Functional decomposition 2. Relational database design 3. Object-Oriented design and UML 4. User-interface design
What is/are some characteristics of Architectural Design?
1. High level overview of system 2. System structure 3. Principal design decisions of a system 4. The skeleton of a system
Steps for Equivalence Class Partioning
1. Identify set of all possible inputs 2. Identify basis for subdividing set of inputs 3. Use basis to divide all inputs into subsets 4. Select a representative test case from each subset/domain
Agile Manifesto
1. Individual and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan
What tasks are performed during design?
1. Modularize the task so multiple people can work on it 2. Make system-wide decisions 3. Develop specs in more detail
Three more Architectural styles
1. Pipe and filters 2. Event driven 3. Database centric
How to estimate a project
1. Take the best guess 2. Estimate by parts 3. Re-estimate as project progresses and uncertainty decreases
Characteristics of Black Box testing
1. Test cases based on specs 2. Require formal specs 3. Thoroughness measured against set of functionality and set of inputs
Characteristics of White Box testing
1. Test cases based on structure of code 2. Can be partially automated 3. Thoroughness measured against code qualities
How can we ensure software correctness?
1. Testing 2. Inspection and reviews 3. Proofs, formal methods 4. Static analysis
What are some challenges of testing?
1. Testing cannot show absence of bugs, only their presence. 2. Too many input-output pairs to test them all
What are two purposes of software dev languages?
1. To communicate w/ others 2. To clarify one's own thinking
Types of testing
1. Unit/component 2. Integration (system when testing entire system) 3. Acceptance 4. Volume/stress 5. Regression
Model View Controller Architecture
1. View components present info to user 2. Models store info and hold business rules 3. Controllers tell view and models to update
What knowledge is necessary before making architectural decisions?
1. What the software is supposed to do 2. Who will be using it 3. Any system constraints
Testing Oracles
A mechanism for deciding whether a test case succeeded or failed
Inspections and Reviews
A process in which humans read documents to find defects. Many different approaches, and is surprisingly effective
Client-Server Architecture
A server computer (or process) has computational or memory resources that it provides to one or more client computers (or processes), typically over a network
UML
A set of a dozen or so visual languages used for expressing various aspects of software development
Brooke's Law
Adding manpower to a late software project makes it later.
Benefits of Agile
Avoids: 1. Lengthy dev times 2. Inability to respond to change 3. Complex methodology 4. Waste/duplication of effort
Chief Programmer Team Model
Chief programmer plans, divides, and assigns pieces of problem to specialists/teams.
Types of UML Diagrams
Class, sequence, use case, activity...
Essence of Software
Complexity: "The hard part of building software is the specification, design, and testing of the conceptual construct--not the programming and testing of the code."
Risks and Danger of Software Development
Complexity: as breadth increases, depth increases; Effort estimation and schedule: completion estimates are usually naive and over ambitious; Assignment and communication: communication paths increase non-linearly as individuals are added to a project;
Properties of Software
Complexity; Conformity; Changeability; Invisibility.
Static Analysis
Computer analyzes source code to find defects; accuracy is an issue
Spiral Model
Determine objectives -> Identify and resolve risks -> Develop and test -> Plan next iteration. Goes through spiral several times.
How are diagrams different than pictures?
Diagrams can be statements in languages w/ syntax Diagrams are interpreted
Wasserman's Principles of Software Engineering
Divide and conquer, modularity, separation of concerns, abstraction.
Verification
Doing the product right: making sure product conforms to specs
Validation
Doing the right product: making sure software meets the users' needs
What is being estimated in a project estimate?
Effort, duration, cost, lines of code
Requirements Process
Elicitation -> Analysis -> (Definition -> Prototyping -> Review) -> Specification -> Agreement
Design Constraints
External factors that must be considered when implementing a system.
Prototype
First or early model that serves the purpose of helping understand requirements.
Functional Requirements
Input-Output mapping. What the software should be able to do (explicitly).
Extreme Programming
Make frequent, small releases; give team dedicated workspace; refactor when/wherever possible; pair programming; unit tests
Davis' Principles of Software Engineering
Make quality #1 Give products to customers early Use an appropriate process model Get it right before you make it faster Good management is more important than good tech
Boehm's Top Risks
Personnel shortfalls; unrealistic schedules and budget; developing wrong functions; shortfalls in externally furnished components; shortfall in externally performed tasks.
Formal Methods
Proof of correctness; usually performed w/ formal specs
Nonfunctional Requirements
Qualities, how the software is to perform; measured on a linear scale; can sometimes overlap with design constraints.
Characteristics of XP
Rapid, fine feedback Simplicity Incremental change Embracing change Quality work
Prototyping Software Model
Requirement -> Quick Design -> Build Prototype -> Customer eval of prototype - > to 1) Requirements or 2) (after acceptance) design -> implement -> test -> maintain.
Waterfall Model
Requirements -> Design -> Implementation -> Verification -> Maintenance; Linear and ideal, tasks occur sequentially; oldest publicized model; also known as document driven approach.
Characteristics of Spiral Model
Risk driven, focus on considering alternatives; each loop through cycle identifies and resolves risk in sub-problem; not all devs on same stage; review is integral; reduces risk.
Incremental Software Process Model
Several waterfall models feed into an integration bucket. Components are dev. overlapping fashion; components integrated and tested as system; provides certain amount of risk containment.
Agile Software Development
Short releases and iterations; incremental design; user involvement; minimal documentation; informal communication; change
Models
Simplified representations of software dev. processes. Can be thought of as prescriptive (enforcing rules) or descriptive (describing or characterizing).
Open Source
Source code is freely available; many contributors work in distributed manner; heavy reliance on software tools; scales very well. Similar in some ways to Agile.
Quote by Edsger Dijkstra
Testing can show the presence of bugs, but not their absence
Software Engineering
The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works on real machines. Phases of software development other than programming.
Parnas' Definition of Software Engineering
The multi-person development of multi-version software.
How to select Black Box test cases
Typical values, boundary values, extreme values, special cases, invalid values, environmental factors
When does testing stop?
When confidence gained from additional testing is no longer worth additional resources necessary to test