SUBJECTS
|
BROWSE
|
CAREER CENTER
|
POPULAR
|
JOIN
|
LOGIN
Business Skills
|
Soft Skills
|
Basic Literacy
|
Certifications
About
|
Help
|
Privacy
|
Terms
|
Email
Search
Test your basic knowledge |
Software Engineering Vocab
Start Test
Study First
Subjects
:
engineering
,
it-skills
Instructions:
Answer 50 questions in 15 minutes.
If you are not ready to take this test, you can
study here
.
Match each statement with the correct term.
Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.
This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. Testing the whole system for functionality
a refactoring
Association
system testing
Law of demeter
2. 1. A language feature that supports prototype- based programming. 2. Originally: One object relying upon another to provide a specified set of functionalities. 3. In .NET: A way of telling which method to call when an event is triggered
Feasibility
software quality
Programming style
Delegation
3. Reusable - abstract 'blocks' of design
patent
Design pattern
Stress testing
Lambda
4. Testing where modules are combined and tested as a group
Integration testing
long parameter list
conflict
Lazy initialization or Lazy loading (Design pattern)
5. Web Services Description Language. Used to create the XML document that describes the tasks performed by various web services.
WSDL
Elicitation
Maturity
Denormalization
6. An effective method expressed as a finite list of well- defined instructions for solving a problem.
REST
Algorithm
Stress testing
sequence diagram
7. JQuery is a lightweight JavaScript library that emphasizes interaction between JavaScript and HTML.
jquery
Data classes
middle man
Scrum (Agile software development)
8. How developed code is (testing - documentation etc)
Data classes
Usability testing
Maturity level
Requirements
9. An operator used to denote anonymous functions or closures.
Algorithm
Lambda
unit testing
copyright
10. Contract between inventor - assignee and state giving a time and geographically limited monopoly
patent
Phase
Design
Security testing
11. Approach to team management that splits management up into two people with separate tasks
Association
a refactoring
Programming style
technical managerial approach
12. (smell) A class whose only purpose is to hold data
Specification
Data classes
data clumps
Non - functional Requirements
13. The process of attempting to optimise the read performance of a database by adding redundant data or by grouping data
Elicitation
Denormalization
Design pattern
path
14. (smell) method has too many statements - loops or variables
a refactoring
data clumps
Quality metrics
long method
15. AKA: Function Constant or Function Literal A function defined - and possibly called - without being bound to an identifier.
Anonymous function
Capacity testing
Maturity
Fully- dressed use case
16. A method that initializes a newly instantiated object
software quality
Analysis...
Constructor
Cowboy coding
17. Single step in a lifecycle
Maturity level
Specification
Non - functional Requirements
Phase
18. Delaying the creation of an object - calculation of a value or another expensive process until first needed.
Security testing
Lazy initialization or Lazy loading (Design pattern)
long parameter list
Lexer
19. A set of rules that define the combinations of symbols that are considered to be correctly structured in a specific programming language. Example: In many programming languages - statements are terminated by a semicolon.
Maturity level
OOP
Programming syntax
Lifecycle
20. Comprehensive description of software's intended purpose
Constructor
WSDL
SRS Documentation
Semantic Web
21. Description of possible sequences of interactions between a user and the system.
Lazy initialization or Lazy loading (Design pattern)
architectural design
use case
patent
22. Executes system in a manner that demands abnormal amounts of resources
Specification
Stress testing
data clumps
Functional Requirements
23. Degree to which the system meets the specified requirements and development standards
path
Erich Gamma - Richard Helm - Ralph Johnson - John Vlissides
software quality
Elicitation
24. A guess of the ability to complete a task or solve a problem. Typically the possible benefits and risks are considered. Some factors would be benefit of completion - risks of incompletion and costs to approach completion.
patent
Feasibility
message chain
Closure
25. Testing tactic based on whether inputs and outputs match up for required functionality
Non - functional Requirements
black box testing
data clumps
duplicated code
26. Each line of code is covered once
statement
Delegation
Dijkstra's law
Lazy initialization or Lazy loading (Design pattern)
27. (smell) Making one change requires changes in multiple places
Dijkstra's law
shotgun surgery
REST
code quality
28. Testing tactic that looks at all ways that data can flow through the code
comments
white box testing
black box testing
feature- driven development
29. Figuring out what the requirements are
software quality
Integration testing
Denormalization
Elicitation
30. The rights governing the ownership and disposition of technology
Lambda
Non - functional Requirements
intellectual property
Stakeholders
31. Each team member given set of features to work on
Anonymous function
architectural design
feature- driven development
Feasibility
32. Series of phases through which software is developed
patent
Stress testing
Lifecycle
Usability testing
33. Ways to express the system's subsystems and their relationship
Maturity level
Constructor
Large class
architectural design
34. 'single dot rule'
Casual use case
system testing
Law of demeter
path
35. The rigorousness of the tests that are able to be placed on the code
Maturity
Software Quality
Programming syntax
brief use case
36. Diagram used to show how information flows around the system
sequence diagram
Closure
Scrum (Agile software development)
Refactoring
37. (smell) Smell deodorant
statement
Test- driven development
comments
Design pattern
38. The process of eliminating data redundancy by ensuring that tables in a database pertain to a single topic
Database normalization
path
Maturity level
comments
39. A subjective set of rules or guidelines used when writing source code. Example: The use of whitespace to consistently group and space out statements.
Denormalization
Programming style
Programming syntax
Data classes
40. Tasks that a system must be able to perform
Stakeholders
OOP
Stress testing
Functional Requirements
41. (smell) client needs to use one object to get another and then use that one to get another
message chain
Database normalization
Stress testing
Quality metrics
42. Reusable - abstract 'blocks' of design
Design Patterns
a refactoring
Lexer
Fully- dressed use case
43. (smell)class with too many instance variables or too much code
technical managerial approach
Scrum (Agile software development)
Large class
Closure
44. A relationship between objects.
Association
Use case diagram
Maturity level
Cowboy coding
45. Freezing the state of the source code at a particular point
Versioning
Phase
Refactoring
use case
46. Each possible path through the code is covered
path
Constructor
Design Patterns
model- driven development
47. Part of compiler reads the sequence of characters and outputs a sequence of lexemes.
Validation
Phase
Lexer
Recovery testing
48. Recognizable indicator that something may be wrong with code
Versioning
brief use case
comments
code smell
49. Derived methods should not assume more or deliver less
Liskov substitution principle
SOAP
data clumps
Validation
50. Constraints on the design due to external factors
Non - functional Requirements
statement
code quality
Database normalization