SettingsPrice per Hour
This value should correlate with the task you are using ProjectCodeMeter for, in most cases you'll want to enter
the gross average hourly rate of a programmer with skills for this type of
project when you use ProjectCodeMeter to calculate the expected gross cost it takes for an average programmer to create this project. Likewise, enter the cost of your programmer to estimate the cost it should take your team to create this project if he/she works at the market average speed. As another example, if you enter the net minimum cost of a development hour, you will get the net minimum cost of the project if done by an average developer.
For specific tasks see the Quick Function Overview
section of the main page. If your developers have several pay grades,
Then enter their average hourly rate when measuring their combined
can enter any integer number for the cost along with any formatting you wish for
representing currency. As an example, all these are valid inputs: 200,
$50, 70 USD, 3200Cents, 4000 Yen.
However integer number format must contain digits ONLY without delimiters, for example these are invalid: 1,000 or 24.5
product quality guaranteed by the programmers' contract. The amount of
quality assurance (QA) testing which was done on the project determines
its failure rate. There is no effective way to determine the amount of
testing done, except for the programmers guarantee. QA can be done in several methods (Unit Testing, UI Automation, Manual Checklist), under several Lifecycle methodologies where quality levels are marked differently for each.
levels stated in Sigma are according to the standard Process Fallout model, as measured in long term Defects Per Million:
1-Sigma 691,462 Defects / Million
2-Sigma 308,538 Defects / Million
3-Sigma 66,807 Defects / Million
4-Sigma 6,210 Defects / Million
5-Sigma 233 Defects / Million
6-Sigma 3.4 Defects / Million
7-Sigma 0.019 Defects / Million
quality of the underlying system platform, measured in average stability and
support for all the platform parts, including the Function library
API, Operating System, Hardware, and Development Tools.
You should select "Popular Stable and Documented" for standard architectures like:
Intel and AMD PCs, Windows NT, Sun
Java VM, Sun J2ME KVM, Windows Mobile, C runtime library, Apache server, Microsoft IIS, Popular Linux
distros (Ubuntu, RedHat/Fedora, Mandriva, Puppy, DSL), Flash.
Here is a more detailed platform list.
type of debugging tools available to the programmer. Tools are listed in descending efficiency (each tool has the capabilities of all lower ranked tools). For projects which do not use any
external or non-standard hardware or network setup, and a Source Step Debugger is available, You should select "Complete System Emulator / VM" since in this case the external platform state is irrelevant thus making a Step Debugger and an Emulator equally useful.
Simulators and Virtual Machines (VMs)
are top of the line debugging
tools, allowing the programmer to simulate the entire system including
the hardware, stop at any given point and examine the internals
and status of the system. They are synchronized with the source step
debugger to stop at the same time the debugger does, allowing to step
through the source code and the platform state.
A "Complete System Emulator" allows to pause and examine every hardware
component which interacts with the project, while a "Main Core Emulator"
only allows this for the major components (CPU, Display, RAM, Storage,
Source Step Debuggers allow the programmer
to step through each line of the code, pausing and examining internal code
variables, but only very few or no external platform states.
Binary Step Debuggers
allow stepping through machine instructions (disassembly) and examining
data and execution state, but don't show the original source code.
Log is used to write a line of text selected by the programmer to a
file, whether directly or through a supporting
hardware/software tool (such as a protocol analyzer or a serial
or Beep Indication is a last resort debugging tool sometimes used by embedded
programmers, usually on experimental systems when supporting tools are
not yet available, on reverse engineering unfamiliar hardware, or when
advanced tools are too expensive.