SEI-CMM Model

SEI-CMM Model

Software Engineering Institute Capability Maturity Model (SEI-CMM)

The Capability Maturity Model (CMM) is a procedure used to develop and refine an organization's software development process.The model defines a five-level evolutionary stage of increasingly organized and consistently more mature processes.It was developed and is promoted by the Software Engineering Institute (SEI)

Methods of SEI-CMM includes:

1. Capability Evaluation:It provides a way to assess the software process capability of an organization. The results of capability evaluation indicate the likely contractor performance if the contractor is awarded a work. Therefore, the results of the software process capability assessment can be used to select a contractor.
2. Software Process Assessment: Software process assessment is used by an organization to improve its process capability. Thus, this type of evaluation is for purely internal use.

Levels Of SEICMM:

1. Level-1: Initial :Processes followed are ad hoc and immature and are not well defined.Unstable environment for software development.No basis for predicting product quality, time for completion, etc.
2. Level-2: Repeatable:Experience with earlier projects is used for managing new similar natured projects.
3. Level-3: Defined:At this level, documentation of the standard guidelines and procedures takes place.It is a well defined integrated set of project specific software engineering and management processes.
4. Level-4: Managed:At this stage, quantitative quality goals are set for the organization for software products as well as software processes.The measurements made help the organization to predict the product and process quality within some limits defined quantitatively.
5. Level-5: Optimizing:This is the highest level of process maturity in CMM and focuses on continuous process improvement in the organization using quantitative feedback.

ISO (International Standards Organization) 9000 Models

 ISO (International Standards Organization) 9000 Models

 The International standards organization (ISO) is a standard which serves as a contract between independent parties. It specifies guidelines for development of quality system.The ISO standard mainly addresses operational methods and organizational methods such as responsibilities, reporting, etc. ISO 9000 defines a set of guidelines for the production process and is not directly concerned about the product itself.The ISO 9000 standard determines the guidelines for maintaining a quality system.

Processes involved in ISO 9000 

Description of the processes include:

1. Application: Once an organization decides to go for ISO certification, it applies to the registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews the document submitted by the organization and suggests an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the organization has compiled the suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification after the successful completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the organization time by time.

Why is it necessary to get ISO 9000 certified?

Some of reasons are:

• This certification has become a standard for international bidding.
• It helps in designing high-quality repeatable software products.
• It emphasizes the need for proper documentation.

Features of ISO 9001 Requirements :

• Document control:All documents concerned with the development of a software product should be properly managed and controlled.
• Planning:Proper plans should be prepared and monitored.
• Review:For effectiveness and correctness all important documents across all phases should be independently checked and reviewed .
• Testing:The product should be tested against specification.

Software Quality Frameworks

Software Quality Frameworks

Software Quality Framework is a model for software quality by connecting and integrating the different views of software quality. This is a framework that describes all the different concepts relating to quality in a common way measured by qualitative scale that can be understood and interpreted in a common way.

1. Developer’s View:

 The primary concern for developers is in the design and engineering processes involved in producing software. Quality can be measured by the degree of conformance to predetermined requirements and standards, and deviations from these standards can lead to poor quality and low reliability. Uses validation and verification to improve the software.

1. Customer’s/User’s View:

End-user programming, a phrase popularized by which is programming to achieve the result of a program primarily for personal, rather than public use. The important distinction here is that software itself is not primarily intended for use by a large number of users with varying needs.

1. Product’s View:

Product quality can be measured by the value-based view which sees the quality as dependent on the amount a customer is willing to pay for it. According to the users, a high-quality product is one that satisfies their expectations and preferences while meeting their requirements. 

SQA Plans

SQA Plans

The SQA plan document consists of the below sections:

1. Purpose section
2. Reference section
3. Software configuration management section
4. Problem reporting and corrective action section
5. Tools, technologies and methodologies section
6. Code control section
7. Records: Collection, maintenance and retention section
8. Testing methodology

Abbreviated as SQAP, the software quality assurance plan comprises the procedures, techniques, and tools that are employed to make sure that a product or service aligns with the requirements defined in the SRS(software requirement specification).

The plan identifies the SQA responsibilities of a team, lists the areas that need to be reviewed and audited. It also identifies the SQA work products.

 

SQA Activities include:

1) Creating an SQA Management Plan

2) Setting the Checkpoints

3) Apply software Engineering Techniques

4) Executing Formal Technical Reviews

5) Having a Multi- Testing Strategy

6) Enforcing Process Adherence

Verification and Validation

Verification and Validation

Verification:

• The process of checking documents, design, code, and program in order to check if the software has been built according to the requirements or not. 
• The main goal of the verification process is to ensure quality of software application, design, architecture etc.
• Verification is the process of evaluating products of a development phase to find out whether they meet the specified requirements.
• The verification process involves activities like reviews, walk-throughs and inspection.

Validation:

• Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.
• It is a dynamic mechanism of testing and validating if the software product actually meets the exact needs of the customer or not. 
• The process helps to ensure that the software fulfills the desired use in an appropriate environment.
• The validation process involves activities like unit testing, integration testing, system testing and user acceptance testing.

Software Quality Assurance(SQA)

Software Quality Assurance(SQA)

Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering processes. It ensures that developed software meets and complies with the defined or standardized quality specifications. SQA is an ongoing process within the Software Development Life Cycle (SDLC) that routinely checks the developed software to ensure it meets the desired quality measures.It encompasses:

• A quality management approach
• Effective Software engineering technology (methods and tools)
• Formal technical reviews that are tested throughout the software process
• A multi tiered testing strategy
• Control of software documentation and the changes made to it.
• A procedure to ensure compliances with software development standards
• Measuring and reporting mechanisms.

Components of SQA:

Pre-project components

Components of project life cycle activities assessment

Components of infrastructure error prevention and improvement

Components of software quality management

Components of standardization, certification, and SQA system assessment

Organizing for SQA – the human components

IEEE Standards for SRS

IEEE Standards for SRS

1. Introduction
   1. Purpose
   2. Scope
   3. Definition, Acronyms and abbreviations
   4. References
   5. Overview
2. The Overall Description
   1. 2.1 Product Perspective
      1. System Interfaces
      2. Interfaces
      3. Hardware Interfaces
      4. Software Interfaces
      5. Communication Interfaces
      6. Memory Constraints
      7. Operations
      8. Site Adaptation Requirements
   2. Product Functions
   3. User Characteristics
   4. Constraints
   5. Assumptions for dependencies
   6. Apportioning of requirements
3. Specific Requirements
   1. External Interfaces
   2. Functions
   3. Performance requirements
   4. Logical database requirements
   5. Design Constraints
   6. Software System attributes
   7. Organization of specific requirements
   8. Additional Comments.

SRS Document

SRS Document:

A software requirements specification (SRS) is a document that captures a complete description about how the system is expected to perform. It is usually signed off at the end of requirements engineering phase.It also describes the functionality the product needs to fulfill all stakeholders (business, users) needs.

 

A typical SRS includes:

• A purpose
• An overall description
• Specific requirements

The best SRS documents define how the software will interact when embedded in hardware — or when connected to other software. 

 It is not a design document.It contains functional and nonfunctional requirements only. System Architects and Programmers write SRS documents.

Importance of SRS Document?

1. A software requirements specification is the basis for your entire project. It lays the framework that every team involved in development will follow.
2. It’s used to provide critical information to multiple teams — development, quality assurance, operations, and maintenance. This keeps everyone on the same page.
3. Using the SRS helps to ensure requirements are fulfilled. And it can also help you make decisions about your product’s lifecycle — for instance, when to retire a feature.
4. Writing an SRS can also minimize overall development time and costs. Embedded development teams especially benefit from using an SRS.

Decision Tables

Decision Tables

A Decision Table is a tabular representation of inputs versus rules/cases/test conditions. It is a very effective tool used for both complex software testing and requirements management. Decision table helps to check all possible combinations of conditions for testing and testers can also identify missed conditions easily. The conditions are indicated as True(T) and False(F) values.

Purpose:

The purpose of a decision table is to show a logical structure, with all possible combinations of conditions and resulting actions.They provide a clear method to verify testing of all pertinent combinations to ensure that all possible conditions, relationships, and constraints are handled by the software under test.

How to create a decision table?

At first fill in the Y/N patterns. Next, each column or rule represents a different set of conditions, analyze the logic and show the outcome of each rule.

Example:

Importance:

1. It assists in development process with developer to do a better job. Testing with all combination might be impractical.
2. A decision table is basically an outstanding technique used in both testing and requirements management.
3. It is a structured exercise to prepare requirements when dealing with complex business rules.

Decision Table Designed for Test looks like:

Entity Relationship Diagrams

Entity Relationship Diagrams

ER-modeling is a data modeling method used in software engineering to produce a conceptual data model of an information system. Diagrams created using this ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or ERDs.

Notations for ERD:

Purpose of ERD:

• The database analyst gains a better understanding of the data to be contained in the database through the step of constructing the ERD.
• The ERD serves as a documentation tool.
• Finally, the ERD is used to connect the logical structure of the database to users. In particular, the ERD effectively communicates the logic of the database to users.

Example of ERD:

Data Flow Diagrams

Data Flow Diagrams

A data-flow diagram is a way of representing a flow of data through a process or a system (usually an information system).The DFD also provides information about the outputs and inputs of each entity and the process itself. A data-flow diagram has no control flow, there are no decision rules and no loops.It is a graphical tool because it presents a picture.It presents a system or software at any level of abstraction. 

Four simple notations are used to complete a DFD- 

i. Data Flow-The data flow is used to describe the movement of information from a part of the system to another part.

ii. Process-A circle or bubble represents a process that transforms incoming data to outgoing data. 

iii. External Entity- A square defines a source or destination of system data. External entities represent any entity that supplies information from the system. 

iv. Data Store- The data store is used to collect data at rest or a temporary repository of data.

Example:

Information Modelling

Information Modelling

• An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. 
• Typically it specifies relations between kinds of things, but may also include relations with individual things. 
• It can provide a sharable, stable, and organized structure of information requirements or knowledge for the domain context.
• Information model is usually an abstract, formal representation of entity types that may include their properties, relationships and the operations that can be performed on them. 
• The entity types in the model may be kinds of real-world objects, such as devices in a network, or occurrences, or they may themselves be abstract, such as for the entities used in a billing system. 
• Typically, they are used to model a constrained domain that can be described by a closed set of entity types, properties, relationships and operations.

Feasibility Study

Feasibility Study

When we are developing a system we know whether the proposed system will be feasible or not i.e. practically implementable or not? It may be possible that the proposed system may not be implementable due to many reasons like it may take longer in development than the specified time limit, cost may increase than proposed. 

Purpose:

“evaluation or analysis of the potential impact of a proposed project or program.”

There may be several types of feasibility depending on the aspects they cover. Some of them are:

1. Technical Feasibility 
2. Operation Feasibility 
3. Economical Feasibility 

Phases of Feasibility: 

Technical feasibility-The technical feasibility study basically centers on alternatives for hardware, software and design approach to determine the functional aspects of a system. The technical issues raised during feasibility are:

1. Does the necessary technology exist?
2. Does the proposed equipment have technical capacity to hold data?
3. Can the system be expended, if developed?
4. Are there technical guarantee of accuracy, reliability and security of data

Operational feasibility-Operational feasibility is a measure of how people are able to work with a system. This type of feasibility demands if the system will work when developed and installed. 

Economical Feasibility -Economic feasibility determines whether the required software is capable of generating financial gains for an organization. It involves the cost incurred on the software development team, estimated cost of hardware and software, cost of performing feasibility study, and so on.

Elicitation

Elicitation

It is related to the various ways used to gain knowledge about the project domain and requirements. The various sources of domain knowledge include customers, business manuals, the existing software of the same type, standards and other stakeholders of the project.

The techniques used for requirements elicitation include interviews, brainstorming, task analysis, prototyping, etc.

1. Analysis

Requirement analysis is a significant and essential activity after elicitation. We analyze, refine, and scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity reviews all requirements and may provide a graphical view of the entire system. After the completion of the analysis, it is expected that the understandability of the project may improve significantly. 

1. Documentation

Typically created in the beginning of a software development project. Has the goal to clearly and precisely specify the expectations in regards to the software being created. May include functional requirements, limitations, hardware or software requirements, compatibility requirements, and so on.

1. Review and Management of User Needs

This is a process in which people from client & contractor organizations are both involved in checking the requirements for omission. Different parts of the document are checked by different people involved in this type of activity. Various activities performed during user needs review process are: 

• Plan a review 
• Review meeting  
• Follow-up actions  
• Checking for redundancy  
• Completeness  
• Consistency

Uses and Significance of Requirement Engineering:

The Requirement Engineering (RE) is the most important phase of the Software Development Life Cycle (SDLC). This phase is used to translate the imprecise, incomplete needs and wishes of the potential users of software into complete, precise and formal specifications.

Uses:

The purpose of requirements engineering methodologies is to make the problem that is being stated clear and complete, and to ensure that the solution is correct, reasonable, and effective.