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
If you need fractures, use a sub-currency instead.
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
Common version names are also provided for simplicity, meaning:
- A quick and dirty Proof Of Concept version, with partial or "happy
path" functionality, no error checking, may have passed some
functionality alpha testing for a specific scenario.
- A basic functionality version, ready to be tested by a select
non-developer user/QA group. rudimentary error checking, passed
functionality black-box tests, and some unit tests.
- A fully functional Release Candidate for a 1st version ready to be
tested by clients, with full error checking, passed all functionality
black-box tests and beta tests, and all unit tests.
- A fully functional version for public distribution, with error
checking. Passed unit testing, static analysis, basic runtime analysis.
Passed client acceptance test.
Stable Release - Passed several release cycles for bug fixes according to initial user feedback.
- Ready to be used by hundreds of thousands of users where
failures will cause expensive feedback and fixing. Extensively used and
mature version, used by tens of users for a several month period, had
tens of fixes and feedback.
Mission Critical -
Ready to be used on important projects where failures shouldn't
occur. All possible errors are handled gracefully, all input
checked. Extensively used and tested in all scenarios, passed
Accelerated Lifecycle Tests, and extensive %100 coverage runtime tests.
- Ready to be used for life supporting missions, where errors cost
lives. All possible errors are handled gracefully, all input checked.
Passed all possible functionality, unit, static, runtime, and security
red team tests.
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, ARM, Windows official release, Sun/Oracle
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 don't 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 none of the 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.
Some advanced settings can be changed from the Advanced Configuration menu (click the "More.." button, then "Advanced Configuration...").