Glossary - I
Incremental
The implementation of a system in a piece-by-piece fashion. Differs from a big-bang
approach in that implementation is in parts allowing a transition from old to new.
Kernel
The part of software product that does the internal processing. Usually this part has
no interaction with the outside world but relies on other `parts' like the API and UI.
Milestone
A significant point in a project schedule which denotes the delivery of a significant
portion of the project. Normally associated with a particular "deliverable".
MTTF
Mean Time To Failure the mean time between errors. Used in engineering to
measure the reliability of a product. Not useful for predicting individual failures.
Open Source
A development philosophy which promotes the distribution of source code to
enhance functionality through the contributions of many independent developers.
Prototype
A model of software which is used to resolve a design decision in the project.
QA
Quality Assurance the process of preventing defects from entering software through
'best practices'. Not be confused with testing!
Release Candidate
The first version of the software considered fit to be released (pre final testing).
Requirement
A statement of need from a stake-holder identifying a desire to be fulfilled
ROI
"Return On Investment" a ratio which compares the monetary outlay for a project
to the monetary benefit. Typically used to show success of a project.
RUP
Rational Unified Process a software development methodology focussed on object-
oriented development. Developed by the big three at IBM-Rational Corporation.
Scope creep
The relentless tendency of a project to self-inflate and take on more features or
functionality than was originally intended. Also known as `feature creep'.
Shrink wrapped
Software that is designed to be sold "off-the-shelf" and not customised for one user
SLA
Service Level Agreement an agreement between two parties as to the minimum
acceptable level of service a piece of software or a process must provide
Show Stopper
A defect that is so serious it literally stops everything. Normally given priority
attention until it is resolved. Also known as "critical" issues.
Static analysis
White Box testing techniques which rely on analysing the uncompiled, static source
code. Usually involves manual and automated code inspection.
Stakeholder
A representative from the client business or end-user base who has a vested interest
in the success of the project and its design
Testing
The process of critically evaluating software to find flaws and fix them and to
determine its current state of readiness for release
Top Down
Building or designing software by constructing a high level structure and then filling in
gaps in that structure. See "Bottom Up" for contrast
UAT
User Acceptance Test(ing) using typical end-users in Acceptance Testing (qv). Often a
test as to whether a client will accept or reject a 'release candidate' and pay up.
Usability
The intrinsic quality of a piece of software which makes users like it. Often described
as the quality present in software which does not annoy the user.
Usability Testing
User centric testing method used to evaluate design decisions in software by observing
typical user reactions to prototype design elements
User Interface
The top 10% of the iceberg. The bit of software that a user actually sees. See CLI and
GUI, different from the Kernel or API.
Verification
The process of checking that software does what it was intended to do as per its
design. See "Validation". Sometimes posited as "are we making the product right?"
Validation
Checking that the design of a software system or product matches the expectations of
users. See "Verification". Sometimes posited as : "are we making the right product?"
White Box Testing
Testing the program with knowledge and understanding of the source code. Usually
performed by programmers, see Black Box Testing for contrast.
XP
eXtreme Programming A form of agile programming methodology
43
