Subject: Software

Engineering Unit-III
Software Engineering Specification

Asst.Prof. Sonali B. Kanawade

Artificial Intelligence and Data Science
Department AISSMS IOIT, Pune
UNIT- III - Software Engineering Specification
Course Objective:

To explain Software Engineering Practices.

Course Outcomes : Students will be able to

Rephrase Software Engineering Practices.

2
Software engineering Specification(SRS) :
•Requirement Engineering Process :
• A systematic and strict approach to the definition, creation, and verification of requirements for a software system is known
as requirements engineering. To guarantee the effective creation of a software product, the requirements engineering
process entails several tasks that help in understanding, recording, and managing the demands of stakeholders

•Requirement Engineering Process

It is a four-step process, which includes –
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
3
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.
Operational Feasibility - Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer requirements.
Economic Feasibility - Economic feasibility decides whether the necessary software can generate
financial profits for an organization.
2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with the help
of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships
and also resolve conflicts if any.
Problems of Elicitation and Analysis
Getting all and only, the right people involved.
Stakeholders often don't know what they want
Stakeholders express requirements in their terms.
Stakeholders may have conflicting requirements.
Requirement change during the analysis process.
Organizational and political factors may influence
system requirements.
Documentation
Software documentation is a written piece of text that is often accompanied by a software program. This
makes the life of all the members associated with the project easier. It may contain anything from API
documentation, build notes or just help content. It is a very critical process in software development. It’s
primarily an integral part of any computer code development method. Moreover, computer code practitioners
are a unit typically concerned with the worth, degree of usage, and quality of the actual documentation
throughout the development and its maintenance throughout the total method. Motivated by the
requirements of Novatel opposition, a world-leading company developing package in support of worldwide
navigation satellite system, and based mostly on the results of a former systematic mapping studies area unit
aimed at a higher understanding of the usage and therefore the quality of varied technical documents
throughout computer code development and their maintenance.
Types Of Software Documentation:
• Requirement Documentation: It is the description of how the software shall perform and which
environment setup would be appropriate to have the best out of it. These are generated while the
software is under development and is supplied to the tester groups too.
• Architectural Documentation: Architecture documentation is a special type of documentation
that concerns the design. It contains very little code and is more focused on the components of
the system, their roles, and working. It also shows the data flow throughout the system.
• Technical Documentation: These contain the technical aspects of the software like API,
algorithms, etc. It is prepared mostly for software devs.
• End-user Documentation: As the name suggests these are made for the end user. It contains
support resources for the end user.
Purpose of Documentation:
Due to the growing importance of computer code necessities, the method of crucial them needs to
be effective to notice desired results. As to such determination of necessities is often beneath sure
regulation and pointers that area unit core in getting a given goal.
These all imply that computer code necessities area unit expected to alter thanks to the ever
ever-changing technology within the world. However, the very fact that computer code information
I’d obtained through development has to be modified within the wants of users and the
transformation of the atmosphere area unit is inevitable.
What is more, computer code necessities ensure that there’s a verification and therefore the testing
method, in conjunction with prototyping and conferences there are focus teams and observations?
For a software engineer reliable documentation is typically a should the presence of documentation
helps keep track of all aspects of associate applications, and it improves the standard of wares, it’s
the most focused area of unit development, maintenance, and information transfer to alternative
developers. Productive documentation can build info simply accessible, offer a restricted range of
user entry purposes, facilitate new users to learn quickly, alter the merchandise and facilitate
chopping out the price.
Principles of Software Documentation:
While writing or contributing into any software documentation, one must keep in mind the following
set of 7-principles :
1. Write from reader’s point of view:
It’s important to keep in mind the targeted audience that will be learning, and working through the
software’s documentation to understand and implement the fully functional robust software
application and even the ones who will be learning for the purpose of using the software. So, while
writing a documentation it becomes very crucial to use the simplest language & domain related
specific languages and terminologies. The structure of the documentation should be organized in a
clearly viewable, navigable and understandable format.
If there’s a lot of content, you can organize it in the glossary part at the end of the document.
List down synonyms, antonyms and difficult terminologies used.
2. Avoid unnecessary repetition:
While the idea of hyperlinking and backlinking may seem redundant at the moment, but it aids in
avoiding the need of redundancy. The back-end database stores every piece of information as an
individual unit and displays it in various different variety of context so redundancy at any point will
not be maintainable and is considered a bad practice.
3. Avoid ambiguity:
Documentation contains a lot of information regarding the versatile functionalities of the software
system, every part of it must be written with clear and precise knowledge while avoiding any
conflicting information that might cause confusion to the reader. For example, if one terminology is
used in different set of context than it must be explicitly defined what it means so to avoid any
miscommunication. This aspect of the software documentation is very important to avoid any kind of
conflicting knowledge between the stakeholders, developers and the maintainers.
4. Follow a certain standard organization:
In order to maintain the professionalism, accuracy, and precision of the document a certain set of
principles must be followed taking reference from other software documentations that would aid in
organizing and structuring the content of the documentation in a much productive and organized
way.
5. Record a Rationale
Rationale contains a comprehensive understanding of why a certain design or development decision
was made. This part of our documentation is written & maintained by the developer or the designer
itself for justification and verification for later needs. Rationale can be mentioned in the start or the
end of the document although typically, it’s in the start of the document.
6. Keep the documentation updated but to an extent
This principle applies to the maintainers of the documentation of the software, because updates are
made to the software on frequent intervals. The updates may contain some bug fixes, new feature
addition or previous functionality maintenance. The maintainer of the documentation must only add
the valuable content and avoid anything that doesn’t fit and irrelevant for that particular time.

7. Review documentation
The documentation consists of too many web-pages collectively holding a large chunk of information
that’s serving a sole purpose – educate and spread knowledge to anyone who is trying to understand
or implement the software. While working with a lot of information it is important ta take feedback
from senior architects and make any necessary changes aligning the documentation with its sole
purpose depending on the type of documentation.
Advantages of software documentation
▪ The presence of documentation helps in keeping the track of all aspects of an application and also
improves the quality of the software product.
▪ The main focus is based on the development, maintenance, and knowledge transfer to other
developers.
▪ Helps development teams during development.
▪ Helps end-users in using the product.
▪ Improves overall quality of software product
▪ It cuts down duplicative work.
▪ Makes easier to understand code.
▪ Helps in establishing internal coordination in work.
Disadvantages of software documentation
▪ The documenting code is time-consuming.
▪ The software development process often takes place under time pressure, due to which many
times the documentation updates don’t match the updated code.
▪ The documentation has no influence on the performance of an application.
▪ Documenting is not so fun, it’s sometimes boring to a certain extent.
Review and Management of User Needs :
▪ This is a process in which people from client & contractor organization both involved for checking
the requirements for omission.

▪ Different parts of document are checked by different people involved in this type of activities.

▪ Various activities performed during user needs review process are :

Plane a review
Review meeting
Follow-up actions
Checking for redundancy
Completeness
Consistency
Feasibility Study :
• When we are developing a system we know weather prposed 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 a long time limit, cost may increase than proposed.

Types of Feasibility Study :

Technical Feasibility
Operational Feasibility
Economic Feasibility
Legal Feasibility
Schedule Feasibility
Market Feasibility.
Technical Feasibility
• Technical feasibility evaluates the available infrastructure (Such as hardware and software ) and
technology needed to meet the consumer needs of software under time and budget constraints.
• The product development team determines whether current tools and technology should be
modified or applied to the program to fulfill the identified user’s needs.
• Examines the technological expertise and talents of members of the software development team .
• Determines whether the application infrastructure is reliable and well- established.
• Ensures that the technology selected for software creation has many customers who can be
contacted when issues emerge on the required changes.
Economical Feasibility
Needs to consider the expenses made on purchasing, such as hardware purchasing and required
activities required to carry out software development. It is also necessary to consider the benefits
that can e achieved by developing the software. Software is economically feasible when it focuses on
the issues listed below.
▪ Expenses incurred on software development for achieving long-term gains for an organization.
▪ Expenses required to conduct elicitation and requirement analysis.
▪ Hardware and software cost, development team and training cost.

Legal Feasibility - Should be follow all the laws.

Schedule Feasibility – Project delivered on time or not?
Market Feasibility – According to the market survey end product is useful for user or not? Is it
making profit or not.
Step to prepare a feasibility study report
▪ Project Description

▪ Market Research

▪ Technical Requirements

▪ Risk Assessment

▪ Outline the Potential Solutions

▪ Criteria for Evaluation

▪ Suggest a feasible solution.

Information Modeling :
▪ An information model is used by software engineers and website designers to build an effective
platform that is easy to use and navigate.
▪ Engineers must plan for what the users wants out of a program or website to make it effective.
▪ The information model is build on a hierarchy schema, and the complexity of the model depends
on the product and how many features the programmer is adding.

Information collection
Report writing
Basic information.
Information Model
▪ Current functional procedures
▪ Practical objective
▪ Performance objective
▪ Assumption and restrictions
▪ Evaluation criteria
▪ Recommendation
▪ Recommended software
▪ Organizational influences
▪ Developmental impacts
▪ Impacts on infrastructure
▪ Program impacts
▪ Organizational implications
▪ Security implications
▪ Security implications
▪ Alternative solution
Data Flow Diagram
A graphical tool, useful for communicating with users, managers, and other personnel.

User to perform structured analysis to determine logical requirements.

Useful for analysing existing as well as proposed systems.

Focus on the movement of data between external entities and processes, and between processes

and data stores.

A relatively simple technique to learn and use.

https://www.javatpoint.com/software-engineering-data-flow-diagrams
Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a process or data store.
Data Store: A set of parallel lines shows a place for the collection of data items. A data store indicates
that the data is stored which can be used at a later stage or by the other processes in a different
order. The data store can have an element or group of elements.
Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink of
system outputs.

https://youtu.be/HSa52aX24xk
https://youtu.be/KN-inGJG540
Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily
three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.
0-level DFD
▪ It is also known as fundamental system model, or context diagram represents the entire software
requirement as a single bubble with input and output data denoted by incoming and outgoing
arrows.
▪ Then the system is decomposed and described as a DFD with multiple bubbles. Parts of the system
represented by each of these bubbles are then decomposed and documented as more and more
detailed DFDs.
▪ This process may be repeated at as many levels as necessary until the program at hand is well
understood. It is essential to preserve the number of inputs and outputs between levels, this
concept is called leveling by DeMacro.
▪ Thus, if bubble "A" has two inputs x1 and x2 and one output y, then the expanded DFD, that
represents "A" should have exactly two external inputs and one external output as shown in fig:
1-level DFD
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level, we
highlight the main objectives of the system and breakdown the high-level process of 0-level DFD into
sub processes.
2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or record the
specific/necessary detail about the system's functioning.
Decision Table
Tabular representation of condition and their respective actions
Used in requirement management as well as in system testing for checking the behavior of
different input combination
Condition R1 R2 R3
Example :
Test case for R1 : Withdrawal Amount <= Balance T F F
Balance =200
Required withdrawal =200 Credit Granted T T F
Result =‘Withdrawal granted’
Test case for R2
Balance =100 Actions
Required withdrawal =200
Result =‘Withdrawal denied’ Withdrawl Granted T F F
Test case for R3
Balance =100
Required withdrawal =200
No credit
Result =‘Withdrawal granted
https://www.youtube.com/watch?v=Znf96SUuP4o
IEEE Standards for SRS
IEEE 29148 : 2011 (Latest – 2018)
It covers the processes and information recommendation for a SRS.

Earlier this standards was named as IEEE std. 830-1998 and later replaced by standard

ISO/IED/IEEE29148:2011, with an update in 2018

This standard makes us understand what should be the characteristics of good SRS, and how to

apply these requirements throughout SDLC

This standard provides us the suggestion to organized functional & Non functional requirement.

https://www.youtube.com/watch?v=vCGLLOuKICc
Software Quality Assurance(SQA)
• Software Quality Assurance (SQA) is a practice that ensures software meets quality standards and
requirements. It's a collaborative effort between developers and testers to identify and fix issues
before releasing software to the public.
• Software Quality Assurance (SQA) is a critical component of the software development process
that ensures the quality and reliability of software products. SQA encompasses methodologies
and practices designed to monitor the software engineering processes and methods used to
ensure quality.
• Elements of Software Quality Assurance (SQA)
1. Standards: The IEEE, ISO, and other standards organizations have produced a broad array of
software engineering standards and related documents.
2. Reviews and audits: Technical reviews are a quality control activity performed by software
engineers for software engineers. Their intent is to uncover errors.
3. Testing: Software testing is a quality control function that has one primary goal—to find errors.
4. Error/defect collection and analysis : SQA collects and analyzes error and defect data to better
understand how errors are introduced and what software engineering activities are best suited
to eliminating them.
5. Change management: SQA ensures that adequate change management practices have been
instituted.

6. Education: Every software organization wants to improve its software engineering practices. A key
contributor to improvement is education of software engineers, their managers, and other
stakeholders.

7. Security management: SQA ensures that appropriate process and technology are used to achieve
software security.

8. Safety: SQA may be responsible for assessing the impact of software failure and for initiating those
steps required to reduce risk.

9. Risk management : The SQA organization ensures that risk management activities are properly
conducted and that risk-related contingency plans have been established.
Software Quality Assurance (SQA) focuses
The Software Quality Assurance (SQA) focuses on the following
SQA

Software Quality Assurance (SQA)

Software’s portability: Software’s portability refers to its ability to be easily transferred or adapted to different
environments or platforms without needing significant modifications. This ensures that the software can run
efficiently across various systems, enhancing its accessibility and flexibility.
software’s usability: Usability of software refers to how easy and intuitive it is for users to interact with and
navigate through the application. A high level of usability ensures that users can effectively accomplish their
tasks with minimal confusion or frustration, leading to a positive user experience.
software’s reusability: Reusability in software development involves designing components or modules that
can be reused in multiple parts of the software or in different projects. This promotes efficiency and reduces
development time by eliminating the need to reinvent the wheel for similar functionalities, enhancing
productivity and maintainability.
software’s correctness: Correctness of software refers to its ability to produce the desired results under
specific conditions or inputs. Correct software behaves as expected without errors or unexpected behaviors,
meeting the requirements and specifications defined for its functionality.
software’s maintainability: Maintainability of software refers to how easily it can be modified, updated, or
extended over time. Well-maintained software is structured and documented in a way that allows developers
to make changes efficiently without introducing errors or compromising its stability.
software’s error control: Error control in software involves implementing mechanisms to detect, handle, and
recover from errors or unexpected situations gracefully. Effective error control ensures that the software
remains robust and reliable, minimizing disruptions to users and providing a smoother experience overall.
 • Software Quality Assurance (SQA) Include
1. A quality management approach.
2. Formal technical reviews.
3. Multi testing strategy.
4. Effective software engineering technology.
5. Measurement and reporting mechanism.
• Major Software Quality Assurance (SQA) Activities
1. SQA Management Plan: Make a plan for how you will carry out the SQA throughout the project. Think about which set
of software engineering activities are the best for project. check level of SQA team skills.
2. Set The Check Points: SQA team should set checkpoints. Evaluate the performance of the project on the basis of
collected data on different check points.
3. Measure Change Impact: The changes for making the correction of an error sometimes re introduces more errors keep
the measure of impact of change on project. Reset the new change to check the compatibility of this fix with whole
project.
4. Multi testing Strategy: Do not depend on a single testing approach. When you have a lot of testing approaches
available use them.
5. Manage Good Relations: In the working environment managing good relations with other teams involved in the project
development is mandatory. Bad relation of SQA team with programmers team will impact directly and badly on project.
Don’t play politics.
6. Maintaining records and reports: Comprehensively document and share all QA records, including test cases, defects,
changes, and cycles, for stakeholder awareness and future reference.
7. Reviews software engineering activities: The SQA group identifies and documents the processes. The group also
verifies the correctness of software product.
Benefits of Software Quality Assurance (SQA)
• SQA produces high quality software.
• High quality application saves time and cost.
• SQA is beneficial for better reliability.
• SQA is beneficial in the condition of no maintenance for a long time.
• High quality commercial software increase market share of company.
• Improving the process of creating software.
• Improves the quality of the software.
• It cuts maintenance costs. Get the release right the first time, and your company can forget about
it and move on to the next big thing. Release a product with chronic issues, and your business
bogs down in a costly, time-consuming, never-ending cycle of repairs.
Disadvantage of Software Quality Assurance (SQA)

Cost: Some of them include adding more resources, which cause the more budget its not, Addition of more
resources For betterment of the product.
Time Consuming: Testing and Deployment of the project taking more time which cause delay in the project.
Overhead : SQA processes can introduce administrative overhead, requiring documentation, reporting, and
tracking of quality metrics. This additional administrative burden can sometimes outweigh the benefits,
especially for smaller projects.
Resource Intensive : SQA requires skilled personnel with expertise in testing methodologies, tools, and quality
assurance practices. Acquiring and retaining such talent can be challenging and expensive.
Resistance to Change : Some team members may resist the implementation of SQA processes, viewing them as
bureaucratic or unnecessary. This resistance can hinder the adoption and effectiveness of quality assurance
practices within an organization.
Not Foolproof : Despite thorough testing and quality assurance efforts, software can still contain defects or
vulnerabilities. SQA cannot guarantee the elimination of all bugs or issues in software products.
Complexity : SQA processes can be complex, especially in large-scale projects with multiple stakeholders,
dependencies, and integration points.
Verification and Validation
Verification and Validation is the process of investigating whether a software system satisfies
specifications and standards and fulfills the required purpose. Barry Boehm described verification
and validation as the following:
Verification: Are we building the product right?
Validation: Are we building the right product?

Verification
Verification is the process of checking that software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have. Verification is simply known as Static
Testing.

Validation
Validation is the process of checking whether the software product is up to the mark or in other
words product has high-level requirements. It is the process of checking the validation of the product
i.e. it checks what we are developing is the right product. it is a validation of actual and expected
products. Validation is simply known as Dynamic Testing.
Difference between Verification and Validation

V &V Model
SQA PLAN
What is a Software Quality Assurance Plan?
• A Quality Assurance Plan (QAP) is a document or set of documents that outlines the
systematic processes, procedures, and standards for ensuring the quality of a product or
service.
• It is a key component of quality management and is used in various industries to
establish and maintain a consistent level of quality in deliverables.
• For a software product or service, an SQA plan will be used in conjunction with the typical
development, prototyping, design, production, and release cycle.
• An SQA plan will include several components, such as purpose, references, configuration
and management, tools, code controls, testing methodology, problem reporting and
remedial measures, and more, for easy documentation and referencing.
SQA Plan
Importance of Software Quality Assurance Plan

• Quality Standards and Guidelines: The SQA Plan lays out the requirements and guidelines
to make sure the program satisfies predetermined standards for quality.
• Risk management: It is the process of recognizing, evaluating and controlling risks in
order to reduce the possibility of errors and other problems with quality.
• Standardization and Consistency: The strategy guarantees consistent methods,
processes, and procedures, fostering a unified and well-structured approach to quality
assurance.
• Customer Satisfaction: The SQA Plan helps to ensure that the finished product satisfies
customer needs, which in turn increases overall customer satisfaction.
• Resource optimization: It is the process of defining roles, responsibilities, and procedures
in order to maximize resource utilization and minimize needless rework.
• Early Issue Detection: SQA Plans help identify problems early on, which lowers the
expense and work involved in fixing them.
Objectives And Goals of Software Quality Assurance Plan:
The objectives and goals of a Quality Assurance Plan (QAP) are to ensure that the products or
services meet specified quality standards and requirements. The plan serves as a roadmap
for implementing quality assurance processes throughout a project or organizational activity.
The specific objectives and goals can vary depending on the nature of the project or industry,
but common elements include:
1. Compliance with Standards and Regulations
2. Customer Satisfaction
3. Defect Prevention
4. Consistency and Reliability
5. Process Improvement
6. Risk Management
7. Clear Roles and Responsibilities
8. Documentation and Traceability
9. Training and Competence
10. Continuous Monitoring and Reporting
https://www.geeksforgeeks.org/software-quality-assurance-plan-in-software-development/#what
-is-a-software-quality-assurance-plan
Software Quality Framework

What is a Software Quality Framework?

• Software Quality Framework connects the customer view with the developer’s view of
software quality and it treats software as a product.
• The software product view describes the characteristics of a product that bear on its
ability to satisfy stated and implied needs.
• This is a framework that describes all the different concepts relating to quality in a
common way measured by a qualitative scale that can be understood and interpreted
commonly.
Therefore, the most influential factor for the developers is the customer perception. This
framework connects the developer with the customer to derive a common interpretation of
quality.
Developers View
• Validation and verification are two independent methods used together to check that a
software product meets the requirements and that it fulfills its intended purpose.
Validation checks that the product design satisfies the purposeful usage and verification
checks for errors in the software.
1. The primary concern for developers is in the design and engineering processes involved
in producing software.
2. 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.
3. While validation and verification are used by the developers to improve the software,
the two methods don’t represent a quantifiable quality measurement.
4. The developer’s view of software quality and the customer’s view of software quality are
both different things.
Users View
• When the user acquires software, he/she always expect a high-quality software. When end users
develop their software then quality is different. End-user programming, a phrase popularized by
which is programming to achieve the result of a program primarily for personal, rather than public
use.
1. The important distinction here is that software itself is not primarily intended for use by many
users with varying needs.
2. For example, a teacher may write a spreadsheet to track student’s test scores.
3. In these end-user programming situations, the program is a means to an end that could be used
to accomplish a goal.
4. In contradiction to end-user programming, professional programming has the goal of producing
software for others to use.
5. For example, the moment a novice Web developer moves from designing a web page for himself
to designing a Web page for others, the nature of this activity has changed.
6. Users find software quality as a fit between their goals and software’s functionality.
7. The better the quality, the more likely the user will be satisfied with the soft-ware.
8. When the quality is bad, developers must meet user needs or face a diminishing demand for
their software.
Product View

• The product view describes quality as correlated to inherent characteristics of the

product. Product quality is defined as the set of characteristics and features of a product
that gives contribution to its ability to fulfill given requirements.
1. 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.
2. According to the users, a high-quality product is one that satisfies their expectations and
preferences while meeting their requirement.
3. Satisfaction of end users of the product represents craft to learn, use, upgrade the
product and when asked to participate in rating the product, a positive rating is given.
ISO 9000 Model
• ISO 9000 is defined as a set of international standards on quality management and quality
assurance developed to help companies effectively document the quality system elements
needed to maintain an efficient quality system. They are not specific to any one industry and can
be applied to organizations of any size.
• ISO 9000 can help a company satisfy its customers, meet regulatory requirements, and achieve
continual improvement. It should be considered to be a first step or the base level of a quality
system.
• ISO 9000:2015 principles of Quality Management
1. Customer focus
• Understand the needs of existing and future customers
• Align organizational objectives with customer needs and
expectations
• Meet customer requirements
• Measure customer satisfaction
• Manage customer relationships
• Aim to exceed customer expectations
• Learn more about the customer experience and
customer satisfaction
2. Leadership
Establish a vision and direction for the organization
Set challenging goals
Model organizational values
Establish trust
Equip and empower employees
Recognize employee contributions
Learn more about leadership
3. Engagement of people
Ensure that people’s abilities are used and valued
Make people accountable
Enable participation in continual improvement
Evaluate individual performance
Enable learning and knowledge sharing
Enable open discussion of problems and constraints
Learn more about employee involvement
4. Process approach
Manage activities as processes
Measure the capability of activities
Identify linkages between activities
Prioritize improvement opportunities
Deploy resources effectively
Learn more about a process view of work and see process analysis tools
5. Improvement
Improve organizational performance and capabilities
Align improvement activities
Empower people to make improvements
Measure improvement consistently
Celebrate improvements
Learn more about approaches to continual improvement
6. Evidence-based decision making
Ensure the accessibility of accurate and reliable data
Use appropriate methods to analyze data
Make decisions based on analysis
Balance data analysis with practical experience
See tools for decision making
7. Relationship management
Identify and select suppliers to manage costs, optimize resources, and create value
Establish relationships considering both the short and long term
Share expertise, resources, information, and plans with partners
Collaborate on improvement and development activities
Recognize supplier successes
Learn more about supplier quality and see resources related to managing the supply chain
SEI-CMM model

• The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies
an increasing series of levels of a software development organization.
What is Capability Maturity Model?
• The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies
an increasing series of levels of a software development organization. The higher
the level, the better the software development process, hence reaching each level
is an expensive and time-consuming process.
• 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.
Methods of SEICMM

Capability Evaluation: Capability evaluation 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.
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.
SEI CMM categorized software development industries into the following five maturity levels. The
various levels of SEI CMM have been designed so that it is easy for an organization to build its quality
system starting from scratch slowly.
Level of CMM Model
• Level One :Initial - The software process is characterized as inconsistent, and occasionally even chaotic.
Defined processes and standard practices that exist are abandoned during a crisis. Success of the
organization majorly depends on an individual effort, talent, and heroics. The heroes eventually move on to
other organizations taking their wealth of knowledge or lessons learnt with them.
• Level Two: Repeatable - This level of Software Development Organization has a basic and consistent project
management processes to track cost, schedule, and functionality. The process is in place to repeat the
earlier successes on projects with similar applications. Program management is a key characteristic of a
level two organization.
• Level Three: Defined - The software process for both management and engineering activities are
documented, standardized, and integrated into a standard software process for the entire organization and
all projects across the organization use an approved, tailored version of the organization's standard
software process for developing, testing and maintaining the application.
• Level Four: Managed - Management can effectively control the software development effort using precise
measurements. At this level, organization set a quantitative quality goal for both software process and
software maintenance. At this maturity level, the performance of processes is controlled using statistical
and other quantitative techniques, and is quantitatively predictable.
• Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving process
performance through both incremental and innovative technological improvements. At this level, changes
to the process are to improve the process performance and at the same time maintaining statistical
probability to achieve the established quantitative process-improvement objectives.
Importance of Capability Maturity Model

• Optimization of Resources: CMM helps businesses make the best use of all of their resources,
including money, labor, and time. Organizations can improve the effectiveness of resource
allocation by recognizing and getting rid of unproductive practices.
• Comparing and Evaluating: A formal framework for benchmarking and self-evaluation is offered
by CMM. Businesses can assess their maturity levels, pinpoint their advantages and
disadvantages, and compare their performance to industry best practices.
• Management of Quality: CMM emphasizes quality management heavily. The framework helps
businesses apply best practices for quality assurance and control, which raises the quality of their
goods and services.
• Enhancement of Process: CMM gives businesses a methodical approach to evaluate and enhance
their operations. It provides a road map for gradually improving processes, which raises
productivity and usefulness.
• Increased Output: CMM seeks to boost productivity by simplifying and optimizing processes.
Organizations can increase output and efficiency without compromising quality as they go
through the CMM levels.
Difference between ISO9000 and SEI-CMM:
ISO 9000 SEICMM

ISO 9000 is a set of international standards on quality management and SEI (Software Engineering Institute), Capability Maturity Model (CMM)
quality assurance developed to help companies effectively document the specifies an increasing series of levels of a software development
quality system elements needed to an efficient quality system. organization.

Focus is customer supplier relationship, attempting to reduce customer’s Focus on the software supplier to improve its interval processes to achieve
risk in choosing a supplier. a higher quality product for the benefit of the customer.

It is created for hard goods manufacturing industries. It is created for software industry.

ISO9000 is recognized and accepted in most of the countries. SEICMM is used in USA, less widely elsewhere.

CMM provides detailed and specific definition of what is required for given
It specifies concepts, principles and safeguards that should be in place.
levels.

This establishes one acceptance level. It assesses on 5 levels.

Its certification is valid for three years. It has no limit on certification.

It focuses on inwardly processes. It focus outwardly.

It has 5 levels:
It has no level.
(a). Initial (b). Repeatable (c). Defined (d). Managed (e). Optimized

It is basically an audit. It is basically an appraisal.

It is open to multi sector. It is open to IT/ITES.

Requirement Models:
Thank
You