Glossary
accelerated keys
(See shortcut
keys.)
access keys
Access keys allow the user to access a menu title, item,
or object by pressing the Alt key with another key. Often confused with shortcut
keys, but they are quite different.
accessibility
Refers to the ability for everyone, despite any
disabilities they may have, to be able to use your solution.
adjective calibration
Method that uses a scale of verbs that describe the
probability of a risk. (See also risk.)
administrators
Users who have the highest level of security access to
features in an application, and to the data that the solution uses.
application architecture
Perspective in enterprise architecture model that
determines issues dealing with current applications and application models,
and what changes may be necessary to these areas. (See
also enterprise architecture model.)
application model
Addresses how applications are constructed to meet the
needs of customers and users. This model promotes the use of COM (Component
Object Model) components. These components are reusable and can be shared by
other applications your team creates. The application model breaks an
application into a network of consumers and suppliers of services. (See
also consumer, supplier, and service.)
attributes
Also known as properties. The things your object knows.
It’s the data that’s associated to the object. (See also objects.)
auditing
Where activities performed by certain or all users are
documented to a file, allowing a user (such as the administrator) to see what
these users have done. The record showing the operations a user performed is
called an audit trail.
availability
The ability of users to access and use the solution.
bandwidth
The network’s capacity to carry information, and is
measured in data transferred per unit of time, usually seconds.
benchmark and baseline phase
In the TCO model, the phase that calculates cost
baselines, benchmarks, return on investments (ROIs), and validations. The
benchmark is the total cost that’s
based on averages in the industry, while the baseline is the actual cost of the
acquisition, management, and retirement of technology. (See also TCO model.)
betting scheme
Method of calculating risk probability that works as if
you were betting money on particular risks; however, no money actually changes
hands. (See also risk.)
BLOB (Binary Large Objects)
Includes such things as graphics, compiled code, tomes,
and sound, which can cause serious performance issues.
bottom-up estimates
A chain-of-command principle, with those who are lower in
a hierarchy reporting work estimates to those above them.
building
Where your product is moved from the paperwork of
schematics to a physical form. Building takes information from the planning
stage, and ensures that the business-driven application is created on budget and
on schedule. One of the three stages in the Information Technology life cycle. (See
also planning and managing.)
business architecture
Perspective in enterprise architecture model that defines
how the business works. It determines what the business does, its strengths, and
its future. (See also enterprise
architecture model.)
business case
A plan of action that’s presented to senior management,
and backs up a proposal for a project by providing facts and evidence about the
project, and how it will be approached.
business layer
Where all of the business logic and rules are contained.
(See also data layer and user layer.)
business object dependency
When one business
object calls on services in another business object.
business objects
Abstract representations of real-world things or concepts
(such as orders and customers).
business rules
Define the logic of how data is manipulated by your
components. These rules mirror the way the business domain you are modeling
operates or does business.
business services
Also called middle-tier services. In a multi-tier
application business services are used
to enforce transactional integrity, business rules, and control sequencing. This
service also transforms the data acquired from data services into meaningful
information that the user can use. (See
also multi-tier application.)
calling conventions
The syntax to employ the service, the input parameters it
accepts, and the output parameters the service will generate. (See
also interface contract and preconditions.)
capacity
The volume or limit something can handle, and can have a
direct effect on the performance of your solution.
case analysis
The process of modeling how the user or users interact
with the system.
client
Role that perform most of the activities in a solution.
These are the common users of an application, who often add and modify much of
the data your solution will access.
communications
Role in the infrastructure model that is responsible for
maintaining video, voice, and data communications in the project. (See
also infrastructure model.)
component granularity
The functionality that you design into your objects is
referred to as component granularity. The more activities or services that your
objects support, the coarser their granularity.
component object model (COM)
A standard that defines how objects can expose
themselves, the life cycle of an object, and how object exposure works across
networks and processes. COM components are reusable; you can invoke existing COM
components from existing applications. Since COM is a platform-independent,
distributed, object-oriented standard, it allows business applications and
systems to be integrated with Internet technologies. When you create COM classes
to make up your COM component, you use properties, methods, and events to make
up the characteristics of the class, which will subsequently become the
characteristics of your component.
Properties are used to read and set values for a specific
attribute of the component. Methods define an interface for the component, and
are used to invoke actions that the component can perform. This could include
such things as adding items and printing. Events are the actions that are
recognized by an object.
connection pooling
Allows components to connect to data sources using a
previously established connection. This dramatically reduces the overhead and
wait time associated with connecting to a database.
conceptual design
In the solutions design model, conceptual design is where
the initial concept of the solution originates. It is here that the team
develops an understanding of what the user needs from a solution. (See
also solutions design model.)
constraints
Business requirements that enforce what a user can input
into specific columns of your database.
consumer
A program or component that uses the services of another
component.
daily build
Building the executable program by compiling it.
database design
A complex process that consists of identifying,
documenting, and implementing the data requirements of the business.
data buffering
Like a cache, where data is stored to improve the
performance of various tasks being carried out.
data integrity
Business rules that can be used to ensure the integrity
of your application's data.
data layer
Responsible for maintaining, accessing, and updating data
based on requests from the business layer. (See
also user layer and business
layer.)
data services
In a multi-tier application data services provide Create,
Read, Update, and Delete services, as well as such retrieval logic as order and
joins. (See also multi-tier application.)
data validation
Ensures that the values users type in are correct and
accurate.
deliverable
A tangible result of the work performed.
Delphi method
Used to determine risk probability. (Also known as the group consensus method.) Each member provides an
estimate on their own, along with the logic and reasons behind the estimate.
Once this estimate and justification have been submitted, the members receive
the estimates, along with the ratings, and re-evaluate their own submissions.
After re-evaluating their work, each member submits revised estimates, and then
discusses these estimates until they come to a consensus. (See also risk.)
denormalization
Allows you to selectively identify which tables and
columns can break away from the normalization techniques you’ve used in your
database. (See also normalization.)
developing phase
Phase in the process model where the functional
specification and project plan are passed forward. Using this information as a
baseline, the product or service begins to be built at this stage. The
development team sets a number of interim delivery milestones, where the product
goes through several cycles of testing, debugging, and fixing. (See
also process model.)
development
Role in the team model that is responsible for building
or implementing a product or service that meets the requirements and needs of
the customer. (See also team
model.)
direct costs
Predictable costs such as scheduled replenishments of
supplies such as printer paper or diskettes.
dumping
When data is copied to an external device.
end users
The people who use the product on a day-to-day basis, and
can tell you what specific needs the solution must address.
enterprise architecture model
A model that provides guidelines for planning, building,
and managing technology infrastructures using four perspectives to help provide
focus to key issues of a project: business architecture, application
architecture, information architecture, and technology architecture.
(See also business
architecture, application
architecture, information
architecture, and technology
architecture.)
envisioning phase
Phase in the process model where project requirements are
defined. This phase keeps the team from spending effort on minor needs, or
trying to make bad procedures or operations more efficient. (See
also process model.)
extensibility
The ability of an application to go beyond its original
design.
external interim milestones
Are known outside of the development team, and are
announced to the organization. (See also
internal interim milestones.)
fault tolerance
The ability of a solution to function regardless of
whether a fault occurred. In short, it is non-stop availability of a solution.
features
The requirements to be implemented into a product or
service, and the quality and functionality of these items. One of the three
elements of a project. (See also schedule
and resources.)
flexible business solutions
Applications that are adaptable, easily modified, and
have the feature of a consistent interface. Such applications allow users to
perform more activities and perform more complex duties, without having to learn
new applications.
foreign keys
Columns or combinations of columns with values that match
the primary key of another table. The values of a foreign key are often unique
and copy those of the primary key in the other table. Don’t confuse foreign
keys with primary keys. Primary keys identify rows that make up the table, while
foreign keys are used in relationships to reference other tables. (See
also primary keys and relationships.)
Forms
(See normalization.)
generalization/subclass relationship
One of the three types of relationships an object can
have. In this type of relationship, an object is a specific type of another
object. These are often identified when different objects have similar
properties. (See also ownership/container
relationship and user/collaboration
relationship.)
guest
Role that is generally given the lowest level of
security. As its name implies, people who are simply visiting the application,
and don’t require a high level of access, have the role of guest.
GUI (graphical user interface)
Visual display of an application for use by a human user.
(See also programmatic interface.)
help desk
Role in the infrastructure model that is responsible for
providing assistance and ongoing support to the end user. (See also infrastructure model.)
Hungarian Naming Convention
This has prefixes added to the names of controls and
objects, which allow developers to recognize the purpose of those objects and
controls. For example, cmd is the prefix for a command button, lbl for a label,
and txt for a textbox.
improvement phase
In the TCO model, the phase where ROI is calculated.
Based on a strategy you create, this is calculated by simulating the impact of
your recommendations on improvement and estimated cost savings. (See
also TCO model.)
indirect costs
Includes costs not included in an IT budget. These costs
are hidden in the expenses of the business departments of the organization.
information architecture
Perspective in enterprise architecture model that
describes how data and information are handled in a business so it can run
effectively, and describes what the company needs to know to run the
organization’s business processes and operations. (See also enterprise
architecture model.)
infrastructure model
The total set of resources needed to support an
enterprise computing environment. The resources included in this model are the
following: technologies and standards, operational processes, and people and
organizational resources. Team roles are expanded to include the following:
systems management, help desk, and communications. (See also systems management,
help desk, and communications.)
interface
The methods that the object exposes and are the gateways
of communication between objects. They are what allow objects to communicate
with one another and exchange data. Without these interfaces, objects would not
know how to request or provide services to one another.
interface contract
A declaration of any preconditions for using the service,
and the calling conventions. (See also
preconditions and calling
conventions.)
internal interim milestones
Are not known outside the development team because they
are useful only for the team itself. (See
also external interim milestones.)
locality of reference
Putting a component in a location where it will be used,
or near to where it will be used.
logical design
In the solutions design model, logical design takes the
information gathered from the conceptual design and applies it to technical
know-how. While the requirements and needs of customers and users are outlined
in the previous design perspective, it is here that the structure and
communication of elements in the solution are established. Creating a logical
design consists of mapping the business rules and user requirements identified
in the conceptual phase, to objects. These objects, which can most readily be
identified from the user requirements as nouns, also provide services. These
services in turn represent the rules and requirements of the business domain
that you are modeling. (See also solutions
design model.)
logistics
Role in the team model that is responsible for a smooth
rollout of the product. Ensures that the installation and migration of a product
to support and operations groups goes smoothly. (See also team model.)
management phase
In the TCO model, the phase where you measure what you
actually achieved against what you hoped to achieve. The results of your work
are compared to your objectives, which either validates or invalidates the
strategy that was used. (See also TCO
model.)
managing
Maintaining and improving the product. One of the three
stages in the Information Technology life cycle. (See also planning and building.)
metaphors
A term or phrase that suggests a resemblance to something
else. Can be used for objects in your application; for example, files holding
data are stored in folders, which can be stored in cabinet files (like filing
cabinets).
Microsoft Solution Framework (MSF)
A model based on the most successful practices available
for making software projects succeed. Unlike some models that are purely
theoretical, MSF is taken from the experiences of IT professionals.
milestone
A major turning point in the project that indicates
progress. Not only marks the point where one phase of a project ends and another
begins, it also indicates the point in time that members of a team should
synchronize their efforts.
minimum cost strategy
This means that the allocation of resources should be
kept to a minimum, so that costs don’t go too high.
mirroring
This creates an exact duplicate of data, by copying data
from one partition to another (which should be on different hard disks). If you
use a separate hard disk controller for each hard disk in a mirror set, it is
called disk duplexing.
modular design
Breaking a large project into smaller modules, or
subprojects.
multiple versioned releases
Refers to the need to limit the scope of a current
project and plan enhancements (new features) in future versions.
multithreading
When multiple threads of execution are used to process a
task.
multi-tier application
The user interacts with the application through a user
interface and/or programmatic interface, which is the user services tier. The
next tier controls sequencing, and enforces business rules and the transactional
integrity of operations. The bottom tier is where data is stored, and where
manipulations of data take place, such as Create, Delete, Read, and Update
services. (See also user
services, business services, and data
services.)
NIH (Not Invented Here)
Idea that software products developed outside the
organization should rarely be used.
normalization
A set of rules that the logical database design should
satisfy. These rules are called Forms, and they ensure the proper design of your
database. Forms include First Normal Form, where you determine that there are no
duplicated groups or multi-value columns in the
database; Second Normal Form, where you ensure that the non-key fields in your
database depend on the entire primary key, and not just part of it; Third Normal
Form, where you determine that non-key fields don’t depend on other non-key
fields; Fourth Normal Form, which requires that independent data entities are
not stored in the same table when those entities have a many-to-many
relationship with one another; Fifth Normal Form, which dictates that you should
be able to reconstruct an original table from the tables created from breaking
up the original table.
not-to-exceed strategy
Pressure to keep within the budget.
object pooling
Allows components to be recycled.
objects
The things from our requirements that we are modeling.
They are often identified in the requirements as nouns. For example, if you scan
through the requirements from the conceptual design phase, you may notice items
being discussed such as a customer, an order, or an invoice. These things
(nouns) are objects.
ownership/container relationship
One of the three types of relationships objects can have.
Commonly referred to as a parent-child or one-to-many relationship. This is
where one object owns or contains another type of object. (See also generalization/subclass
relationship and user/collaboration
relationship.)
performance
How well an application works under daily conditions.
perspective
In the solutions design model, a perspective is an
outlook or viewpoint on something, which in this case is the design process of
an application. (See also solutions
design model.)
physical design
In the solutions design model, physical design is where
requirements from the conceptual and logical perspectives are put into a
tangible form. It is here that the constraints of technology are applied to the
logical design of the solution. Physical design defines how the components of
your solution, such as the user interface and physical database, work together.
(See also solutions design model.)
planning
Creating strategies and evolving an enterprise
architecture that will drive, or is adaptable to, changes in the business. One
of the three stages in the Information Technology life cycle. (See
also building and managing.)
planning phase
Phase in the process model where the customers and team
members sit down and determine what will be delivered, and how it should be
built. (See also process model.)
preconditions
Conditions that must exist prior to using the service.
For example, a database with certain tables may need to exist in order for the
service to return the requested data. (See
also interface contract and calling
conventions.)
prefetching
When your solution anticipates additional data or data
requests.
primary key
When one column in the table is used as an identifier,
it’s called a primary key. If more than one column is used as an identifier,
it’s called a composite or compound primary key. (See also foreign keys and
relationships.)
proactive risk management
Deals with risks before they become problems that result
in loss. (See also reactive
risk management.)
process
Deals with how things will get done. Process deals with
the methodologies of technology and management.
process model
Clarifies what people are working toward, and the
progress achieved from that work. Process focuses the team on issues relevant to
different phases of the project, and allows members to see that they’re on the
right track with a project. (See also envisioning
phase, planning phase, developing phase, and stabilizing
phase.)
product management
Role in the team model that is responsible for obtaining
the customer’s requirements of a product, and setting the vision for the
product so everyone understands what it entails. (See also team model.)
product specifications
Provide detailed descriptions for project requirements.
program management
Role in the team model that is responsible for making
decisions that determine delivery of the right product at the right time. (See
also team model.)
programmatic interface
Used by other applications to obtain information. (See
also GUI.)
project plan approved milestone
The planning phase results in the project plan approved
milestone, providing the functional specification and schedule. The functional
specification created here is the combined plans of members in each role of the
MSF team model, and details the requirements and commitments of the project. (See
also planning phase.)
prototypes
Provide a way of generating feedback from customers, end
users, and other interested parties. Evolutionary prototypes are built on, and
used in the construction of the end product. Throwaway prototypes are discarded
once they’ve been used to validate the design and generate feedback.
prototype phase
Allows you to validate and refine the initial set of
business objects you developed from the usage scenarios and requirements list.
quality control
Determines the number of defects your product will have
and have removed by release, thereby affecting the quality of the product.
RAID (Redundant Array of Inexpensive Disks)
A common method of fault tolerance. (See also fault tolerance.)
reactive risk management
Deals with risks after they’ve occurred. (See
also proactive risk management.)
referential integrity
When referential integrity is set on a relationship, you
ensure that for every row existing in a foreign key, there is a corresponding
row in the primary key. (See also relationships,
foreign keys, and primary
key.)
relationships
Link two tables together, by having the primary key of
one table referenced by the foreign key of
another table. (See also primary
key and foreign keys.)
release milestone
The stabilizing phase results in the release milestone
where the product is shipped and put into service. (See also stabilizing phase.)
replication
Allows all or part of a database to be copied to other
machines on your network. Because each database is a replication of the other,
users see a consistent copy of available data.
resources
Include such things as the people who work on the
project, the technologies they work with, and the money available to use on a
project. One of the three elements of a project. (See
also schedule and features.)
response time
The difference in time between the end of a query or
command to when the results of that query or command first begin to appear on
the screen.
risk
The possibility of suffering some sort of loss. Inherent
in any project, risk is an opportunity for success. Risk probability is the
likelihood of events occurring, while risk impact is the amount of loss that
could result.
risk assessment table
Documents the probability of loss and the size of loss
associated with the risk. These two fields are multiplied to find the risk
exposure.
risk factor chart
Used to organize and categorize risks, so it can be
determined how critical certain risks are to a project.
risk impact
Measures the size of loss, or severity of adverse effects
if a risk results in becoming an actual problem. It is measured in currency for
risks with a financial impact, time increments (e.g., days and weeks) for risks
with a time impact, or a subjective scale for other risks that don’t fall into
such obvious areas.
risk management
Process of identifying and dealing with areas of the
project that can jeopardize success.
risk statement
Used to communicate the risks involved in a project, so
that members can effectively manage them. Includes not only mentioning the
symptoms of a risk, but what the results of a risk could be.
roaming users
Users who access your solution from more than one
workstation, and thereby require having their preferences available from more
than one computer.
robustness
How well components perform and handle unusual
exceptions.
scalability
How well an application performs as the number of users
increases.
schedule
A timetable with dates that define when parts of a project
are due, and when the finished product or service is due to be completed. One of
the three elements of a project. (See also
features and resources.)
scope
The opposite of vision, and reigns in the features
included in the vision, until it becomes something reasonable that the team can
deliver. (See also vision.)
scope complete/first use milestone
The developing phase results in the scope complet/first
use milestone, where the product’s functionality is assessed, and it is
determined that rollout and support plans are in place before the product is
delivered. (See also developing
phase.)
service
A unit of application logic, which is used to perform an
operation, function, or some sort of transformation on an object.
service request
Communication among the three layers of the multi-tier
application. (See also user
services, business services, and data
services.)
shortcut keys
Allow users to quickly access features of your product.
Rather than having to navigate to a menu title, access the menu, and then select
a menu item, users can press a combination of keys on their keyboard to access
the same command. Also called accelerated keys.
SMART vision/scope document
Specific, Measurable, Achievable, Results-based, and
Time-oriented.
smoke tests
Building the program daily by compiling it, and then
running a series of tests on it to ensure that it functions as it should. Used
to detect major problems that go beyond seeing if the software launches
properly.
solutions design model
Users become involved in the design process. By having
them address key issues, such as usability and requirements, the team is able to
determine that an application will be used and increase productivity. This model
is comprised of different perspectives: conceptual, logical, and physical. (See
also perspective, conceptual design, logical
design, and physical design.)
spiral model
Also called the rapid application development (or RAD)
model. It breaks a project into sub-projects, each of which deals with different
risks in a project. Since each risk is addressed in the sub-projects, all risks
in a project can be identified individually. MSF process model is partially
based on the waterfall model. (See also
waterfall model and process
model.)
stabilizing phase
Phase in the process model with a primary focus on
finding and fixing bugs that have appeared in the product. This phase occurs
concurrently with code development, where the programming of the software
product takes place. (See also process
model.)
stateless components
Do not maintain state between method calls.
supplier
Provides the requested service to this consumer.
systems management
Role in the infrastructure model that is responsible for
maintaining accountability for the systems and technology. This accountability
is inclusive to the continued operation of this technology. (See
also infrastructure model.)
TCO (Total Cost of Ownership) model
Works on the basic premise that optimizing costs equals a
better return on investment (ROI). In other words, by spending less, you have
more money in your pocket. The TCO model approaches this objective by analyzing
the cost areas in a business in a rational and proven method. TCO model uses an
ongoing three-phase process: benchmark and baseline phase, improvement phase,
and management phase. (See also benchmark
and baseline phase, improvement phase,
and management phase.)
team model
Outlines well-defined roles for members of the team. Each
role has its own mission, for which members in that role are responsible. (See
also product management, program
management, development, testing,
user education, and logistics.)
technology architecture
Perspective in enterprise architecture model that
describes standards and guidelines for laying out the software and hardware
supporting an organization. This perspective includes such things as operating
systems, client/workstation tools, and hardware used by workstations and
servers, printers, and modems. (See also
enterprise architecture model.)
testing
Role in the team model that is responsible for making
certain that a product works, and that issues such as bugs and errors are
addressed before release. (See also team
model.)
time and materials strategy
Giving the team power to control risks and changes in a
project by adjusting resources.
trade-off
Where one element of a project is sacrificed so that
another may fulfill the current needs.
trade-off matrix
To establish priorities in a project when dealing with
tradeoffs, a tradeoff matrix can be created to determine a strategy. This allows
the team and customer to specify whether it is more important to stay on
schedule, on budget, or to pass certain features off to future versions. A
tradeoff matrix is simply a table that is used as a reference tool.
transaction
One or more separate actions that are grouped together,
and executed as a single action.
user/collaboration relationship
One of the three types of relationships an object can
have. This is where objects employ the services of other objects. They aren’t
a specific type of another object nor are they owned by another object. They
simply rely on some other object’s specific functionality or service. (See
also container/ownership relationship and generalization/subclass relationship.)
user communities
The parts of an organization that use IT services.
user education
Role in the team model that is responsible for enhancing
the user’s experience and performance with a product, by making the product
easy to understand and use. (See also team
model.)
user layer
The interface of the application. (See also business layer
and data layer.)
user requirements
The list of items that the application needs to be able
to accomplish.
user services
In a multi-tier application user services are associated
with the user interface and/or programmatic interface, provided by units of
application logic. (See also multi-tier
application.)
vision
The features and functionality you’d ideally like to
see in a product. (See also scope.)
vision/scope approved milestone
The envisioning phase results in the vision/scope
approved milestone, where an agreement is made on what direction the project
will take. Vision sets the ultimate goals of the project, while scope recognizes
the limitations. (See also envisioning phase.)
waterfall model
Views the life cycle as a flow of steps. When one step
ends, a milestone is reached. The milestone indicates that the step is assessed,
and the next step begins in the development process. MSF process model is
partially based on the waterfall model. (See also spiral model and
process model.)
Year 2000 (Y2K) problem
The fact that most computer hardware and software has not
been programmed to deal with the date change to the year 2000.
zero-defect milestone
Incremental internal release that passed testing without
any defects and developers can now work on the next set of features.