Level 147 Level 149
Level 148

Software Engineering II


70 words 0 ignored

Ready to learn       Ready to review

Ignore words

Check the boxes below to ignore/unignore words, then click save at the bottom. Ignored words will never appear in any learning session.

All None

Ignore?
Lifecycle
series of phases through which software is developed
Phase
Single step in a lifecycle
Cowboy coding
Absence of lifecycle
Requirements
__________ include identifying what is to be produced, how frequently and how fast it is to be produced.
functional requirements
Specific features and functions that a proposed IT system must have.
non-functional requirements
Conditions that a proposed IT system must meet, such as working on certain hardware or giving results within a certain time.
Elicitation
1st step of requirements gathering
Design
A stage of SDP that involves the planning of a solution to the problem
Design pattern
Reusable, abstract "blocks" of design
Stakeholders
People who care about the outcome
SRS Documentation
Comprehensive description of software's intended purpose
use case
description of possible sequences of interactions between a user and the system.
architectural design
Ways to express the system's subsystems and their relationship
Dijkstra's law
Testing can show the presence but not absence of errors
unit testing
Testing that verifies that individual units of source code are working
Integration testing
Testing where modules are combined and tested as a group
regression testing
Testing designed to uncover regressions (where stuff that used to work doesn't work anymore)
system testing
testing the whole system for functionality
Acceptance testing
Formal testing against end user specifications
Recovery testing
Force software to fail in order to see how it recovers
Security testing
verifies that system is protected against improper penetration
Stress testing
executes system in a manner that demands abnormal amounts of resources
Capacity testing
Evaluates upper limits of operational parameters
Usability testing
Test whether or not tasks can be accomplished efficiently by all levels of users
Performance testing
Test the run-time performance of the system
black box testing
Testing tactic based on whether inputs and outputs match up for required functionality
white box testing
Testing tactic that looks at all ways that data can flow through the code
Design Patterns
A general reusable solution to a common problem within a given context in software design.
Maturity level
how developed code is (testing, documentation etc)
software quality
degree to which the system meets the specified requirements and development standards
Code Quality
Lack of errors in code, readability etc
a refactoring
small, behaviour-preserving, source-to-source transformation
Analysis
2nd step of requirements gathering
Specification
3rd step of requirements gathering
Validation
4th step of requirements gathering
brief use case
A few sentences summarizing a use case
Casual use case
One or two paragraphs of text outlining a use case
Fully-dressed use case
Formal document outlining a task that needs to be performed on a system
Use Case Diagram
a set of scenarios that describes an interaction between a user and a system.
conflict
a powerful motivator for change
technical managerial approach
approach to team management that splits management up into two people with separate tasks
Sequence Diagram
Diagram showing the sequence of messages between objects during a single use case
Law of Demeter
Design guideline that states that a method should not operate on global objects or objects that are a part of another object.
Liskov substitution principle
derived methods should not assume more or deliver less
Test-driven development
Test cases made -> code compiles -> make code pass
model-driven development
models->code work is done to keep models in sync with code
feature-driven development
each team member given set of features to work on
Versioning
Freezing the state of the source code at a particular point
Maturity
The rigorousness of the tests that are able to be placed on the code
Quality metrics
a way to automatically grade code based on heuristics
code smell
recognizable indicator that something may be wrong with code
duplicated code
code is repeated in multiple places
long method
method has too many statements, loops or variables
Large class
class with too many instance variables or too much code
long parameter list
many parameters are being passed into a method
comments
Smell deodorant
message chain
client needs to use one object to get another and then use that one to get another
data clumps
If a set of variables are used together in multiple places
feature envy
A method using another class more than its own
shotgun surgery
Making one change requires changes in multiple places
inappropriate intimacy
Classes using things that should be private in other classes
Data classes
A class whose only purpose is to hold data
middle man
One class delegates all of its requests to another class
intellectual property
anything produced by the creative process of the human mind
patent
contract between inventor, assignee and state giving a time and geographically limited monopoly
copyright
protecting the embodiment of an idea
trademark
what is a word, phrase, symbol, or design that identifies goods or services
Statement
A syntactical unit in a program
branch
Each condition is covered twice (true, false)
path
A drive and list of directories pointing to a file such as C:\Windows\command.