@echo off

if “%1″ == “” goto Help
if /i “%1″ == “-h” goto Help

set server=%1
set project=%2
set buildType=%3

set schedule=%4
set startTime=%5
set startDate=%6

set schName=%2_%3

set tfsCommand=”C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TfsBuild.exe start %server% %project% %buildType%”

set user=%userdomain%\%username%
echo %tfsCommand%

schtasks /create /sc %schedule% /tn %schName% /tr %tfsCommand% /st %startTime% /sd %startDate% /ru %user% /rp *
Goto Done

:Help
@echo Usage: schbuild TeamfoundationServer TeamProject BuildType Schedule StartTime StartDate
@echo.
@echo     TeamfoundationServer   The Team Foundation server.
@echo.
@echo     TeamProject            Team project name.
@echo.
@echo     BuildType              Build Type name.
@echo.
@echo     Schedule               Specifies the schedule frequency.
@echo                            Valid schedule types: MINUTE, HOURLY,
@echo                            DAILY, WEEKLY, MONTHLY, ONCE.
@echo.
@echo     StartTime              Time to start the build in HH:MM:SS
@echo                            (24 hour format)
@echo.
@echo     StartDate              Specifies the first date on which the
@echo                            task runs. The format is mm/dd/yyyy.

one

If the BuildType includes a space however, you’d have to type something like:

schbuild.bat buildmachine123 OurProject “Server Core Engine” DAILY 03:10:00 04/01/2006

In such a case you can either add the task manually or re-write the script.

I am writing to inform you of what has developed since my note of December 18^th and to outline plans to restore our stakeholders’ faith in Satyam.

The events of the past two weeks have raised many questions, but these can be distilled into two basic issues: the viability of our business strategy to diversify; and the effectiveness of our corporate governance.

Re: business strategy, you should understand that Satyam is completely committed to the IT services and BPO business, as we have been since our inception.  While the idea that we could diversify into an unrelated business was rejected by our investors, it was formed with the belief that doing so would not imperil our leadership in our core business or lessen our commitment to it, and that all stakeholders would benefit.  Satyam did not – and does not now – intend to retreat from IT and BPO services in any way, and going forward, Satyam will focus exclusively on these markets.

Re: corporate governance, the board arrived at its decision to bid for Maytas by following all required processes and procedures, and while there was a spirited discussion among members, their vote to approve the motion was unanimous.  Further, Satyam has won numerous awards for excellence in corporate governance, including the Golden Peacock Global Award for Excellence in Corporate Governance on two separate occasions, most recently in 2008.

Over the past two weeks, we have been communicating these facts to our customers, and I’m very pleased to report that customers continue to show a high level of trust in Satyam.

We have also been in contact with many of our investors, and we have taken key steps to regain their confidence.  These include strengthening the board by changing its size and composition, and engaging DSP Merrill Lynch to provide strategic advice and options.  The board will meet on January 10, 2009 to consider these options and to chart a course of action that would boost stakeholders’ confidence further.

Please be assured that the board and the leadership team are doing everything possible to get Satyam back on track.  We cannot do this without your help, however.  I ask for your continued faith in Satyam and for your steadfast focus on your customers, especially in the face of wild speculation and unchecked rumor.  There is simply no more effective way to strengthen the company and to secure its future – and yours – than by delighting your customers.

Thank you very much for your commitment and support.  Once again, I wish you the very best for 2009.

With warm regards,

Raju

Toshiba has also gone with a customized 3D UI to add a little pizzazz to the mix. The Mobile Internet Device is powered by a 1GHz mobileCPU. Aside from its extremely large display and a slim 9.9mm thick body, this GSM handset is quite well equipped too with features that include - 

• Internal GPS with A-GPS
• Bluetooth 2.0
• Wi-Fi
• EDGE/GPRS and 3G with HSDPA support
• 512MB internal memory with up to 32GB for external via MicroSD cards
• 3.2 megapixel camera
• Support for DivX video playback.
• Internet Explorer Mobile 6 with full support for Flash and a virtual track pad for web navigation
• Shake control for specific features as well as an accelerometer for screen rotation

Other than that the company and Qualcomm have claimed that the TG01 will actually be able to go for a whole day without recharging thanks to the CPU’s dynamic speed control. 

The TG01 mobile will be available in two colors according to the images making the rounds - black and white. It’ll hit Europe later this year through exclusive operator deals. There’s no pricing mentioned yet so stay tuned.

And when a defect gets through during the development process, the earlier it is diagnosed, the easier and cheaper is the rectification of the defect. The end result in prevention or early detection is a product with zero or minimal defects.

How serious are defects in software development? In the United States, up to 60 percent of software developers are involved in fixing errors, Computer Finance Magazine reported in 1998. This fact alone, without consideration of providing the quality needed to please customers, shows the value of preventing software defects.

Advantage of Early Defect Detection

Data to support the need for early fixes of software defects is supplied by several reports. The National Institute of Standard Technology (NIST) published a study in 2002 noting that the cost of fixing one bug found in the production stage of software is 15 hours compared to five hours of effort if the same bug were found in the coding stage.

The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase (Figure 1).

Figure 1: Relative Costs to Fix Software Defects

                                                                                                      Source: IBM Systems Sciences Institute 

Can software defects be prevented by simply logging them into some “defect tracking tool/system,” documenting them and providing fixes for them? The obvious answer is no, though this is the first step toward defect prevention.

Defect prevention involves a structured problem-solving methodology to identify, analyze and prevent the occurrence of defects. Defect prevention is a framework and ongoing process of collecting the defect data, doing root cause analysis, determining and implementing the corrective actions and sharing the lessons learned to avoid future defects.

Principles of Defect Prevention

How does a defect prevention mechanism work? The answer is in a defect prevention cycle (Figure 2). The integral part of the defect prevention process begins with requirement analysis – translating the customer requirements into product specifications without introducing additional errors. Software architecture is designed, code review and testing are done to find out the defects, followed by defect logging and documentation.

Figure 2: Defect Prevention Cycle

                                                                                           Source: 1998 IEEE Software Productivity Consortium 

The blocks and processes in the gray-colored block represent the handling of defects within the existing philosophy of most of the software industry – defect detection, tracking/documenting and analysis of defects for arriving at quick, short-term solutions.

The processes that form the integral part of the defect prevention methodology are on the white background. The vital process of the defect prevention methodology is to analyze defects to get their root causes, to determine a quick solution and preventive action. These preventive measures, after consent and commitments from team members, are embedded into the organization as a baseline for future projects. The methodology is aimed at providing the organization a long-term solution and the maturity to learn from mistakes.

Most of the activities of the defect prevention methodology require a facilitator. The facilitator can be the software development project leader (wearing another hat of responsibility) or any member of the team. The designated defect prevention coordinator is actively involved in leading defect prevention efforts, facilitating meetings and communication among team and management, and consolidating the defect prevention measures/guidelines.

The five general activities of defect prevention are:

1. Software Requirements Analysis

Errors in software requirements and software design documents are more frequent than errors in the source code itself, according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also are more severe and more difficult to remove. Front-end errors in requirements and design cannot be found and removed via testing, but instead need pre-test reviews and inspections. Table 1 shows the defects introduced during different phases of the software development life cycle. 

From the studies made by various software development communities, it is evident that most failures in software products are due to errors in the requirements and design phases – as high as 64 percent of total defect costs (Figure 3), according to Crosstalk, the Journal of Defense Software Engineering.

Figure 3: Origin of Software Defects

                                                                      Source: Crosstalk, the Journal of Defense Software Engineering 

Hence, it is important to have a proper process of analyzing the requirements in place to ensure that the customer needs are correctly translated into product specifications. Perhaps two or three iteration of interactive sessions with the customer can be of great help in verifying the understanding of the developer about actual requirements.

2. Reviews: Self-Review and Peer Review

Self-review is one of the most effective activites in uncovering the defects which may later be discovered by a testing team or directly by a customer. The majority of the software organizations are now making this a part of “coding best practices” and are really increasing their product quality.

Often, a self-review of the code helps reduce the defects related to algorithm implementations, incorrect logic or certain missing conditions. Once the developer feels they are ready with the module code, a glance through the code and understanding what it does compared to what it is supposed to do, would complete the self-review.

Peer review is similar to self-review in terms of the objective – the only difference is that it is a peer (someone who understands the functionality of the code very well) who reviews the code. The advantage is that of a “fresh pair of eyes.”

3. Defect Logging and Documentation

Effective defect tracking begins with a systematic process. A structured tracking process begins with initially logging the defects, investigating the defects, then providing the structure to resolve them. Defect analysis and reporting offer a powerful means to manage defects and defect depletion trends, hence, costs.

A defect logging tool should document certain vital information regarding the defect such as:

• Correct and complete description of the defect – so that everyone on the development team understands what it is and how to reproduce it.
• Phase at which it is found – so that preventive measures can be taken and propagation of the defect to next phase (software build) is avoided.
• Further description of the defect by screenshots.
• Names of those who uncover defects – so everyone knows who to contact for a better understanding of the defect.

4. Root Cause Analysis and Preventive Measures Determination

After defects are logged and documented, the next step is to analyze them. Generally the designated defect prevention coordinator or development project leader facilitates a meeting to explore root causes.

The root cause analysis of a defect is driven by three key principles:

• Reducing the defects to improve the quality: The analysis should lead to implementing changes in processes that help prevent defects and ensure their early detection.
• Applying local expertise: The people who really understand what went wrong are the people present when the defects were inserted – members of the software engineering team. They can give the best suggestions for how to avoid such defects in the future.
• Targeting the systematic errors: There may be many errors or defects to be handled in such an analysis forum; however, some mistakes tend to be repeated. These systematic errors account for a large portion of the defects found in the typical software project. Identifying and preventing systematic errors can have a big impact on quality (in terms of defects) for a relatively small investment.

With these guidelines, defects are analyzed to determine their origins. A collection of such causes will help in doing the root cause analysis. The defects are classified based on their types. A Pareto chart is prepared to show the defect category with the highest frequency of occurrence – the target. An example of defect classification in a Pareto chart is shown in Figure 4.

Figure 4: Example of Defect Classification in a Pareto Chart

Root cause analysis is the process of finding and eliminating the cause, which would prevent the problem from recurring. Finding the causes and eliminating them are equally important.

Each defect category and the causes making those defects happen can be represented using a cause-and-effect diagram, as shown in Figure 5.

Figure 5: Cause-and-Effect Diagram for a Defect

The cause-and-effect diagram, also known as a fishbone diagram, is a simple graphical technique for sorting and relating factors that contribute to a given situation. A team usually develops the cause-and-effect diagram in a facilitated brainstorming session. Once the root causes are documented, finding ways to eliminate them requires another round of brainstorming. The object is to determine what changes should be incorporated in the processes so that recurrence of the defects can be minimized.

5. Embedding Procedures into Software Development Process

Implementation is the toughest of all activities of defect prevention. It requires total commitment from the development team and management. A plan of action is made for deployment of the modification of the existing processes or introduction of the new ones with the consent of management and the team. Some of the other activities in this phase of defect prevention are:

• Monthly status of the team should mention the severe defects and their analyses.
• Fortnightly or monthly (based on the project schedule) meetings to make the team aware of the systematic errors/defects, their symptoms and solutions.
• Embedding the defect prevention measures in software development life cycle processes.
• Learning from the previous project’s root cause analysis of defects should be used as the baseline for future projects.
• Monitoring the defect prevention progress. Is the number of defects decreasing? Is the development team learning from past mistakes?

Finally, defect prevention is not an individual exercise but a team effort. The software development team should be striving to improve its process by identifying defects early, minimizing resolution time and therefore reducing project costs.

Conclusion: Beyond ‘To Err Is Human’

To err is human but defect prevention practices enhance the ability of software developers to learn from those errors and, more importantly, learn from the mistakes of others. The benefits of implementing a defect prevention methodology are:

• Improved checklist for product quality
• Reduced rework effort
• Significant reduction the number of defects and their severity
• Better communication among the project team and upper management
• More optimized resource planning

·          understand and can speak to the larger context of the project,

·          develop together a common vision and set of goals for the project which encompass all aspects (not just software, or implementation, or customer relations, but all aspects together),

·          have a common understanding of the current status of the project,

·          maintain direction and movement toward their goals,

·          avoid becoming too narrow in their focus by concentrating on a single area of responsibility.

Method

Schedule and conduct weekly team meetings according to the project hierarchy.  On a small project with a small project team there might need to be only one such meeting each week.  On a larger project, Project Managers should hold weekly team meetings with their Team Leaders and Team Leaders should hold similar weekly team meetings with their team members.

Conduct meetings in person, preferably, or via a conference phone‑call, if necessary (for example, with remote teams). Adhere to a standard meeting time and place.  Make sure that everyone does everything they can to attend the meeting.  If someone is off on a business trip or working off site, include them via a conference call if at all possible.  Don’t be too quick to accept excuses (there are always seemingly valid reasons for not attending the meeting) or any suggestion that a weekly meeting is a waste of time.  The chairperson is at fault if the meeting is not run as efficiently or as effectively as it should be.

Use the meeting technique to plan for, schedule, and conduct an effective and efficient meeting.  Do not allow the meeting to be used to ask questions or hold discussions which are of interest to only a small number of the participants.

Meeting technique

Arrange to have individual status reports distributed and read by team members in advance of each meeting.

Use a standard agenda for each meeting, including the following:

·          individual status – goals and accomplishments,

·          issues for discussion and resolution (e.g., problems or risks arising from team status or raised by team members),

·          outstanding decision requests, change requests, and fault reports,

·          quality metrics and trends,

·          summary of action items.

Have each person provide a brief status update, highlighting his or her three (maximum of five) most significant accomplishments or events over the past week and the three (maximum of five) most significant items that they or their team realistically plan to accomplish next week.  Make sure that each person focuses on what the others need to know about each area of responsibility. Do not allow anyone to simply list what they or their team members are continuing to work on, or to get into long detailed explanations.

Make sure that everyone saves editorial comments, questions, or issues for a systematic and focused question and answer period when all presentations are complete.  As soon as an item does not need further discussion as a group, or cannot be resolved in the meeting, assign it for follow up to the individual responsible, as appropriate. 

Review the status and impact of all outstanding Decision Requests, Change Requests, and Fault Reports, as appropriate.

Follow-up on risk items in accordance with the risk management technique.

Risk Management

Give each participant a final opportunity to raise any of the following:

·          issues (e.g., interfaces between components, items not followed‑up),

·          requests for advice (e.g., “can you suggest a way to …?”),

·          problems (e.g., items not being tested correctly at the unit level),

·          warnings (e.g., potential slippages to schedules, and dates),

·          suggestions (e.g., to improve the processes being used by the team),

·          compliments (e.g., “great job …”).

Conclude the meeting by summarizing the action items and record, communicate, and track all action items to completion. See also:

Manage Action Items

Prepare a brief, action-oriented set of meeting minutes, summarizing the decisions reached, along with a brief explanation for why each decision was made, to preserve the “collective memory” of the project. Distribute the minutes to the participants and file the minutes on the team’s LAN or in the Project Book.

Prepare Individual Status Reports

Have each team member use the standard template or equivalent (e.g., Checkpoint) to prepare a Weekly Status Report. Make sure that each report is brief (point form), focused on the key information to be communicated, and directly related to the team member’s scheduled activities as defined in his or her Project Tracking Document.

Sit down with each team member to go over his or her Weekly Status Report, identify and resolve any variances from plan, assess the team member’s continuing commitment, and review whether there are any new risk factors present.  Use constructive criticism to help the individual improve his or her performance if necessary.  Apply risk management to any new risks that may have been identified.

            Constructive Criticism

            Risk Management

Prepare Summarized Team and/or Project Status Reports

Summarize all individual reports to the team or project level to provide key accomplishments, objectives, and problems (if any) for the week. Attach statistics and/or charts or configuration management reports showing the screen, report and function counts to provide a quantitative view of progress.  Include with the summarized report updated versions of each of the following (as appropriate):

            Project Tracking Summary Report,

            Risk Management Log,

            Change Request Log,

            Decision Request Log,

            Fault Report Log.

Distribute and Follow-Up Status Reports

Distribute the summarized Project Weekly Status Report and attachments to project team members, and file these on the team’s LAN or in the Project Book.  Retain the latest four status reports in the Project Book and archive previous reports in the project files.

Walk-through the summarized Project Weekly Status Report and attachments with the Delivery Line Manager and the Acceptor. Formally record and manage the action items that result and track them through to closure.