Today's TIP is on using alias in you command window.
This is to save some typing.
Commonly used for a long strings that are frequently used. Alias allows you to have a small more familiar command or name to execute a long string.
You can add following to your bash profile and enjoy less typing.
alias clr=clear
alias cls=clear
alias conMysql="/usr/local/mysql/bin/mysql -u user -ppassword"
alias openBash="/usr/bin/vim ~/.bash_profile"
alias startTomcat="cd $CATALINA_HOME/bin; ./catalina.sh run"
alias stopTomcat="cd $CATALINA_HOME/bin; ./catalina.sh stop"
You can add more for your frequently used commands.
Monday, July 02, 2007
Write Tests Before You Code : Test-Driven Development (TDD)
Even though this is for Visual Studio, it talks about TDD, good to read.
Reference ->
Reference ->
Write Tests Before You Code
Use the Test-Driven Development methodology in Visual Studio Team System to write tests and improve the quality of your code.
by Jeff Levinson
May 1, 2007
Welcome to Visual Studio Magazine's new online column on Microsoft Visual Studio 2005 Team System (VSTS). Twice a month I will introduce you to concepts in VSTS, for beginners and professionals alike. If you have a question about an aspect of VSTS that you would like to suggest I address in a future column, please send it to onlineedit@1105media.com.
In this debut column, I will demonstrate how to use Team Edition for Software Testers for writing code in accordance with the Test-Driven Development (TDD) methodology. Oddly enough, many developers still do not write unit tests for their code, much less write tests before they write code! Using the TDD process, you write tests before you write code. Two of the most compelling reasons for this approach are (1) all code you write will be testable, and (2) you will not write any unnecessary code. At the very least, even if you decide not to adopt TDD, you will see the value of the unit-testing features in Team System and incorporate them in your process to build better applications.
There are advantages and disadvantages to using TDD. For agile methodologies, incorporating TDD offers a huge benefit because you do not conduct significant upfront design in agile development. TDD does not allow you to create class diagrams and perform optimization up front. However, TDD does make it extremely easy to refactor code you've written. TDD generally prevents you from "gold plating" an application — that is, adding code that is unnecessary and often unused — and it is incredibly simple to add to an application without breaking the whole thing!
Team System implements a generic unit-testing framework that can be adapted to virtually any situation. Team System can be used for TDD, but not in the purest sense of the word. In the TDD process you create a unit test that will break ("red"), fix the method being tested so the test passes ("green"), and refactor — then start the cycle over again. Because you create the test before the method, the test is guaranteed to fail. Typically when performing refactoring, you have a somewhat larger body of code to work from. The good news is that for the purposes of regression testing, almost all of your tests are written already!
Using VSTS you can generate method stubs from your unit test, but you need to create the class that is going to house the method stub first. This is really the only limitation when using VSTS's unit testing from a purist's perspective.
To create your first test, create a new VS Console application. Add a new public class called "Calculate." Select Test > New Test from the main menu, and select Unit Test from the Add New Test dialog. Name the test "CalcTests" (this is not actually the name of the test but is used as the name of the class).
One best practice I suggest is to append "Test" to the name of the method you are going to test — if you write more than one test per method, which is likely, either describe the test or append numbers and enter a description. For example, you may have "AddTestPositiveNumbers" or "AddTest1" with a description. (To enter the description select Test > Windows > Test Manager or Test View and select the test, then add a description in the Properties window.)
Create a new test project (your tests should in generally always be separate from your application code base) and call it "AppTests." Change the name of the test method to "AddTest." Next, add a reference to the ConsoleApplication1 project to the AppTests project and import it in the CalcTests module.
Next, add the following to the test method (entire method is shown for reference):
[TestMethod]
public void AddTest()
{
int x = 5;
int y = 10;
int result = 0;
int expected = 15;
Calculate c = new Calculate();
result = c.Add(x, y);
Assert.AreEqual(expected, result,
"Values are not equal");
}
When you enter result = c.Add(x, y); "Add" will be underlined and you'll be given the option to generate a method stub. When you select this option, the following stub is generated in the Calculate class:
public int Add(int x, int y)
{
throw new Exception("The method or operation is "
+ "not implemented.");
}
The Assert method is a class with a collection of static methods that allows you to evaluate one or more values that you use to determine if a test passes. Run the test by selecting Test > Window > Test Manager or Test Viewer, check the AddTest entry, and select the Run Checked Tests button. The test will, of course, fail. Change the Add method to read:
public int Add(int x, int y)
{
return x + y;
}
Compile the application and re-run the test — this time it passes. You're on your way to developing code with TDD.
VSTS allows you to perform many more advanced operations, such as extending the testing framework, creating data-driven tests (test data supplied from a database), checking code coverage and providing other tools to help improve the quality of your code. I will explore these features and more in future columns.
About the Author
Jeff Levinson is a senior consultant at Accentient, Inc. He specializes in methodology and process improvement using Visual Studio Team System. He is a former solutions design and integration architect for The Boeing Company. He is a Microsoft Team System MVP and holds the MCAD, MCSD, MCDBA and security certifications. He is co-author of the book Pro Visual Studio 2005 Team System.
Software Comfortableness-Important trait of common good UI
Today I would like to share with you about the 'Software Comfortableness' & 'how to identify good/bad software comfort' which will help you to test the UIs while moving with your projects.
S/w comfort is a pretty touchy-feely concept, which conveys the comfortable usage. Appropriateness,error handling and performance are some basic features of that. The very basic idea of these features as follows,
*Appropriateness, The proper look & feel of the software what it's doing and who it's for and also neither be too garish nor too plain for the task It's intended to perform.
*Error handling, It should warn users before a critical operation and allow users to restore data lost because of mistake
*Performance, It should be flashed error messages too quickly to read and If an operation is slow, It should at least give the user feedback on how much longer It will take & slow that It's still working like status bars. Hope this tip will help you, because Software Comfortableness is one of the important trait of common good UI.
*Appropriateness, The proper look & feel of the software what it's doing and who it's for and also neither be too garish nor too plain for the task It's intended to perform.
*Error handling, It should warn users before a critical operation and allow users to restore data lost because of mistake
*Performance, It should be flashed error messages too quickly to read and If an operation is slow, It should at least give the user feedback on how much longer It will take & slow that It's still working like status bars. Hope this tip will help you, because Software Comfortableness is one of the important trait of common good UI.
User Acceptance Testing – What to Test?
- To ensure an effective User Acceptance Testing Test cases are created.
- These Test cases can be created using various use cases identified during the Requirements definition stage.
- The Test cases ensure proper coverage of all the scenarios during testing.
- During this type of testing the specific focus is the exact real world usage of the application.
- The Testing is done in an environment that simulates the production environment.
- The Test cases are written using real world scenarios for the application.
Tips to find Important Bugs Quickly
We as QA engineers need to find important (Blocker, Critical and Major) bugs quickly in a release testing cycle.
Your smoke test should be able to find most of them shortly after installation (1-2 hours)
Good QA engineers should be able to define SMOKE test cases which capture important bugs.
But how to find important bugs fast. You should be able to smell where system is broken. :-)
Here are few TIPS.
1) Test things that are changed. Fixes and Updates mean fresh RISK.
Most of you know this by experience by now.
2) Test core functions before contributing functions. Test the popular and Critical things that the application does.
Test the functions that makes the product what it is. (e.g. Test ETL/Core before admin)
3) Test capability before reliability. Test whether each function can work at all before deep penetration.
Testing all possibilities should be done later.
4) Test common situations before highly unlikely tests. Use popular data and scenarios of use.
(e.g. Use common files from customer before abnormal files)
5) Test common threats before highly unlikely tests. Test with most likely stress and error situations.
(e.g. Testing 100+ using interacting with an Admin GUI is not a common scenario. Simulating 1000+ users sending topup messages is a common stress scenario.)
6) Test for high impact problems before low impact problems. Test the part of the product that would do a lot of damage in case of failure. Where the RISK his hight more testing should be done.
(e.g. Testing an admin module before Core is not acceptable)
7) Test most wanted areas before areas not requested. You can capture this during knowledge transfer session with pre-sales.
Above list is common to most of the project. You can important bugs sooner
--- If you know more about the product
--- Software and Hardware that interact with the product
--- People who use it
--- People who develop it
I recommend you to think about this and improve on this and explore other ways to find bugs quickly.
Your smoke test should be able to find most of them shortly after installation (1-2 hours)
Good QA engineers should be able to define SMOKE test cases which capture important bugs.
But how to find important bugs fast. You should be able to smell where system is broken. :-)
Here are few TIPS.
1) Test things that are changed. Fixes and Updates mean fresh RISK.
Most of you know this by experience by now.
2) Test core functions before contributing functions. Test the popular and Critical things that the application does.
Test the functions that makes the product what it is. (e.g. Test ETL/Core before admin)
3) Test capability before reliability. Test whether each function can work at all before deep penetration.
Testing all possibilities should be done later.
4) Test common situations before highly unlikely tests. Use popular data and scenarios of use.
(e.g. Use common files from customer before abnormal files)
5) Test common threats before highly unlikely tests. Test with most likely stress and error situations.
(e.g. Testing 100+ using interacting with an Admin GUI is not a common scenario. Simulating 1000+ users sending topup messages is a common stress scenario.)
6) Test for high impact problems before low impact problems. Test the part of the product that would do a lot of damage in case of failure. Where the RISK his hight more testing should be done.
(e.g. Testing an admin module before Core is not acceptable)
7) Test most wanted areas before areas not requested. You can capture this during knowledge transfer session with pre-sales.
Above list is common to most of the project. You can important bugs sooner
--- If you know more about the product
--- Software and Hardware that interact with the product
--- People who use it
--- People who develop it
I recommend you to think about this and improve on this and explore other ways to find bugs quickly.
Saturday, June 16, 2007
Measurement and Analysis: Specific Practices by Goal
SG 1 Align Measurement and Analysis Activities
Measurement objectives and activities are aligned with identified information needs and objectives. The specific practices covered under this specific goal may be addressed concurrently or in any order:
· When establishing measurement objectives, experts often think ahead about necessary criteria for specifying measures and analysis procedures. They also think concurrently about the constraints imposed by data collection and storage procedures.
· It often is important to specify the essential analyses that will be conducted before attending to details of measurement specification, data collection, or storage.
SP 1.1 Establish Measurement Objectives
Establish and maintain measurement objectives that are derived from identified information needs and objectives.
Measurement objectives document the purposes for which measurement and analysis are done, and specify the kinds of actions that may be taken based on the results of data analyses.
The sources for measurement objectives may be management, technical, project, product, or process implementation needs.
The measurement objectives may be constrained by existing processes, available resources, or other measurement considerations.
Judgments may need to be made about whether the value of the results will be commensurate with the resources devoted to doing the work.
Modifications to identified information needs and objectives may, in turn, be indicated as a consequence of the process and results of measurement and analysis. Sources of information needs and objectives may include the following:
· Project plans
· Monitoring of project performance
· Interviews with managers and others who have information needs
· Established management objectives
· Strategic plans
· Business plans
· Formal requirements or contractual obligations
· Recurring or other troublesome management or technical problems
· Experiences of other projects or organizational entities
· External industry benchmarks
· Process-improvement plans
Typical Work Products
1. Measurement objectives
Subpractices
1. Document information needs and objectives.
Information needs and objectives are documented to allow traceability to subsequent measurement and analysis activities.
2. Prioritize information needs and objectives.
It may be neither possible nor desirable to subject all initially identified information needs to measurement and analysis. Priorities may also need to be set within the limits of available resources.
3. Document, review, and update measurement objectives.
It is important to carefully consider the purposes and intended uses of measurement and analysis.
The measurement objectives are documented, reviewed by management and other relevant stakeholders, and updated as necessary. Doing so enables traceability to subsequent measurement and analysis activities, and helps ensure that the analyses will properly address identified information needs and
objectives.
It is important that users of measurement and analysis results be involved in setting measurement objectives and deciding on plans of action. It may also be appropriate to involve those who provide the measurement data.
4. Provide feedback for refining and clarifying information needs and objectives as necessary.
Identified information needs and objectives may need to be refined and clarified as a result of setting measurement objectives. Initial descriptions of information needs may be unclear or ambiguous. Conflicts may arise between existing needs and objectives. Precise targets on an already existing measure may be
unrealistic.
5. Maintain traceability of the measurement objectives to the identified information needs and objectives.
There must always be a good answer to the question, "Why are we measuring this?"
Of course, the measurement objectives may also change to reflect evolving information needs and objectives.
SP 1.2 Specify Measures
Specify measures to address the measurement objectives.
Measurement objectives are refined into precise, quantifiable measures. Measures may be either "base" or "derived." Data for base measures are obtained by direct measurement. Data for derived measures come from other data, typically by combining two or more base measures.
Examples of commonly used base measures include the following:
· Estimates and actual measures of work product size (e.g., number of pages)
· Estimates and actual measures of effort and cost (e.g., number of person hours)
· Quality measures (e.g., number of defects, number of defects by severity)
Examples of commonly used derived measures include the following:
· Earned Value
· Schedule Performance Index
· Defect density
· Peer review coverage
· Test or verification coverage
· Reliability measures (e.g., mean time to failure)
· Quality measures (e.g., number of defects by severity/total number of defects)
Derived measures typically are expressed as ratios, composite indices,or other aggregate summary measures. They are often more quantitatively reliable and meaningfully interpretable than the base
measures used to generate them.
Typical Work Products
1. Specifications of base and derived measures
Subpractices
1. Identify candidate measures based on documented measurement objectives.
The measurement objectives are refined into specific measures. The identified candidate measures are categorized and specified by name and unit of measure.
2. Identify existing measures that already address the measurement objectives.
Specifications for measures may already exist, perhaps established for other purposes earlier or elsewhere in the organization.
3. Specify operational definitions for the measures.
Operational definitions are stated in precise and unambiguous terms. They address two important criteria as follows: · Communication: What has been measured, how was it measured, what are the units of measure, and what has been included or excluded?
· Repeatability: Can the measurement be repeated, given the same definition, to get the same results?
4. Prioritize, review, and update measures.
Proposed specifications of the measures are reviewed for their appropriateness with potential end users and other relevant stakeholders. Priorities are set or changed, and specifications of the measures are updated as necessary.
SP 1.3 Specify Data Collection and Storage Procedures
Specify how measurement data will be obtained and stored.
Explicit specification of collection methods helps ensure that the right data are collected properly. It may also aid in further clarifying information needs and measurement objectives.
Proper attention to storage and retrieval procedures helps ensure that data are available and accessible for future use.
Typical Work Products
1. Data collection and storage procedures
2. Data collection tools
Subpractices
1. Identify existing sources of data that are generated from current work products, processes, or transactions.
Existing sources of data may already have been identified when specifying the measures. Appropriate collection mechanisms may exist whether or not pertinent data have already been collected.
2. Identify measures for which data are needed, but are not currently available.
3. Specify how to collect and store the data for each required measure.
Explicit specifications are made of how, where, and when the data will be collected. Procedures for collecting valid data are specified. The data are stored in an accessible manner for analysis, and it is determined whether they will be saved for possible reanalysis or documentation purposes. Questions to be considered typically include the following:
· Have the frequency of collection and the points in the process where measurements will be made been determined?
· Has the time line that is required to move measurement results from the points of collection to repositories, other databases, or end users been established?
· Who is responsible for obtaining the data?
· Who is responsible for data storage, retrieval, and security?
· Have necessary supporting tools been developed or acquired?
4. Create data collection mechanisms and process guidance.
Data collection and storage mechanisms are well integrated with other normal work processes. Data collection mechanisms may include manual or automated forms and templates. Clear, concise guidance on correct procedures is available to those responsible for doing the work. Training is provided as necessary to
clarify the processes necessary for collection of complete and accurate data and to minimize the burden on those who must provide and record the data.
5. Support automatic collection of the data where appropriate and feasible.
Automated support can aid in collecting more complete and accurate data.
Examples of such automated support include the following:
· Timestamped activity logs
· Static or dynamic analyses of artifacts
However, some data cannot be collected without human intervention (e.g.,customer satisfaction or other human judgments), and setting up the necessary infrastructure for other automation may be costly.
6. Prioritize, review, and update data collection and storage procedures.
Proposed procedures are reviewed for their appropriateness and feasibility with those who are responsible for providing, collecting, and storing the data. They also may have useful insights about how to improve existing processes, or be able to suggest other useful measures or analyses.
7. Update measures and measurement objectives as necessary.
Priorities may need to be reset based on the following:
· The importance of the measures
· The amount of effort required to obtain the data
Considerations include whether new forms, tools, or training would be required to obtain the data.
SP 1.4 Specify Analysis Procedures
Specify how measurement data will be analyzed and reported.
Specifying the analysis procedures in advance ensures that appropriate analyses will be conducted and reported to address the documented measurement objectives (and thereby the information needs and
objectives on which they are based). This approach also provides a check that the necessary data will in fact be collected.
Typical Work Products
1. Analysis specification and procedures
2. Data analysis tools
Subpractices
1. Specify and prioritize the analyses that will be conducted and the reports that will be prepared.
Early attention should be paid to the analyses that will be conducted and to the manner in which the results will be reported. These should meet the following criteria:
· The analyses explicitly address the documented measurement objectives
· Presentation of the results is clearly understandable by the audiences to whom the results are addressed
Priorities may have to be set within available resources.
2. Select appropriate data analysis methods and tools.
Issues to be considered typically include the following:
· Choice of visual display and other presentation techniques (e.g., pie charts, bar charts, histograms, radar charts, line graphs, scatter plots, or tables)
· Choice of appropriate descriptive statistics (e.g., arithmetic mean, median, or mode)
· Decisions about statistical sampling criteria when it is impossible or unnecessary
to examine every data element
· Decisions about how to handle analysis in the presence of missing data elements
· Selection of appropriate analysis tools
· The work does not cost more to perform than is justified by the benefits that it provides.
Criteria for evaluating the conduct of the measurement and analysis might include the extent to which the following apply:
· The amount of missing data or the number of flagged inconsistencies is beyond specified thresholds.
· There is selection bias in sampling (e.g., only satisfied end users are surveyed to evaluate end-user satisfaction, or only unsuccessful projects are evaluated to determine overall productivity).
· The measurement data are repeatable (e.g., statistically reliable).
· Statistical assumptions have been satisfied (e.g., about the distribution of data or about appropriate measurement scales).
Measurement objectives and activities are aligned with identified information needs and objectives. The specific practices covered under this specific goal may be addressed concurrently or in any order:
· When establishing measurement objectives, experts often think ahead about necessary criteria for specifying measures and analysis procedures. They also think concurrently about the constraints imposed by data collection and storage procedures.
· It often is important to specify the essential analyses that will be conducted before attending to details of measurement specification, data collection, or storage.
SP 1.1 Establish Measurement Objectives
Establish and maintain measurement objectives that are derived from identified information needs and objectives.
Measurement objectives document the purposes for which measurement and analysis are done, and specify the kinds of actions that may be taken based on the results of data analyses.
The sources for measurement objectives may be management, technical, project, product, or process implementation needs.
The measurement objectives may be constrained by existing processes, available resources, or other measurement considerations.
Judgments may need to be made about whether the value of the results will be commensurate with the resources devoted to doing the work.
Modifications to identified information needs and objectives may, in turn, be indicated as a consequence of the process and results of measurement and analysis. Sources of information needs and objectives may include the following:
· Project plans
· Monitoring of project performance
· Interviews with managers and others who have information needs
· Established management objectives
· Strategic plans
· Business plans
· Formal requirements or contractual obligations
· Recurring or other troublesome management or technical problems
· Experiences of other projects or organizational entities
· External industry benchmarks
· Process-improvement plans
Typical Work Products
1. Measurement objectives
Subpractices
1. Document information needs and objectives.
Information needs and objectives are documented to allow traceability to subsequent measurement and analysis activities.
2. Prioritize information needs and objectives.
It may be neither possible nor desirable to subject all initially identified information needs to measurement and analysis. Priorities may also need to be set within the limits of available resources.
3. Document, review, and update measurement objectives.
It is important to carefully consider the purposes and intended uses of measurement and analysis.
The measurement objectives are documented, reviewed by management and other relevant stakeholders, and updated as necessary. Doing so enables traceability to subsequent measurement and analysis activities, and helps ensure that the analyses will properly address identified information needs and
objectives.
It is important that users of measurement and analysis results be involved in setting measurement objectives and deciding on plans of action. It may also be appropriate to involve those who provide the measurement data.
4. Provide feedback for refining and clarifying information needs and objectives as necessary.
Identified information needs and objectives may need to be refined and clarified as a result of setting measurement objectives. Initial descriptions of information needs may be unclear or ambiguous. Conflicts may arise between existing needs and objectives. Precise targets on an already existing measure may be
unrealistic.
5. Maintain traceability of the measurement objectives to the identified information needs and objectives.
There must always be a good answer to the question, "Why are we measuring this?"
Of course, the measurement objectives may also change to reflect evolving information needs and objectives.
SP 1.2 Specify Measures
Specify measures to address the measurement objectives.
Measurement objectives are refined into precise, quantifiable measures. Measures may be either "base" or "derived." Data for base measures are obtained by direct measurement. Data for derived measures come from other data, typically by combining two or more base measures.
Examples of commonly used base measures include the following:
· Estimates and actual measures of work product size (e.g., number of pages)
· Estimates and actual measures of effort and cost (e.g., number of person hours)
· Quality measures (e.g., number of defects, number of defects by severity)
Examples of commonly used derived measures include the following:
· Earned Value
· Schedule Performance Index
· Defect density
· Peer review coverage
· Test or verification coverage
· Reliability measures (e.g., mean time to failure)
· Quality measures (e.g., number of defects by severity/total number of defects)
Derived measures typically are expressed as ratios, composite indices,or other aggregate summary measures. They are often more quantitatively reliable and meaningfully interpretable than the base
measures used to generate them.
Typical Work Products
1. Specifications of base and derived measures
Subpractices
1. Identify candidate measures based on documented measurement objectives.
The measurement objectives are refined into specific measures. The identified candidate measures are categorized and specified by name and unit of measure.
2. Identify existing measures that already address the measurement objectives.
Specifications for measures may already exist, perhaps established for other purposes earlier or elsewhere in the organization.
3. Specify operational definitions for the measures.
Operational definitions are stated in precise and unambiguous terms. They address two important criteria as follows: · Communication: What has been measured, how was it measured, what are the units of measure, and what has been included or excluded?
· Repeatability: Can the measurement be repeated, given the same definition, to get the same results?
4. Prioritize, review, and update measures.
Proposed specifications of the measures are reviewed for their appropriateness with potential end users and other relevant stakeholders. Priorities are set or changed, and specifications of the measures are updated as necessary.
SP 1.3 Specify Data Collection and Storage Procedures
Specify how measurement data will be obtained and stored.
Explicit specification of collection methods helps ensure that the right data are collected properly. It may also aid in further clarifying information needs and measurement objectives.
Proper attention to storage and retrieval procedures helps ensure that data are available and accessible for future use.
Typical Work Products
1. Data collection and storage procedures
2. Data collection tools
Subpractices
1. Identify existing sources of data that are generated from current work products, processes, or transactions.
Existing sources of data may already have been identified when specifying the measures. Appropriate collection mechanisms may exist whether or not pertinent data have already been collected.
2. Identify measures for which data are needed, but are not currently available.
3. Specify how to collect and store the data for each required measure.
Explicit specifications are made of how, where, and when the data will be collected. Procedures for collecting valid data are specified. The data are stored in an accessible manner for analysis, and it is determined whether they will be saved for possible reanalysis or documentation purposes. Questions to be considered typically include the following:
· Have the frequency of collection and the points in the process where measurements will be made been determined?
· Has the time line that is required to move measurement results from the points of collection to repositories, other databases, or end users been established?
· Who is responsible for obtaining the data?
· Who is responsible for data storage, retrieval, and security?
· Have necessary supporting tools been developed or acquired?
4. Create data collection mechanisms and process guidance.
Data collection and storage mechanisms are well integrated with other normal work processes. Data collection mechanisms may include manual or automated forms and templates. Clear, concise guidance on correct procedures is available to those responsible for doing the work. Training is provided as necessary to
clarify the processes necessary for collection of complete and accurate data and to minimize the burden on those who must provide and record the data.
5. Support automatic collection of the data where appropriate and feasible.
Automated support can aid in collecting more complete and accurate data.
Examples of such automated support include the following:
· Timestamped activity logs
· Static or dynamic analyses of artifacts
However, some data cannot be collected without human intervention (e.g.,customer satisfaction or other human judgments), and setting up the necessary infrastructure for other automation may be costly.
6. Prioritize, review, and update data collection and storage procedures.
Proposed procedures are reviewed for their appropriateness and feasibility with those who are responsible for providing, collecting, and storing the data. They also may have useful insights about how to improve existing processes, or be able to suggest other useful measures or analyses.
7. Update measures and measurement objectives as necessary.
Priorities may need to be reset based on the following:
· The importance of the measures
· The amount of effort required to obtain the data
Considerations include whether new forms, tools, or training would be required to obtain the data.
SP 1.4 Specify Analysis Procedures
Specify how measurement data will be analyzed and reported.
Specifying the analysis procedures in advance ensures that appropriate analyses will be conducted and reported to address the documented measurement objectives (and thereby the information needs and
objectives on which they are based). This approach also provides a check that the necessary data will in fact be collected.
Typical Work Products
1. Analysis specification and procedures
2. Data analysis tools
Subpractices
1. Specify and prioritize the analyses that will be conducted and the reports that will be prepared.
Early attention should be paid to the analyses that will be conducted and to the manner in which the results will be reported. These should meet the following criteria:
· The analyses explicitly address the documented measurement objectives
· Presentation of the results is clearly understandable by the audiences to whom the results are addressed
Priorities may have to be set within available resources.
2. Select appropriate data analysis methods and tools.
Issues to be considered typically include the following:
· Choice of visual display and other presentation techniques (e.g., pie charts, bar charts, histograms, radar charts, line graphs, scatter plots, or tables)
· Choice of appropriate descriptive statistics (e.g., arithmetic mean, median, or mode)
· Decisions about statistical sampling criteria when it is impossible or unnecessary
to examine every data element
· Decisions about how to handle analysis in the presence of missing data elements
· Selection of appropriate analysis tools
· The work does not cost more to perform than is justified by the benefits that it provides.
Criteria for evaluating the conduct of the measurement and analysis might include the extent to which the following apply:
· The amount of missing data or the number of flagged inconsistencies is beyond specified thresholds.
· There is selection bias in sampling (e.g., only satisfied end users are surveyed to evaluate end-user satisfaction, or only unsuccessful projects are evaluated to determine overall productivity).
· The measurement data are repeatable (e.g., statistically reliable).
· Statistical assumptions have been satisfied (e.g., about the distribution of data or about appropriate measurement scales).
Color and Suggested meaning
Before your audience read and react to your information they see it in color.
It can excite, impress, entertain and persuade but color also can create instant negative associations.
It's good idea to be aware that how the majority of people respond to the colors and use this information in your choice of colors .
Following chart will help you
Note: Be careful in using colors in official emails.