The biotechnology and clean technology sectors could help to spur manufacturing and jobs creation in the United States, according to Ro Khanna, deputy assistant secretary for domestic operations at the Department of Commerce.
Khanna, who is traveling across the country to promote President Barack Obama's National Export Initiative, told attendees at an April 9 manufac- turing forum in Fremont, Calif., that although manufacturing has dropped from 28 percent to 11.5 percent, he was confident that these sectors would continue to grow and support high-paying jobs in the United States.
"The key is to invest in innovation, and to take advantage of global demand and increase exports," Khanna, who presented an administration grant to the city, was quoted as saying in a press release form his office. Talking about the importance of exporting in creating jobs, Khanna pointed out that "only 5 percent of American companies currently exported," and exports accounted for less than 12 percent of the U.S. gross national product. Comparatively, exports account for over 40 percent of China and Germany's GNP .
"The challenge is how to make American companies more aware of the opportunities that exist abroad for American prod- ucts," he said.
Khanna is part of the key team that includes Commerce Secretary Gary Locke and Agriculture Secretary Tom Vilsack, and aims to increase U.S. exports and boost job creation at home.
As part of the initiative, Khanna has already traveled to Des Moines; Oshkonosh, Wis.; Cleveland; Salt Lake City; and Newark, N.J., to conduct forums with the local governments on export and job creation for minority owned businesses, the press release said.
Design and Coding Standards: A set of design and coding standards need to be established. Each team member must follow these standards.
Structured Life Cycle: A Structured Life Cycle needs to be chosen and documented according to the project at hand.
Reviews: The following reviews must take place throughout the Software Life Cycle.
Requirements Reviews
Design Reviews
Peer Coding Reviews
Test Reviews
Audits: Through normal reviews, an anomaly may be spotted. In this event, an audit team is established and presented with a task and desired finding, and given resources to complete its assignment.
Review and Audit Guidelines
Reviews
qualified and available team members
resources to enable the team members to perform
predefined agenda (agenda must be established)
a clear picture of the goals of the review
Audit
qualified and available team members
resources to enable the team members to perform
a clear picture of the goals of the audit
a commitment from the developers that they will not obstruct the audit teams' search
a clout to enable the use of the finding of the audit
Documentation Standards: Documentation standards must be established and documented here.
Testing Standards: Testing standards must be established and documented here.
Verification and Validation: Verification and Validation criteria must be established and documented here.
Tools, Techniques and Methodologies: Any tools, techniques and methodologies must be stated here.
Documentation Reference: Any reference to other documentation must be stated here.
Adapted from material at Real-World Lab, Georgia Tech.
A SQA plan will be prepared for each project according to the following guidelines.
The SQA plan is developed in the early part of the project. In most cases this will be in the beginning of a quarter. It is recommended that the plan be developed in the beginning of a quarter so that it can be followed for the duration of a developer's (student's) time spent on the project. The SQA plan is to be developed along with the overall project plan. A copy of the project plan will be given and stored by the SCM group.
The SQA plan developed for the project is reviewed by senior management (the professor), the project leader, the SQA group, the customer (if possible) and other software process groups, such as the SCM group.
The SQA plan developed is placed under the control of the SCM group. The SQA plan is revised using established polices (according to configuration management) and modifications to the SQA plan must be reviewed and approved by the SQA group and senior management. Only an approved SQA plan will be used.
The SQA plan for the project will follow this format. (A description for these plans is included in appendix four).
Design and Coding Standards
Structured Life Cycle
Reviews
Audits
Review and Audit Guidelines
Documentation Standards
Configuration Management
Testing Standards
Verification and Validation
Tools, Techniques and Methodologies
Documentation Reference
The SQA plan, once approved is handed to the SCM group to be placed under configuration management.
SQA Group Activities
The SQA group is established to execute SQA activities.
The SQA group is responsible for making sure that each project follows a previously defined SQA plan (mentioned earlier). The SQA group performs random audits of each project. In order to avoid conflicts of interest, only the members of the SQA group who are not involved with the project perform the audit. Results of the audit are discussed with the full SQA group and the members of the project. Any problems that are found can be discussed and resolved at this time. If a resolution cannot be reached senior management is brought in to arbitrate.
The SQA group is responsible for providing management with information concerning adherence to the established software process. The SQA group is also responsible for providing management with information concerning defects in software products.
The SQA group is responsible for verification and validation of the software and maintaining statistics and other information regarding defects in the code.
The SQA group is expected to require at least the following resources: 1) a computer with database, spreadsheet, and word-processing software, 2) access to all documentation pertaining to the software process, 3) access to senior-management (the professor), 4) access to any revision control databases, 5) access to all requirements, design documents, and project plans.
The SQA group will need to be present (or at least represented) in all meetings regarding development plans for each project. (This will be the case since one member of each project team is a member of the SQA group.)
The SQA group will produce (through audits and questionnaires), evaluations of each project team with respect to adherence to software development policy, as well as evaluations of the quality of the software being developed.
The SQA group will monitor deviations from established policies after a solution has been implemented to verify compliance. Follow up audits may be required to verify that the problems have been solved. (This information as with all information concerning problems will be recorded in a database.) Milestone reports will be generated at each documented milestone according to the project plan.
The SQA group will be required to verify that software products meet customer requirements prior to delivery. In addition the SQA group will verify that the product meets standards. These standards are derived from the functional requirements. Any deviations will be resolved prior to release to the customer.
SQA group will provide reports on the project. These reports will be made available to all members of the team for review and comment. When appropriate, the customer should also be provided with these reports, as well as senior management.
The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built and designed. The primary purpose of this document is to standardize the policies and procedures with respect to Software Quality Assurance. This document will establish a formal written policy for handling Software Quality Assurance.
Additionally, the purpose is to provide quality software. Quality should be measured via a set of the following attributes:
Portability: the ability of the software to be transferred easily from one computer to another.
Efficiency: the ability of the software to perform with minimum use of computer resources.
Usability: the ability of the software to be easily understood and used by human users.
Testability: the ability of the software to be easily verified by execution.
Understandability: the ability of the software to be read by a software maintained.
Modifiability: the ability of the software to be revised by a software maintained.
Goals
Ensuring customer satisfaction through involvement of all employees in learning how to reliably produce and deliver quality software.
The Software Quality Assurance Group (SQAG) should provide a structured environment for all team members to work together to improve the quality of the software and promote communication and teamwork.
All Software Quality Assurance activities are planned in advance by one member from the team.
Adherence of the software products and activities to the standards, procedures, and requirements is verified objectively by individuals that are not associated with the particular project. The adherence is documented by reviews.
Affected groups and individuals are informed of software quality assurance activities and results. These reports will also be made available to include each project member, and the project leader. This notification will be done formally through the project review form.
Noncompliance issues that can't be resolved within the software project are addressed by senior management, along with the group's project leader. Communication to the project leader can be done by several methods. If there is an actual non-compliance issue, the Non-Compliance Form can be generated with the appropriate information and sent to the proper personnel. If there is a possible upcoming problem detected, then just a communiquè to the project leader can be generated.
Commitment to Perform
Team Members
Each Team Member is responsible for learning what quality in the Software Life Cycle is and how to produce quality work throughout. Quality evolves from correct requirements, design, coding and then comprehensive testing.
Oranizational Policy
Each project must follow the established written organizational policy. Reviews will be performed biweekly to ensure that all SQA functions are in place and being utilized by Projects.
Ability to Perform
Responsibility
Responsibility for Software Quality Assurance will be one member of the team.
Documentation
All documentation for the Software Quality Assurance groups will be maintained and archived for future reference. The format of the individual reports will depend on the circumstance and the situation at hand, but the reports in appendix four will be used and archived. Documentation of noncompliance issues will be provided to all project members upon completion of the audits and copies will be sent to all senior management.
Training
Team members will be made aware of their duties and responsibilities. This is one of the actions of SQA. The primary training that needs to be performed is to inform the SQA members of the policies and procedures for SQA throughout the Software Life Cycle. All objectives and activities will also be explained to the members of the SQA group. Training on the use of the tools that are to be used will be performed on an as-needed basis.
Activities Performed
The Software Quality Assurance group will work with the project during its early stages and through the quarter to establish plans, standards, and procedures that will add value to the software project and satisfy the constraints of the project and the organization's policies. By participating in establishing the plans, standards, and procedures, the Software Quality Assurance group helps ensure they fit the projects needs and verifies that these plans will be usable for performing reviews and audits throughout the software project life cycle to ensure quality.
Grady and Caswell (1986) offer a good description of Hewlett-Packard's software metric program, including both the primitive metrics and computed metrics that are widely used at HP. Primitive metrics are those that are directly measurable and accountable such as control token, data token, defect, total operands, LOC, and so forth. Computed metrics are metrics that are mathematical combinations of two or more primitive metrics. The following is an excerpt of HP's computed metrics:
Average fixed defects/working day: self-explanatory.
Average engineering hours/fixed defect: self-explanatory.
Average reported defects/working day: self-explanatory.
Bang: "A quantitative indicator of net usable function from the user's point of view" (DeMarco, 1982). There are two methods for computing Bang. Computation of Bang for function-strong systems involves counting the tokens entering and leaving the function multiplied by the weight of the function. For data-strong systems it involves counting the objects in the database weighted by the number of relationships of which the object is a member.
Branches covered/total branches: When running a program, this metric indicates what percentage of the decision points were actually executed.
Defects/LOD: Self-explanatory (LOD—Lines of documentation not included in program source code).
Defects/testing time: Self-explanatory.
Design weight: "Design weight is a simple sum of the module weights over the set of all modules in the design" (DeMarco, 1982). Each module weight is a function of the token count associated with the module and the expected number of decision counts which are based on the structure of data.
NCSS/engineering month: Self-explanatory.
Percent overtime: Average overtime/40 hours per week.
Motorola's software metrics program is well articulated by Daskalantonakis (1992). By following the Goal/Question/Metric paradigm of Basili and Weiss (1984), goals were identified, questions were formulated in quantifiable terms, and metrics were established. The goals and measurement areas identified by the Motorola Quality Policy for Software Development (QPSD) are listed in the following.
Sunday, April 18, 2010
5:06 PM
Multimedia Developing
