Ieee Ses
Ieee Ses
Ieee Ses
The following standards are those a tester should be aware of, and include a short abstract about each one:
1012a-1998: IEEE Standard for Software Verification and Validation (Supplement to 1012-1998 –
Content Map to IEEE 12207.1)
The 2 requirements (1012 and 12207.1) place requirements on plans for verification of software
and validation of software. The purpose of this annex is to explain the relationship between the two sets of
requirements, so that users producing documents intended to comply with both standards may do so.
Framework: Software Quality is the degree to which Software possesses a desired combination of
quality attributes. The purpose of Software Metrics is to make assessments throughout the Software Life
cycle as to whether the Software Quality requirements are being met. The use of software metrics reduces
subjectivity in the assessment and control of software quality by providing a quantitative basis for making
decisions about software quality. However the use of Software Metrics does not eliminate the need for
human judgment in Software assessments. The use of software metrics within an organization or project
is expected to have a beneficial effect by making software quality more visible.
Other External Standards
The use of standards simplifies communication, promotes consistency and uniformity, and eliminates the
need to invent yet another (often different and even incompatible) solution to the same problem.
Standards, whether ‘official’ or merely agreed upon, are especially important when we’re talking to
customers and suppliers, but it’s easy to underestimate their importance when dealing with different
departments and disciplines within an organization. They also provide vital continuity so that we are
within our own organization. They also provide vital continuity so that we are not forever reinventing the
wheel. They are a way of preserving proven practices above and beyond the inevitable staff changes
within organizations.
Some standards are particularly important to the testing practitioner. They can provide a
benchmark for writing documents like requirements, so that testers and others doing verification have a
framework for what they can expect to find. More specifically, standards tell us what to put into key test
documents, such as a test plan.
Standards are not only practical from the development point of view, but they are increasingly the
basis for contracts and therefore also, when things go wrong, for litigation. One of the issues that arise in
litigation is whether the software was developed according to known standards that are prevalent in the
industry today. This means we need to know not only what the standards are, but to also see that they are
applied.