Clauses of ISO 9001
Clauses for ISO 9126:
A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. This set of attributes characterizes what the software does to fulfill needs, whereas the other sets mainly characterize when and how it does so. The sub-characteristics include:
A set of attributes that bear on the effort needed for use and on the individual assessment of such use, by a stated or implied set of users.
“Users” may be interpreted as most directly meaning the users of interactive software. Users may include operators, and users and indirect users who are under the influence of or dependent on the use of the software. Usability must address all of the different user environments that the software may affect, which may include preparation for usage and evaluation of results.
Usability defined in this International Standard as a specific set of attributes of a software product differs from the definition from an ergonomic point of view, where other characteristics such as efficiency and effectiveness are also seen as constituents of usability.
A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. The sub-characteristics include:- -Maturity
– Fault tolerance
A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.
The sub-characteristics include:
– Time behavior
– Resource behavior
A set of attributes that bear on the effort needed to make specified
modifications. The sub-characteristics include:
A set of attributes that bear on the ability of software to be transferred
from one environment to another. The sub-characteristics include:
2.Software Configuration Management is how you control the evolution of a software project. Slightly more formally, software configuration management (SCM) is a software-engineering discipline comprising the tools and techniques (processes or methodology) that a company uses to manage change to its software assets.
Seven key management practices enhance the success of a configuration management system:
Maintain a unique read-only copy of each release: After each release, the configuration manager should label the entire code base with an identifier that helps to uniquely identify it. Alternatively, a configuration management tool can automatically name each release using one of many defined schemes.
Control the creation, modification, and deletion of software artifacts following a defined procedure. A defined procedure should identify every item that an organization uses to make every work product (e.g., compilers), regardless of the type of work product – code or documentation. Control procedures should also identify who can create, alter, and delete a software artifact and under what conditions.
Create a formal approval process for requesting and approving changes. A formal approval process should identify who has responsibility for accepting a change request and allocating the work. It should also identify the evaluation criteria that determine the requests that an organization will perform, as well as how it prioritizes them. The approval process should require the requestor to produce documentation that the development or maintenance team may need, the reason for the change, and a contingency plan.
Use change packages. A change package defines a unit of work, whether it is the repair of a defect, the addition of a new feature or capability to a system, or an original development activity. Consequently, a change package should be traceable to a planned activity of a work plan or schedule. If it is not, the schedule is not an accurate reflection of the work a team is performing or when the team is performing it. The benefit of using change packages is that they aggregate collections of individual, yet related, changes, which helps to control the instability within a software system.
Use shared build processes and tools. It is rare that individual members of a project team use different build processes or tools. When they do, the results are often inconsistent and difficult to debug. Thus, an organization should avoid such an approach.
A version manifest should describe each software release. A version manifest should identify all components that comprise a release, all open and closed problems, the differences between versions, relevant notes and assumptions, and build instructions.
Segregate derived artifacts from source artifacts. Source artifacts are works created by an author. Derived artifacts are those artifacts that result from processing source artifacts. For example, a binary object file is the result of compiling a source file written in a programming language. Work products, on the other hand, may be source artifacts, but they may also be derived objects. Work products are those products that an organization delivers to a customer or some end user or uses to develop a product. Delivered work products are those work products actually delivered to a customer, whether they are source or derived objects. If possible, an organization should separate these different categories of artifacts to ease their management.
The purpose of reliability testing is to determine product’s reliability, and to determine whether the software meets the customer’s reliability requirements. In the system test phase or after the software is fully developed, one reliability testing technique is a test/ analyze/ fix technique, where we couple reliability testing with the removal of faults. When any failure is found, then it will send back to developers to repair. The developer builds another new version of the software and again another test iteration is carried out.
Here in online book store reliability is tested through checking functionalities like search book by category, allow access to users by admin, admin functionalities like add or delete book category, add or delete member, manage member orders, add or delete credit card type.
Compatibility testing is used to measure how well your software application or hardware device functions in concert with relevant hardware, software, operating systems or network environments.
Your internal QA department has done all it can to ensure that your product functions as designed. Your product is nearing completion, and the release deadline is rapidly approaching. Your application functions on all of your in-house computers, but what about the myriad of computer systems of your target users? Nothing upsets your customers more than breaking open that shrink-wrap (or downloading the software from your site) only to find that a conflict exists with the software or hardware they already have installed on their computer, rendering your product inoperable. Website, browser, or software compatibility testing can help you avoid this dangerous and expensive pitfall.
Here it will test by checking some validations like text limitation for contact no, credit card types, language choice and so on.
It basically defines that how easy it is to maintain the system. This means that how easy it is to analyze, change and test the application or product.
Maintainability testing shall use a model of the maintainability requirements of the software/system. The maintainability testing shall be specified in terms of the effort required to effect a change under each of the following four categories:
- Corrective maintenance – Correcting problems.
The maintainability of a system can be measured in terms of the time taken to diagnose and fix problems identified within that system. Suppose after some time admin needs to add some books, then modification to the software should be done in correct manner.
- Perfective maintenance – Enhancements.
Suppose in our system we need to modify the database then how it will test the maintainability? So for that by recording the time taken to achieve a new piece of identifiable functionality such as a change to the database, etc. A number of similar tests should be run and an average time calculated. The outcome will be that it is possible to give an average effort required to implement specified functionality. This can be compared against a target effort and an assessment made as to whether requirements are met.
- Adaptive maintenance – Adapting to changes in environment.
The maintainability of a system can also be measured in terms on the effort required to make required adaptations to that system. This can be measured in the way described above for perfective maintainability testing.
- Preventive maintenance – Actions to reduce future maintenance costs. This refers to actions to reduce future maintenance costs.
In Usability Testing, a small-set of target end-users, of a software system, “use” it to expose usability defects. This testing mainly focuses on the user’s-ease to use the application, flexibility in handling controls and ability of the system to meet its objectives.
Suppose time and cost is increased from the target which is given by the customer then again the online book store application is again experimented and try to decrease time and cost..We will try to meet the customer’s satisfaction.