Pass the Software Certifications Software Certification CSQA Questions and answers with ExamsMirror

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 which does not properly implement its requirements, which does not function as the programmer intended, or which 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.

Nominal Data

This data can be categorized. For example, a program can be classified as database software, operating system, etc. Nominal data cannot be subjected to arithmetic operations of any type, and the values cannot be ranked in any "natural order." The only possible operation is to determine whether something is the same type as something else. Nominal data can be objective or subjective, depending on the rules for classification.

Ordinal Data

This data can be ranked, but differences or ratios between values are not meaningful. For example, programmer experience level may be measured as low, medium, or high. For ordinal data to be used in an objective measurement the criteria for placement in the various categories must be well defined; otherwise, it is subjective.

Interval Data

This data can be ranked and can exhibit meaningful differences between values. Interval data has no absolute zero, and ratios of values are not necessarily meaningful. For example, a program with a complexity value of 6 is four units more complex than a program with a complexity of 2, but it is probably not meaningful to say that the first program is three times as complex as the second. T.J. McCabe’s complexity metric is an example of an interval scale.

Ratio Data

This data has an absolute zero and meaningful ratios can be calculated. Measuring program size by LOC is an example. A program of 2,000 lines can be considered twice as large as a program of 1,000 lines, and programs can have zero length.

Developing a cause-and-effect diagram requires this series of steps:

1. Identify a problem (effect) with a list of potential causes. This may result from a brainstorming session.

2. Write the effect at the right side of the paper.

3. Identify major causes of the problem, which become “big branches”. Six categories of causes are often used: Measurement, Methods, Materials, Machines, People, and Environment, but the categories vary with the effect selected.

4. Fill in the “small branches” with subcauses of each major cause until the lowestlevel subcause is identified.

5. Review the completed cause-and-effect diagram with the work process to verify that these causes (factors) do affect the problem being resolved.

6. Work on the most important causes first. Teams may opt to use the nominal group technique or Pareto analysis to reach consensus.

7. Verify the root causes by collecting appropriate data (sampling) to validate a relationship to the problem.

8. Continue this process to identify all validated causes, and, ultimately the root cause.

Size

LOC is the most common way of quantifying software size; however, this cannot be done until the coding process is complete. Function points have the advantage of being measurable during the design phase of the development process or possibly earlier.

Lines of Code

This is probably the most widely used measure for program size, although there are many different definitions. The differences involve treatment of blank lines, comment lines, nonexecutable statements, multiple statements per line, multiple lines per statement, and the question of how to count reused lines of code. The most common definition counts any line that is not a blank or a comment, regardless of the number of statements per line. In theory, LOC is a useful predictor of program complexity, total development effort, and programmer performance (debugging, productivity). Numerous studies have attempted to validate these relationships.

Function Points

J. Albrecht proposed a metric for software size and the effort required for development that can be determined early in the development process. This approach computes the total function points (FP) value for the project, by totaling the number of external user inputs, inquiries, outputs, and master files, and then applying the following weights: inputs (4), outputs (5), inquiries (4), and master files (10). Each FP contributor can be adjusted within a range of ±35% for a specific project complexity.

Complexity

More metrics have been proposed for measuring program complexity than for any other program characteristic. Two examples of complexity metrics are:

Cyclomatic Complexity -- v(G)

Given any computer program, draw its control flow graph, G, where each node corresponds to a block of sequential code and each edge corresponds to a branch or decision point in the program. The cyclomatic complexity of such a graph can be computed by a simple formula from graph theory, as v(G)=e-n+2, where e is the number of edges, and n is the number of nodes in the graph.

Knots

Calculate program knots by drawing the program control flow graph with a node for every statement or block of sequential statements. A knot is defined as a necessary crossing of directional lines in the graph. The same phenomenon can be observed by drawing transfer-of control lines from statement to statement in a program listing

There is a high correlation between process maturity and cycle time. As shown in the figure below, as processes mature, there is a decrease in the cycle time to build software products. The maturity of processes, people, and controls has associated with it a search for the root cause of problems. It is these problems that lead to rework which, in turn, extends the cycle time. Thus, improvements also focus on facilitating transitions of deliverables from work task to work task, which also significantly reduces cycle time.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 12.47.42 PM.png

Level 1 – Constraint Requirements

This level involves staffing, budget, and schedule. The business requirements are frequently defined as a set of objectives described on several pages of narrative description. Thus, it becomes the role of the project team to expand the initial definition and build the software. However, management and the end user of the software will manage more by the constraint requirements than by the business requirements. The result is that the software put into production on the scheduled date may miss many key requirements, which will need to be installed after the operational date but under new budgets and schedules.

Level 2 – Business Requirements

This level places its emphasis on the functional and operating requirements. Level 2 establishes the criteria that the deliverables must meet in order to be accepted by the end user. At this level, standards are established for the requirements document which specifies the totality of requirement attributes that must be included for the requirements to be considered complete. These often include defining how the requirements will be tested, the objective of therequirement, the problem that the requirement is designed to solve, a detailed description of the requirement, and how the requirement is related to the objectives to be accomplished. Many information organizations at this level introduce uniquely identifying requirements, and then utilize processes that trace requirements through the entire software-building process.

Level 3 – Relational Requirements

This level emphasizes relationships within an information system and between information systems. Level 2 defines relationships, but normally at a much lower level than Level 3. Level 2 relationship specifications tend to be within an individual application system. Level 3 relationships focus on organizational databases, processing sequences and priorities, intersystem relationships, and processing cycle relationships. Data relationships help eliminate data redundancy and help assure consistency of use of data throughout an organization. Processing relationships address processing priorities and processing sequences. The system relationships deal with interfaces between systems and changes to systems. The larger challenge is assuring that all systems are changed concurrently when they are impacted by a common change(s). The processing cycle or timing relationship assures that all data that belongs in a particular accounting processing cycle is processed during that cycle.

Level 4 – Quality Requirements

Quality requirements are the characteristics surrounding the functional requirements that facilitate end user satisfaction. An example of quality requirements is ease of use. The functional requirements deal with the data specified for a particular product, but if it is very difficult to use (i.e., not meeting the quality ease of use requirement); the end user tends to be dissatisfied.

Level 5 – Reliability Requirements

Reliability primarily deals with mean time between failures. To achieve reliability requirements necessitates building a database of processing information and performing adequate statistical analysis on that data. Then a statistical prediction of reliability can be made. While the end user needs to specify reliability requirements, they can only be measured and achieved through the use of statistical tools. Figure 44 shows the best practices for deliveries process.

Management Tools

These tools are based on logic rather than mathematics, to address idea generation and organization, decision-making and implementation. The examples are brainstorming and affinity diagram.

Statistical Tools

These tools have a mathematical focus, usually related to data collection, organization, or interpretation. They may also be separated into tools used for counting and tools used with measures. The examples are check sheet and histogram.

Presentation Tools

These tools are used during presentations to summarize or graphically illustrate data. These tools may be used in the development of written materials, such as proposals or reports, or to accompany oral presentations. The examples are table and line chart.

Generally, a SLA should contain clauses that define a specified level of service, support options, incentive awards for service levels exceeded and/or penalty provisions for services not provided. Before having such agreements with customers the IT services need to have a good quality of these services, Quality management (link is external) will try to improve the Quality of service (link is external), whereas the SLAs will try to keep the quality and guarantee the quality to the customer.

Typical Service Level Agreement Contents:

Services Delivered

Performance

Problem Management

Customer Duties

Warranties & Remedies

Security

Disaster Recovery

Termination

LOC is the most common way of quantifying software size; however, this cannot be done until the coding process is complete. Function points have the advantage of being measurable during the design phase of the development process or possibly earlier.

J. Albrecht proposed a metric for software size and the effort required for development that can be determined early in the development process. This approach computes the total function points (FP) value for the project, by totaling the number of external user inputs, inquiries, outputs, and master files, and then applying the following weights: inputs (4), outputs (5), inquiries (4), and master files (10). Each FP contributor can be adjusted within a range of ±35% for a specific project complexity.

Some guidelines for selecting and sequencing change approaches are:

Select approaches that are most acceptable to the culture (poor approaches that are acceptable may be more effective than optimal approaches that are resisted).

Select approaches that have the highest probability of success, first.

Select approaches that will provide both short-term and long-term results. Select an implementation strategy that will use the best people and the best projects, as opposed to trying to improve the poorest projects with the least effective staff.

Implement the prerequisites to the approach before implementing the approach.

Use tools such as risk ranking, analysis, or return on investment.

To map processes, executive management (Quality Council) must have identified the organization's mission, long and short-term goals, organizational structure, and deliverables. If formal strategic planning is not regularly performed, identifying an organization's mission and goals is difficult.

Processes should be mapped to mission and goals, to functional units (people), and to deliverables in separate matrices. The following generic process can be used for each mapping:

1. Create a matrix.

2. List processes across the top of the matrix.

3. On the left side of the matrix, list the goals, functional units or roles or deliverables.

4. Identify the linkages between the rows and columns, as follows:

A process may support multiple goals. Put an X in the intersection to acknowledge a linkage only if the stability or quality of the process could influence meeting goals. If all processes contribute to all goals, decompose the mission and goals further. The resulting Manage-by-Process matrix is a process map.

Processes have primary owners, suppliers and customers. Identify a linkage in this matrix by using “O”, “S” or “C” in the intersection to distinguish between the roles.

Deliverables can be internal such as design specifications, or external such as user manuals. In this matrix indicate the usage of the deliverable by placing a “C”, “R”, “U” and/or “D” in the intersection. “C” is used when the deliverable is created, or the service is provided through the process. “R” indicates the deliverable is referenced or used as input to the process. “U” indicates the deliverable is updated or revised in the process. “D” means the deliverable is deleted, or retired, etc.

5. For mission and goal mapping, look for gaps where goals are not supported by processes. Consider removing any processes that do not support goals, as they do not add value. For functional unit mapping, look for gaps where units do not have processes. For deliverable mapping, look for gaps where deliverables do not have processes or vice versa.

6. If the mapping identified any new processes, add them to the inventory.