Computer Science 310: Software Engineering
My Set for the CPSC 310 class at UBC
Terms
undefined, object
copy deck
- Elicitation
- Figuring out what the requirements are
- Dijkstra's law
- Testing can show the presence but not absence of errors
- Requirements
- The things a system must do
- path
- Each possible path through the code is covered
- Quality metrics
- a way to automatically grade code based on heuristics
- Design patterns
- Techniques for composing objects to form larger structures
- Law of demeter
- "single dot rule"
- middle man
- (smell) One class delegates all of its requests to another class
- statement
- Each line of code is covered once
- comments
- (smell) Smell deodorant
- regression testing
- Testing designed to uncover regressions (where stuff that used to work doesn't work anymore)
- Design pattern
- Reusable, abstract "blocks" of design
- Large class
- (smell)class with too many instance variables or too much code
- Security testing
- verifies that system is protected against improper penetration
- technical managerial approach
- approach to team management that splits management up into two people with separate tasks
- use case
- description of possible sequences of interactions between a user and the system.
- Elicitation
- 1st step of requirements gathering
- software quality
- degree to which the system meets the specified requirements and development standards
- Maturity level
- how developed code is (testing, documentation etc)
- a refactoring
- small, behaviour-preserving, source-to-source transformation
- copyright
- protecting the embodiment of an idea
- Recovery testing
- Force software to fail in order to see how it recovers
- Non-functional Requirements
- Constraints on the design due to external factors
- Versioning
- Freezing the state of the source code at a particular point
- architectural design
- Ways to express the system's subsystems and their relationship
- brief use case
- A few sentences summarizing a use case
- white box testing
- Testing tactic that looks at all ways that data can flow through the code
- inappropriate intimacy
- (smell) Classes using things that should be private in other classes
- intellectual property
- the rights governing the ownership and disposition of technology
- system testing
- testing the whole system for functionality
- Use case diagram
- Diagram outlining the tasks that are going to be performed by the user
- code smell
- recognizable indicator that something may be wrong with code
- Maturity
- The rigorousness of the tests that are able to be placed on the code
- Stress testing
- executes system in a manner that demands abnormal amounts of resources
- shotgun surgery
- (smell) Making one change requires changes in multiple places
- Analysis
- 2nd step of requirements gathering
- Cowboy coding
- Absence of lifecycle
- Capacity testing
- Evaluates upper limits of operational parameters
- Test-driven development
- Test cases made -> code compiles -> make code pass
- Code Quality
- Lack of errors in code, readability etc
- data clumps
- (smell) If a set of variables are used together in multiple places
- Liskov substitution principle
- derived methods should not assume more or deliver less
- model-driven development
- models->code work is done to keep models in sync with code
- black box testing
- Testing tactic based on whether inputs and outputs match up for required functionality
- Performance testing
- Test the run-time performance of the system
- trademark
- word, logo or symbol used to distinguish one organization's wares and services from another's
- SRS Documentation
- Comprehensive description of software's intended purpose
- conflict
- a powerful motivator for change
- Acceptance testing
- Formal testing against end user specifications
- Stakeholders
- People who care about the outcome
- unit testing
- Testing that verifies that individual units of source code are working
- message chain
- (smell) client needs to use one object to get another and then use that one to get another
- Data classes
- (smell) A class whose only purpose is to hold data
- Phase
- Single step in a lifecycle
- duplicated code
- (smell) code is repeated in multiple places
- sequence diagram
- Diagram used to show how information flows around the system
- Usability testing
- Test whether or not tasks can be accomplished efficiently by all levels of users
- feature-driven development
- each team member given set of features to work on
- Software Quality
- how well your fulfil your requirements
- Lifecycle
- series of phases through which software is developed
- Specification
- 3rd step of requirements gathering
- Design
- Developing a plan for a product, system or component. "how" a system should perform a task
- feature envy
- (smell) A method using another class more than its own
- branch
- Each condition is covered twice (true, false)
- Functional Requirements
- Tasks that a system must be able to perform
- long method
- (smell) method has too many statements, loops or variables
- Casual use case
- One or two paragraphs of text outlining a use case
- Validation
- 4th step of requirements gathering
- Fully-dressed use case
- Formal document outlining a task that needs to be performed on a system
- code quality
- the degree to which code is free of defects
- patent
- contract between inventor, assignee and state giving a time and geographically limited monopoly
- long parameter list
- (smell) many parameters are being passed into a method
- Integration testing
- Testing where modules are combined and tested as a group