Enterprise Standards Management
Contents
One of the most important features of Total Visual CodeTools is its
ability to manage development standards for single developers, project
teams, and an entire enterprise. As projects become more complex, and
entail greater staffing requirements, the need for standards in
development becomes crucial.
Total Visual CodeTools tackles this problem by offering a powerful
and flexible architecture for managing your standards.
- As a single developer, you can use Total Visual CodeTools to
ensure that all your projects conform to the development standards
dictated by the project. With support for multiple standards
templates, you can customize standards according to a specific
client's needs, or a particular project's requirements.
- As a team or enterprise developer, Total Visual CodeTools
standards allow you to develop projects without worrying about
whether or not you are conforming to the defined project standard.
- As a development manager, you now have a tool to define
development standards, and enforce them among entire project teams.
Total Visual CodeTools uses Standards to define how your projects are
created and updated. Standards define things like naming conventions,
commenting style, and error handling. In order to use Standards
effectively, it is important to understand the Standards architecture
employed in the product.
Total Visual CodeTools uses two types of settings to control how the
product works and how standards are enforced.
- Shared Standards are the settings that are used throughout the
Total Visual CodeTools tool set. These control development standards
that can be shared by an entire team. Shared standards are stored in
a central shared location so each developer using Total Visual
CodeTools can seamlessly connect to the Standards repository and use
the elements defined there. For example, naming conventions,
commenting style, and error handling settings are Shared Standards.
All Shared Standards are set and managed from the Total Visual
CodeTools Standards form. This enterprise feature is extremely
helpful in maintaining consistent coding styles across your
development team, and is particularly effective for new members of
your team or junior programmers.
- Local Settings are the settings that are assigned to a specific
tool or developer and are unique to each installation of Total
Visual CodeTools. These options are set by the developer from a
specific tool's form. For example, the procedure type setting in the
New Procedure Builder is an option that shouldn't be controlled
centrally--it is up to the developer each time the tool is used.
Another example would be the developer's initials used when
generating comments. Local Settings are stored in the Windows
Registry on the computer running Total Visual CodeTools and are
therefore private to that developer.
Total Visual CodeTools stores all Shared Standards in one or more
Shared Standards files. When you first install the product, a default
file is created in the directory you specified for installation. This
file contains reasonable defaults--if you are a single developer and
want to get started right away, the default settings will most likely be
appropriate.
You can modify any Shared Standards to match your development style
and standards. Additionally, you can save multiple settings in
multiple Shared Standards files. This is helpful if you are working
on multiple projects that have different development standards.
Finally, you can place a Shared Standards file on a shared network
drive and have all installations of Total Visual CodeTools use this
file. Because this file can be password protected, you can define
and protect standards from unwarranted modification.
The Total Visual
CodeTools Shared Standards architecture is designed to be both easy to
use and flexible. This section contains the information you need to get
up and running in multiple situations.
If you are a single developer using Total Visual CodeTools on a
single project, you can start using the product immediately with the
default Standards settings. However, it is worth the time to review the
default values and adjust them according to your needs.
If you are a single developer working on multiple projects, you can
use multiple Shared Standards files to accommodate the different
requirements for each project. For example, you have a client who
requires a particular type of commenting, while another requires a
specific error handling format.
In this scenario, you have multiple developers who are connected to
the same network or shared drive. Each developer has an installation of
Total Visual CodeTools and you want to configure Shared Standards so
every developer uses the same settings.
To accomplish this, you must first configure the Shared Standards
file, and then configure each installation of Total Visual CodeTools to
use the same Shared Standards file.
Having all developers working with Total Visual CodeTools using a
shared settings file is a great concept. But what happens when a
developer disconnects his or her computer from the network? Developers
often go offsite with mobile computers. What happens to the connection
to the settings file in such a case?
To handle this scenario, Total Visual CodeTools automatically
checks at startup to see if its connection to the Shared Settings
file is available. If not, it automatically switches to a local
copy. This means that Total Visual CodeTools can be used even when
disconnected from a Shared Settings file located on a shared drive.
The next time the disconnected developer connects to the shared drive and
starts Total Visual CodeTools, the program automatically reconnects to the
Shared Settings file on the shared drive.
Note that if you have assigned a settings file to the Shared
Settings file, and a developer is working in disconnected mode, the
developer will not be able to change any settings--this is the
design of password protection. However, the developer, who may be at
a remote site, may need to change certain settings in response to
project requirements. In such a case, the developer can clear the
password on his or her local copy using the Save As feature. See the
following section on Password Protection for more information.
This section covers the management aspects of Shared Standards files,
including password-protection, making backups, and restoring defaults.
In order to protect against unwanted changes to your standards, you
can assign a password to Shared Standards files. By assigning a
password, you are restricting certain values in the Standards form to be
read-only, unless you have a password. This is not so much a security
feature as it is a convenience feature. Even if you assign a password to
a Shared Settings file, there is nothing to stop a developer from point
to any other (non-password-protected) settings file. Instead, the
password-protection feature is designed to prevent developers from
making unintentional changes to the team or enterprise standards already
defined.
Because Shared Standards files contain a lot of information,
recreating them manually in the event of a system failure would be a
time-consuming process. To prevent this from happening, it is a good
idea to make backups of your Shared Standards files. To do this, simply
copy any .CTS files to your backup media.
At any time, you can restore the current Shared Settings file to its
default values by pressing the [Defaults] button at the bottom of the
Standards form. Because this action overwrites any current values, you
should use the [Save As] button (under Manage Settings) to save your
current settings before restoring defaults.
