What is a review and what is the role it plays in the software development process?

Reviews give support to a software whether it is good or bad and thus, making it easier for people to judge whether the program is the right choice for them or wrong. As far as a program is concerned, it is improved with only those new extensions which have been reviewed properly. Otherwise, these extensions are marked as “unsupported”. If the extensions have been reviewed they are marked as “stable and supported” and added to the official directory. Reviewing is an important method or strategy for making a software application or a program even more dependable and secure. Reviewing can be defined as a process of self regulation and evaluation by a team of professionals and qualified individuals in that particular field. Reviewing is essentially needed to know pros and cons of the program and to improve it’s performance, and to maintain the standard of the software application. Reviewing also provides the program with some sort of credibility.
Reviews can be classified into many types depending upon the field of activity and the profession involving that particular activity. Peer review is commonly known as software review in the field of computer science and development. Software reviewing is a process in which a software product like a source code, program or a document is first examined and checked by its author and then by his/ her colleagues (who are essentially professionals in that field) and qualified individuals for evaluating the quality of the proposed software product. According to the capability maturity model, its purpose is to spot and correct flaws and errors in software applications or programs and thus preventing them from causing any trouble during operation. Reviewing is a part of software development process and it is used as tool to identify flaws and correct them as soon as possible so as to avoid potential errors. Reviewing is necessary as it saves a trouble by identifying problems early during requirements testing otherwise which would have been a hectic problem to fix during software architecture testing.
Software reviews are different from other kind of reviews. Software review processes involve the following activities:
1. Buddy checking (unstructured activity) and formal activities like:
2. Technical peer reviews
3. Walk through
4. Software inspections.
Software reviewing is now considered as a part of computer science and engineering. If there are reviewers; less difficult it becomes to solve a problem. But even though, there may be many reviewers and researchers, it is still difficult to find out every single and small flaw in a huge work piece. But reviewing always improves the work and identifies the mistakes. Reviewers and the review process are in demand because of basically three reasons.
Firstly, the workload of review cannot be directly handled by the team of developers. Even if each individual contributes his/ her all time it won’t be enough.
Secondly, even though the reviewers work as a team to find out mistakes, they put out their own opinions about the program.
Thirdly, a reviewer cannot be considered equal to an expert in all the fields concerning that program.
So having more reviewers to review a software artifact becomes necessary. The names and identity of the reviewers is kept secret to avoid unnecessary criticism and cronyism. Reviewing leads to great improvement in the quality of the software product, readability of the program code, identification of missing and incorrect references, identification of statistical errors and also the identification of scientific errors. Software reviewing is like a filter which filters out the program in its best form to the benefit of the users.

Some great books explaining software reviews:
1. Best Kept Secrets of Peer Code Review: Modern Approach. Practical Advice
2. Software Engineering Reviews and Audits
3. Peer Reviews in Software: A Practical Guide

Performing User Interface Design - Design Evaluation

Design should be evaluated to check whether it meets the user needs or not once an operational user interface prototype has been created. Evaluation spans a formality spectrum that ranges from an informal test drive in which a user provides an impromptu feedback to a formally designed study.

- After design model has been completed, a first level prototype is created.
- Prototype is evaluated by user.
- User provides designer with direct comments about the efficacy of interface.
- Evaluation cycle continues until no further modifications to interface design are necessary.
- Once first prototype is built, designer collects a variety of qualitative and quantitative data that will assist in evaluating the interface.
- Qualitative data includes questionnaires like simple yes/no, numeric response, scaled response, likert scales, percentage response or open ended.
- Quantitative data can be got by a form of time study analysis can be conducted.

The evaluation criterion applied during early design reviews are:
- length and complexity of written specification of the system.
- number of user tasks specified and average number of actions per task.
- number of actions, tasks, and system states indicated by the design model imply memory load.
- interface styles, help facilities, and error handling protocol provides an indication of interface complexity.

Verification Strategies - Reviews - Design Review and Code Review

Design Review: A process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include critical design review, preliminary design review and system design review.Quality assurance team member leads design review. members from development team and QA team participate in the review.

Input Criteria: Design document is an essential document for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewers comments and suggestions and the re-verification whether they are incorporated in the documents.

Code Review: A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. QA team member(in case the QA team is only involved in black box testing then the development team lead chairs the review team) leads code review. Members from development team and QA team participate in the review.

Input Criteria: The Coding Standards Document and the Source file are the essential documents for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewer's comments and suggestions and the re-verification whether they are incorporated in the documents.