MULTIMEDIA DEVELOPING

Khanna promotes Obama's jobs-creation agenda

2010-04-18T17:06:00.000-07:00

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.

SQA Plan

2010-04-17T20:51:00.000-07:00

Software Quality Assurance Plan

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.

Software Quality Assurance

2010-04-17T20:48:00.000-07:00

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.

Hewlett-Packard software

2010-04-17T20:12:00.000-07:00

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:

Source: Grady, R. B., and D. L. Caswell, Software Metrics: Establishing A Company-Wide Program, pp. 225–226. Englewood Cliffs, N.J.: Prentice-Hall. Copyright © 1986 Prentice-Hall, Inc. Used with permission to reprint.

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/KNCSS: Self-explanatory (KNCSS—Thousand noncomment source statements).

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.

Phase: engineering months/total engineering months: Self-explanatory.

Motorola Quality Policy for Software Development

2010-04-17T20:06:00.000-07:00

Motorola:

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.

Goals

· Goal 1: Improve project planning.

· Goal 2: Increase defect containment.

· Goal 3: Increase software reliability.

· Goal 4: Decrease software defect density.

· Goal 5: Improve customer service.

· Goal 6: Reduce the cost of nonconformance.

· Goal 7: Increase software productivity.

Machine testing

2010-04-17T19:57:00.000-07:00

In-Process Quality Metrics

Because our goal is to understand the programming process and to learn to engineer quality into the process, in-process quality metrics play an important role. In-process quality metrics are less formally defined than end-product metrics, and their practices vary greatly among software developers. On the one hand, in-process quality metrics simply means tracking defect arrival during formal machine testing for some organizations. On the other hand, some software organizations with well-established software metrics programs cover various parameters in each phase of the development cycle. In this section we briefly discuss several metrics that are basic to sound in-process quality management. In later chapters on modeling we will examine some of them in greater detail and discuss others within the context of models.

Defect Density During Machine Testing

Defect rate during formal machine testing (testing after code is integrated into the system library) is usually positively correlated with the defect rate in the field. Higher defect rates found during testing is an indicator that the software has experienced higher error injection during its development process, unless the higher testing defect rate is due to an extraordinary testing effort—for example, additional testing or a new testing approach that was deemed more effective in detecting defects. The rationale for the positive correlation is simple: Software defect density never follows the uniform distribution. If a piece of code or a product has higher testing defects, it is a result of more effective testing or it is because of higher latent defects in the code. Myers (1979) discusses a counterintuitive principle that the more defects found during testing, the more defects will be found later. That principle is another expres-sion of the positive correlation between defect rates during testing and in the field or between defect rates between phases of testing.

This simple metric of defects per KLOC or function point, therefore, is a good indicator of quality while the software is still being tested. It is especially useful to monitor subsequent releases of a product in the same development organization. Therefore, release-to-release comparisons are not contaminated by extraneous factors. The development team or the project manager can use the following scenarios to judge the release quality:

· If the defect rate during testing is the same or lower than that of the previous release (or a similar product), then ask: Does the testing for the current release deteriorate?

o If the answer is no, the quality perspective is positive.

o If the answer is yes, you need to do extra testing (e.g., add test cases to increase coverage, blitz test, customer testing, stress testing, etc.).

· If the defect rate during testing is substantially higher than that of the previous release (or a similar product), then ask: Did we plan for and actually improve testing effectiveness?

o If the answer is no, the quality perspective is negative. Ironically, the only remedial approach that can be taken at this stage of the life cycle is to do more testing, which will yield even higher defect rates.

o If the answer is yes, then the quality perspective is the same or positive.

Defect Arrival Pattern During Machine Testing

Overall defect density during testing is a summary indicator. The pattern of defect arrivals (or for that matter, times between failures) gives more information. Even with the same overall defect rate during testing, different patterns of defect arrivals indicate different quality levels in the field.Data were plotted from 44 weeks before code-freeze until the week prior to code-freeze. The second pattern, represented by the charts on the right side, obviously indicates that testing started late, the test suite was not sufficient, and that the testing ended prematurely.

The objective is always to look for defect arrivals that stabilize at a very low level, or times between failures that are far apart, before ending the testing effort and releasing the software to the field. Such declining patterns of defect arrival during testing are indeed the basic assumption of many software reliability models. The time unit for observing the arrival pattern is usually weeks and occasionally months. For reliability models that require execution time data, the time interval is in units of CPU time.

When we talk about the defect arrival pattern during testing, there are actually three slightly different metrics, which should be looked at simultaneously:

· The defect arrivals (defects reported) during the testing phase by time interval (e.g., week). These are the raw number of arrivals, not all of which are valid defects.

· The pattern of valid defect arrivals—when problem determination is done on the reported problems. This is the true defect pattern.

· The pattern of defect backlog overtime. This metric is needed because development organizations cannot investigate and fix all reported problems immediately. This metric is a workload statement as well as a quality statement. If the defect backlog is large at the end of the development cycle and a lot of fixes have yet to be integrated into the system, the stability of the system (hence its quality) will be affected. Retesting (regression test) is needed to ensure that targeted product quality levels are reached.

Phase-Based Defect Removal Pattern

The phase-based defect removal pattern is an extension of the test defect density metric. In addition to testing, it requires the tracking of defects at all phases of the development cycle, including the design reviews, code inspections, and formal verifications before testing. Because a large percentage of programming defects is related to design problems, conducting formal reviews or functional verifications to enhance the defect removal capability of the process at the front end reduces error injection. The pattern of phase-based defect removal reflects the overall defect removal ability of the development process.

With regard to the metrics for the design and coding phases, in addition to defect rates, many development organizations use metrics such as inspection coverage and inspection effort for in-process quality management. Some companies even set up "model values" and "control boundaries" for various in-process quality indicators. For example, Cusumano (1992) reports the specific model values and control boundaries for metrics such as review coverage rate, review manpower rate (review work hours/number of design work hours), defect rate, and so forth, which were used by NEC's Switching Systems Division.

A was front-end loaded and project B was heavily testing-dependent for removing defects. In the figure, the various phases of defect removal are high-level design review (I0), low-level design review (I1), code inspection (I2), unit test (UT), component test (CT), and system test (ST). As expected, the field quality of project A outperformed project B significantly.

Defect Removal Effectiveness

Defect removal effectiveness (or efficiency, as used by some writers) can be defined as follows:

Because the total number of latent defects in the product at any given phase is not known, the denominator of the metric can only be approximated. It is usually estimated by:

The metric can be calculated for the entire development process, for the front end (before code integration), and for each phase. It is called early defect removal and phase effectiveness when used for the front end and for specific phases, respectively. The higher the value of the metric, the more effective the development process and the fewer the defects escape to the next phase or to the field. This metric is a key concept of the defect removal model for software development.The weakest phases were unit test (UT), code inspections (I2), and component test (CT). Based on this metric, action plans to improve the effectiveness of these phases were established and deployed.

Pollution

2010-04-17T19:50:00.000-07:00

Our surroundings, especially air, water and the delightful greenery, are extremely important for human existence, but unfortunately most of us disregard this vital fact and are responsible for polluting the environment in several ways. We pollute the air with smoke in much ways-through smoking tobacco, lighting fires here, there and everywhere, for good reasons and bad. Environment supports life forms. Without the biosphere our planet, the only one endowed with an environment that supports life, would be lifeless and desolate. Scientists have told us that the biosphere is made of a rightly balanced mixture of oxygen, nitrogen, carbon dioxide, water vapor etc. any action that disturbs this fine balance is not conductive to our welfare.

The irony is that man himself indulges in activities that tend to reduce the quantum of oxygen, increase carbon dioxide and other harmful ingredients of the air which consequently become dangerous for human existence. The pollution caused by the fantastic increase in the number of motor vehicles in larger cities has to seen to be believed.

Many times I have been a mute witness to people cutting down trees for various reasons, and shooting birds and animals for pleasure without realizing that they are doing comfortable damage to our environment. Allegation that we are ourselves responsible for spoiling the vital environment.

New life comes after ruins

2010-04-17T19:46:00.000-07:00

Every several hundred years, a great spiritual upheaval takes place during which the older changes, a universal spiritual revival starts, and a new cycle is established. Simply there comes a great spiritual and moral change in the world after every several hundred years. This revolution totally throws away the old order to the background and sets a new spiritual movement. Before this period there come disastrous earthquakes, storms, epidemics and wars which cause the death of several human beings and heavy destruction of property. Whenever incarnation is to take place, the world must be purged of all impurities to open the doors for the spiritual movement. Those who know prepare the ground for such a period.

The world at present is passing through such a period of transition of the changing of a cycle. The world under the disastrous events lie earthquake, wars etc may be compared to a patient suffering from a long standing disease necessitating an operation by surgeons who open the body to remove the disease. However painful trail this is for the poor patient such suffering is essential for the relief it will bring to his life after the removal of the disease.

All the religious scriptures speak of such a period. The masters of spiritual perfection, however, know them as a fact and some who, on special duty and mission, actually work them out.

carrer in banking

2010-04-17T19:37:00.000-07:00

No career is as satisfying as a bank service. The multiplicity of jobs one will required to handle is by itself fascinating. In banks, if one is not already deadwood, one can briskly move from one responsibility to another. It will be unrealistic to assume that banks need only living calculators. It will also be unrealistic to assume that banks need only auditors or economists. Ever since nationalization of major banks the bank is not place for those who relish early specialization. Look at the bank recruitment testing pattern. It should be clear to all the bank management wants its personnel to handle all kinds of jobs.

The accent on personnel equipped with exceptional skills of reasoning and deduction continues the assumption that bank managements wants highly intelligent young men and women with or without specialized knowledge. Logic demands that the exceptionally intelligent candidate is also equipped with language skills.

One, who assumes that the entire banking activity is more or less identical to the job of a typical cashier, will not be able to bring to the highly challenging job the skill and the intelligence which it warrants. There is no other institution where one can test his skill against concrete results. No wonder, banks are developing promotional avenues against hard performance. This, to say the least, affords self-fulfillment and self-realization.

Video Compression

2010-04-13T23:44:00.000-07:00

Video has been a major part of public consciousness for over 50 years. The emergence of the VCR and the increasing shift to use of cable television signals have created an open environment where video producers can rapidly distribute information to a larger number of consumers. The domains of video, computer systems, and communications services used to be quite distinct.

Requirements for full-motion video compression:

The MPEG standard is a generic standard designed to support a wide range of applications. This genericity places a special burden if all applications are supported by the same basic standard. To address this issue, the standard has been set up in a toolkit manner. As we noted earlier, it has been determined that, for the present, acceptable video quality can be achieved by providing a bandwidth of 1.5 Mbits/sec. a much higher bandwidth would be required for HDTV-quality video, which also includes the digital audio signal bandwidth.

The major impact of this rate is on storage as well as transmission. Both must be able to keep up with this rate for any kind of streaming operation to be successful. The typical storage media for multimedia components include CD-ROM, DAT, optical writeable disks, hard disks, and magnetic tape. It is assumed that for a wide range of applications, decompression does not happen at the point of storage; rather, It happens at either an intermediate point or the destination CPU.

Applications using MPEG standards can be symmetric or asymmetric. Symmetric applications, as defined earlier in this chapter, are applications that require essentially equal use of compression and decompression. Asymmetric applications require frequent decompression, but usually the compression is performed only once. For these applications, there is no real need for on-line input devices.

Data Elements For Multimedia Systems

2010-04-13T19:47:00.000-07:00

Facsimile:

Facsimile transmissions were the first practical means of transmitting document images over a telephone line.The basic technology,now widely used,has evolved to allow higher scanning density for better-quality fax.

Document Images:

Document images are used for storing business documents that must be retained for long periods of time or may need to be accessed by a larger number of people.Providing multimedia access to such documents removes the need for making several copies of the original for storage or distribution.

Photographic Images:

Photographic images are used for a wide range of applications such as employee records for instant identification at a security desk,real estate systems with photographs of houses in the database containing the descriptions of houses,medical case histories,and so on.

Geographic Information Systems Maps:

Known as GIS systems;maps created in a GIS system are being used widely for natural resource and wildlife management as well as urban planning.These systems store the graphical information of the map along with a database containing information relating high-lighted map elements with statistical or item information such as wildlife statistics or details of the floors and rooms and workers in an office building.

Voice Commands and Voice Synthesis:

Voice commands and voice synthesis used for hands-free operation of a computer program.Voice synthesis is used for presenting the results of an action to the user in a synthesized voice.Application such as a patient monitoring system in a surgical theater will be prime beneficiaries of these capabilities.voice commands allow the user to direct computer operation by spoken commands.

Audio Messages:

Annotated voice mail already uses audio or voice messages as attachments to memos and documents such as maintenance manuals.

Video Messages:

Video messages are being used in a similar manner to annotated voice mail.

Full-Motion Stored And Live Video:

Full-motion video started out as a very useful idea for on-line training and maintenance manuals.The capability to use full-motion stored video for electronic mail or live video for presentations and video-conferencing are important evolutionary steps.Three-dimensional video techniques are being adapted to create the concept of virtual reality.

Holographic Images:

All of the techniques so far essentially present a flat view of information.Holographic images extend the concept of virtual reality by allowing the user to get "inside" a part,such as,an engine and view its operation from the inside.

Fractals:

Fractals started as a technology in early 1980s but has received serious attention only recently.This technology is based on synthesizing and storing algorithms that describe the information.

Multimedia

2010-04-13T07:24:00.000-07:00

Hi guys.........this is my new blog.i am going to share my thoughts about multimedia developing and i wanna interact with others view on multimedia.
so keep in touch.thanks buddy.