Skip to main content

Quality Assurance in Software Development Life Cycle

Quality Assurance is a set of activities keeping in check the quality of a product. In software industry following are some of the some of the aspects used for assessing the quality of the product and the process model adopted for developing the product:

  • The quality of code:
    • Code cohesion is minimal
    • Code coupling is minimal
    • Lower rate of fault detection
    • Code is understandable
    • Code is reusable
    • Minimal cyclomatic complexity
    • Minimal design complexity
  • The quality of the process model adopted:
    • Minimal or no communicational gap
    • Minimal software development effort required
    • Minimal software testing effort required
    • Improved productivity in the organization
    • Minimal development cost
    • Delivery of the product or a part of the product is according to the agreed upon schedule
To achieve the above quality factors following are some of the quality assurance practices being adopted in various software development process models:
  1. Refactoring of Code: It is a process of making changes to the existing set of code without having to change its behavior. Following are some of the techniques used for refactoring the code:
    • Composing methods i.e. breaking down complex and large functions into smaller chunks reducing the complexity of such functions.
    • Safely moving the functionality between the classes and creating new classes while hiding the implementation details from the public.
    • Organizing data i.e. data handling, replacing primitives with rich class functionalities.
    • Simplifying complex conditional expressions.
    • Simplifying complex method calls.
    • Dealing with generalization.
  2. Iterative development of the product
  3. Continuous software product testing. This requires testing the developed software product both during its development phase and after the completion of its development. Following are some of the testing types used for testing the software:
    • Unit testing: This particular type of testing requires testing of the software unit developed. Each unit developed the software undergoes individual testing to ensure accurate functionality of the unit itself.
    • Integration testing: It requires the testing of the software units after their integration forming a group ready for a test.
    • System testing is a testing of a complete software after its development.
    • Acceptance testing: This process tests the system for its acceptance by the customer.
  4. Enforced teamwork.
  5. Enforced collective ownership. This requires that distribution of the software development responsibility for a number of people rather than making it one individual's responsibility.
  6. Involvement of customer enforced throughout the development of the software product.
  7. Adopting coding standards during the implementation of the software design.
  8. Use of system metaphors for improving the understandability of the software product being developed. This requires relating the software entities to something familiar.
  9. Implementation of Change Control in a software being developed.

Comments

  1. I curious more interest in some of them hope you will give more information on this topics in your next articles. Software Engineering

    ReplyDelete

Post a Comment

Popular posts from this blog

Software Architecture Views and Structures

Description of Views: In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views: Logical Development Process Physical Scenario Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures: Views Sub-View of Description Logical None Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture. Development None It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective. Process None It deals with the representation of...

Overview of MISRA C++ (2008)

Introduction Software to Control Autonomous Car MISRA C ++ is a software development standard for C and C++ programming language that aims to facilitate code portability and reliability in the context of embedded systems, specifically those systems programming in ANSI C. Its mission is:  “   To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software ” MISRA - A Brief History In 1998 MISRA targeted only the automotive industry but later released it focus on generic rules for developing safety-critical applications such as: anti-lock braking system  (ABS), and auto-pilot software system etc. No major changes have been made to the MISRA C++ standard after the version released in the year 2008. Every autonomous vehicle developed can only be allowed for commercial or industrial use if each of its hardware and software component adheres to the required standards. ...

How traceability of non-functional requirements is managed throughout the software development process?

1. Requirements Traceability: Requirements traceability is the process of describing and keeping track of a set of requirements throughout the system’s lifecycle. The process assists in managing changing requirements of a particular software product. Requirements traceability of is two types, forward traceability where a particular requirement involved during the design and implementation phases of the software system, and backward requirement traceability where a particular requirement is being traced back to its source. 2. Proposed Solutions for the Traceability of Non - Functional Requirements : The author J. Merilinna [8], proposed a framework supported by a tool to trace the non-functional requirements in both forward and backward direction. The proposed method is based on the context of DSM (Domain Specific Modeling).  The NFR+1 framework involved are used for the elicitation, definition and redefinition of the system’s non-functional requirements. The...