October 31st, 2008 chris
What do you call a review session that has continuous code reviews, builds teamwork, implements cross-training and coaching, improves the writing of codes, and do refactoring at the same time. What great savings in time, money, and effort it would have a project. This review is actually a development technique. It is a review during development and it is called Pair Programming.
Pair programming is a technique in which two programmers work simultaneously at a single computer and continuously review each others’ work. Although many programmers were introduced to pair programming as a part of Extreme Programming, it is a practice that can be valuable in any development environment. Pair programming improves the organization by ensuring that at least two programmers are able to maintain any piece of the software. Pair programming also helps programmers’ professional development, because they learn from each other.
Pair programming is like having a continuous code review, without the extra time or effort of holding individual code reviews. It encourages a redundancy among the team members, and everyone is cross-trained on various parts of the code. Junior people can more quickly learn directly from senior people when they are paired together. While it may seem that assigning two people to a single programming task could be inefficient, in fact, productivity often increases. It takes somewhat less time to perform each task, as there are often gaps where one person is “tapped out” and the other can take over. More importantly, the resulting code is of very high quality, so there are far fewer mistakes to go back and fix.
One useful benefit of pair programming is that people tend to write better code when they know that someone else will be reading it. They cut fewer corners, spend more time making the code readable, are more likely to include comments where necessary, and refactor more often.
In pair programming, two programmers sit at one computer to write code. Sometimes they share a single keyboard and mouse, although it is possible to get special hardware or cables that allow each programmer to have his own. Generally, one programmer will take control and write code, while the other watches and advises. But different pairs of people may discover their own dynamic: for example, some pairs will take turns at the keyboard, while others will designate one person as the typist (if one person types significantly faster than the other).
Posted in Reviews
October 31st, 2008 chris
Having headaches on different coding style, different developer IQ level and skills, dependence on a single person for a task or tasks, individualism and disunity of the team. Apparently, your project is going through a road to failure. To prevent being dependent on people who has the only key and having to decrypt your source code which was supposed to be simple and readable then this review is the pill to your worries, or might I say the key, Code Reviews.
A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code that does not properly implement its requirements, that does not function as the programmer intended, or that is not incorrect but could be improved (for example, it could be made more readable or its performance could be improved). In addition to helping teams find and fix bugs, code reviews are useful for both cross-training programmers on the code being reviewed and for helping junior developers learn new programming techniques.
The first task in a code review is to select the sample of code to be inspected. It’s impossible to review every line of code, so the programmers need to be selective about which portion of the code gets reviewed. Many teams have found that it takes about two hours to review 400 lines of code (in a high-level language such as Java), although this estimate differs dramatically from team to team and depends on the complexity of the code being reviewed. At that rate, there is no way a team could review all of the code for a software project. Nor would the team want toin any program, there is a good deal of uninteresting code that looks very similar to the code already developed in previous applications, which has a lower risk of containing as many defects.
The purpose of any inspection is to find and repair defects. Since a relatively small portion of the code will be reviewed, it’s important to review the code that is most likely to have defects. This will generally be the most complex, tricky, or involved code.
There are a few useful rules of thumb that are helpful:
- Is there is a portion of the software that only one person has the expertise to maintain? That may be a good candidate for review, for two reasons. First, because the rest of the team will learn how to maintain it; second, it’s only ever been looked at by one person, so nobody else has yet had a chance to catch any defects in it.
- Does the software implement a highly abstract or tricky algorithm? The more difficult the algorithm, the more likely it is that a programmer introduced errors in its implementation.
- Is there an object, library, or API that is particularly difficult to work with? Working with a nonintuitive interface causes many programmers to make mistakes.
- Was the code written by someone who is inexperienced or has not written that kind of code before? Does it employ a new programming technique? Is it written in an unfamiliar language? A programmer who is doing something for the first time is most likely to introduce errors.
- Is there an area of the code that will be especially catastrophic if there are defects? A core tax accounting function is more important than the code that renders the splash screen. Select code that must not fail so that more people can look at itand will be able to maintain it if it does have problems.
- It is important to select a sample of code that an inspection team can review in about two hours. The project manager should try to keep the meeting to two hours or less, to avoid “meeting fatigue.”
Posted in Reviews
October 31st, 2008 chris
Understanding technical documents that you have developed is hard enough if you try to review and remember it all over again. Then think about this, try letting other people understand your documents by themselves, it is even harder if not impossible. To blend your work documents on every member’s brain of your project team and make your project successful then what you need is the black label of reviews, Walthroughs.
A walkthrough is an informal way of presenting a technical document in a meeting. Unlike other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments, and ensuring that everyone present understands the work product. It typically does not follow a rigid procedure; rather, the author presents the work product to the audience in a manner that makes sense. Many walkthroughs present the document using a slide presentation, where each section of a work product is shown using a set of slides. Work products that are commonly reviewed using a walkthrough include design specifications and use cases.
Walkthroughs are used when the author of a work product needs to take into account the perspective of someone who does not have the technical expertise to review the document. For example, a requirements analyst must make sure that the use cases she builds will provide the functionality that the users need, but the user representatives may not have seen use cases before and would be overwhelmed by them. If these users are simply included as part of an inspection team, it is likely that they will read the document and, failing to find many defects, sit silently through the inspection meeting without contributing much. This is not their fault, their training is in the business of the organization, not in reading and understanding software engineering documents. This is where a walkthrough can be a useful technique to ensure that everyone understands the document.
Posted in Reviews
October 31st, 2008 chris
There are work products that do not benefit enough to warrant the attention of a full formal review because they do not need consensus or approval. If you have this type of work products and simply needs input from others to prevent defects, but does not require that they approve the document then what you need is a deskcheck.
A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. In a deskcheck, the author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author. Work products that are commonly reviewed using a deskcheck include vision and scope documents and discussion summaries.
Deskchecks can be used as predecessors to inspections. In many cases, having an author of a work product pass his work to a peer for an informal review will significantly reduce the amount of effort involved in the inspection. Many defects can be caught by a single person reviewing a document. Approval and consensus is built later on during the inspection meeting; this is simply a way of saving effort. After a deskcheck, many authors will feel much more comfortable sending their document into an inspectionit will often help the author to be more objective and to take the inspection comments less personally.
Posted in Reviews
October 31st, 2008 chris
Most project managers have seen their projects get delayed because of scope creep and unnecessary work caused by changes that, had they been caught earlier, would have required much less work to fix. One of the most common complaints from project team members is that they would have built the software differently had they been given a better understanding of what was needed from the beginning. One important root cause of these problems is defects in work products that are not caught until long after those work products have been used as the basis for later project activities.
A solution for these problems is doing inspection reviews. An inspection is one of the most common sorts of review found in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. Commonly inspected work products include software requirements specifications and test plans. In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document that an inspector disagrees with. The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product.
Inspections are easy to implement, and have an immediate effect on quality and consensus-building. A small team spending a few hours inspecting a work product will catch errors that could potentially save weeks, or even months, of wasted effort. An effective inspection requires a well-chosen team, a moderator who is able to run the meeting, and an author who is willing to listen to criticism and fix the work product being inspected.
Posted in Reviews
October 31st, 2008 chris
Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project management is accomplished through the application and integration of the project management process of initiating, planning, executing, monitoring and controlling, and closing. The project manager is the person responsible for accomplishing the project objectives.
Managing a project includes:
- Identifying requirements
- Establishing clear and achievable objectives
- Balancing the competing demands for quality, scope, time and cost
- Adapting the specifications, plans, and approach to the different concerns and expectations of the various stakeholders.
Posted in Project Management
October 31st, 2008 chris
The related process area section lists references to related process areas and reflects the high-level relationships among the process areas. The related process area section is an informative component.
An example of a reference found in the related process area section of the Project Planning process area is “Refer to the Risk Management process area for more information about identifying and managing risks.”
Posted in CMMI
October 31st, 2008 chris
The introductory notes section of the process area describes the major concepts covered in the process area and is an informative component.
An example from the introductory notes of the Project Planning process area is “Planning begins with requirements that define the product and project.”
Posted in CMMI
October 31st, 2008 chris
The purpose statement describes the purpose of the process area and is an informative component.
For example, the purpose statement of the Organizational Process Definition process area is “The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.”
Posted in CMMI
October 31st, 2008 chris
There are twelve model components of CMMI and they are the following:
- Process Areas
- Purpose Statements
- Introductory Notes
- Related Process Areas
- Specific Goals
- Generic Goals
- Specific Goal and Practice Summaries
- Specific Practices
- Typical Work Products
- Subpractices
- Generic Practices
- Generic Practice Elaborations
Posted in CMMI