Software Engineering

KCA-302

Unit 1
 Bloom’s Knowledge Knowledge
Course Outcomes (COs)
Level (BL) Category (KC)
At the end of this course, Student will be able to
Describe Software Engineering Concepts and
CO-1 BL2 F,C,P
SDLC models.
Prepare Software Requirement Specification
CO-2 (SRS) with Modelling tools and Quality BL3 F,C,P
standards.
Analyse design concepts to software
CO-3 development with software metrics methods. BL4 F,C,P

Categorize software testing techniques and its

CO-4 BL4 F,C,P
implementation.
Contrast Software project management
activities with its parameters such as Cost,
CO-5 BL4 F,C,P
Efforts, Schedule/ Duration.
Referred Books
Contents of Unit-1

• Software Engineering Concepts, Components, & Software Characteristics

• Software Crisis, Software Engineering Processes
• Comparison Conventional Engineering Processes, Software Quality Attributes
• Software Development Life Cycle (SDLC): Waterfall Model
• SDLC: Prototype Model, and Spiral Model
• SDLC: Evolutionary Development Models
• SDLC: Iterative Enhancement Models.
• Comparison of all SDLC Models
What is Software?
• Instructions (Computer Programs) that when executed provide
desired function and performance
• Data structures that enable the programs to adequately
manipulate information.
• Documents that describe the operation and use of the programs
IEEE Definition of Software
Software is the collection of computer programs, procedure rules and
associated documentation and data.
 Program vs. Software
• Program – A set of instructions written in a proper syntax to solve a
specific problem.
• Software – It consists of programs, set of documentations and the
procedures used to setup and operate the software system.
Software Components:
• Software = Programs + Documentation + Operating Procedures.
• Program = Source Code + Object Code
• Operating Procedure consists of instructions to setup and use the
software system and instructions on how to react to system failure.
• Documentation consists of different types of manuals
Software Applications

1. System Software
2. Real Time Software
3. Embedded Software
4. Business Software
5. Personal Computer Software
6. Artificial Intelligence Software
7. Web Based Software
8. Engineering and Scientific Software
Software Characteristics
• Software does not wear out – Like
hardware
• Software may be retired due to
environmental changes, new
requirements, new expectations
• Software is not manufactured
• Software is logical rather than
physical.
• Reusability of components.
• Software is flexible.
• Most software is custom built, rather
than being assembled from existing
components.
Software Crisis
• The situation, where catastrophic
failures have occurred, is known
as Software Crisis. The major causes of
software crisis are the problems
associated with poor quality software
such as malfunctioning of software
systems, inefficient development of
software, and the most important,
dissatisfaction amongst the users of the
software.
• So, the term ‘Software Engineering’
first introduced at a conference in late
1960’s to discuss the software crisis.
Factors contributing to software crisis
• Projects running over-budget.
• Projects running over-time.
• Unrealistic or unarticulated project goals
• Software was very inefficient with lack of resources
• Software was of low quality.
• Software often did not meet requirements.
• Projects were unmanageable and code difficult to maintain.
• Software was never delivered.
Software Engineering Definition
IEEE Comprehensive Definition: -- Software Engineering is the
application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software, i.e., the
application of engineering to software.
Software Engineering deals with cost-effective solutions to practical
problems by applying scientific knowledge in building software arti-
facts in the service of mankind
Software Engineering is the application of methods and scientific
knowledge to create practical cost-effective solutions for the design,
construction, operation and maintenance of software
Software Engineering Processes
• Software Process defines a framework for a set of Key Process
Areas (KPAs) that must be established for effective delivery of software
engineering technology. This establishes the context in which technical
methods are applied, work products such as models, documents, data,
reports, forms, etc. are produced, milestones are established, quality is
ensured, and change is properly managed.

• (Webster) A system of operations in producing something; a series of

actions, changes, or functions that achieve an end or a result

• (IEEE) A sequence of steps performed for a given purpose

 A common process framework is established by
Software Engineering Processes defining a small number of framework activities
that are applicable to all software projects,
regardless of their size or complexity.
• Several task sets – each a collection of
software engineering
~ work tasks,
~ project milestones,
~ work products, and
~ quality assurance points – Enable the
framework activities to be adapted to the
characteristics of the software project and
the requirements of the project team.
• Umbrella activities – such as software quality
assurance, software configuration
management, and measurement – overlap the
process model. Umbrella activities are
independent of any one framework activity
and occur throughout the process.
Software Quality Attributes
Software Quality Attributes are features that facilitate the measurement of
performance of a software product by Software Testing professionals. This
approach to software quality is best exemplified by fixed quality models, such as
ISO/IEC 25010:2011. This standard describes a hierarchy of eight quality
characteristics, each composed of sub-characteristics:
1. Functional suitability
2. Performance efficiency
3. Compatibility
4. Usability
5. Reliability
6. Security
7. Maintainability
8. Transferability
Functional Suitability: Functional Suitability refers to how well a product or system is
able to provide functions that meet the stated and implied needs.
• Functional Completeness: Refers to the set of functions that covers all of the
specified tasks and user objectives.
• Functional Correctness: Refers to how well a product or system provides the
correct results with the needed degree of precision.
• Functional Appropriateness: Refers to how well functions are able to accomplish
specified tasks and objectives.
Performance Efficiency: Performance Efficiency refers to the performance related to
the amount of resources used.
• Time Behavior: Refers to the response and processing times, and throughput rates
of a product or system while it’s performing its functions.
• Resource Utilization: Refers to the amounts and types of resources used by a
product or system while performing its functions.
• Capacity: Refers to the maximum limits of a product or system parameter.
Compatibility: Compatibility refers to how well a product, system, or component can
exchange information as well as perform its required functions while sharing the same
hardware or software environment.
• Co-existence: Refers to how well a product can perform its required functions
efficiently while sharing a common environment and resources with products,
without negatively impacting any other product.
• Interoperability: Refers to how well two or more systems, products, or
components are able to exchange information and use that information.
Portability: Portability refers to how well a system, product, or component can be
transferred from one environment to another.
• Adaptability: Refers to how well a product or system can be adapted for different
or evolving hardware, software, or other usage environments.
• Installability: Refers to how successfully a product or system can be installed
and/or uninstalled.
• Replaceability: Refers to how well a product can replace another comparable
product.
Usability: Usability refers to how well a product or system can be used to achieve
specified goals effectively, efficiently, and satisfactorily.
• Appropriateness Recognizability: Refers to how well you can recognize
whether a product or system is appropriate for your needs.
• Learnability: Refers to how easy it is to learn how to use a product or system.
• Operability: Refers to whether a product or system has attributes that make it
easy to operate and control.
• User Error Protection: Refers to how well a system protects users against
making errors.
• User Interface Aesthetics: Refers to whether a user interface is pleasing.
• Accessibility: Refers to how well a product or system can be used with the
widest range of characteristics and capabilities.
Maintainability
Maintainability refers to how well a product or system can be modified to improve,
correct, or adapt to changes in the environment as well as requirements.
• Modularity: Refers to whether the components of a system or program can
be changed with minimal impact on the other components.
• Reusability: Refers to how well an asset can be used in more than one
system.
• Analysability: Refers to the effectiveness of an impact assessment on
intended changes. In addition, it also refers to the diagnosis of deficiencies
or causes of failures, or to identify parts to be modified.
• Modifiability: Refers to how well a product or system can be modified
without introducing defects or degrading existing product quality.
• Testability: Refers to how effective the test criteria is for a system, product,
or component. In addition, it also refers to the tests that can be performed to
determine whether the test criteria has been met.
Security
Security refers to how well a product or system protects information and data from
security vulnerabilities.
• Confidentiality: Refers to how well a product or system is able to ensure that
data is only accessible to those who have authorized access.
• Integrity: Refers to how well a system, product, or component is able to
prevent unauthorized access and modification to computer programs and/or
data.
• Non-repudiation: Refers to how well actions or events can be proven to have
taken place.
• Accountability: Refers to the actions of an unauthorized user can be traced
back to them.
• Authenticity: Refers to how well the identity of a subject or resource can be
proved.
Reliability
Reliability refers to how well a system, product, or component performs specified
functions under specified conditions.
• Maturity: Refers to how well a system, product, or component is able to
meet your needs for reliability.
• Availability: Refers to whether a system, product, or component is
operational and accessible.
• Fault Tolerance: Refers to how well a system, product, or component
operates despite hardware and/or software faults.
• Recoverability: Refers to how well a product or system can recover data
in the event of an interruption or failure.
Software Development Life Cycle

A systematic process for building software

that ensures the quality and correctness of
the software built.
• SDLC is a framework defining tasks
performed at each step in the
software development process
• defines all the tasks required for
developing and maintaining software
• SDLC is a process followed for a
software project
• well-organized process for building
software that guarantees the quality
and accuracy of the software created
Why SDLC is Important?
• It provides visibility for the engaged parties
• It allows to control the project
• Predictable deliveries throughout an entire development process
• Eliminating risks like going over budget or deadline breach
• The process goes on until all the requirements are met

What are SDLC Models?

There are various software development life cycle models defined and designed
which are followed during software development process. These models are also
referred as "Software Development Process Models". Each process model follows a
Series of steps unique to its type, in order to ensure success in process of software
development.
SDLC Models
Following are the most important and popular SDLC models (which will
discuss in this syllabus) followed in the industry:
• SDLC: Waterfall Model
• SDLC: Prototype Model
• SDLC: Spiral Model
• SDLC: Evolutionary Development Models
• SDLC: Iterative Enhancement Models.
• Agile Model
• DevOps Model
linear-sequential life cycle model.
• The Waterfall Model was the first Process Model developed by Winston W.
Royce in 1970. It is also referred to as a linear-sequential life cycle model. It is
very simple to understand and use. In a waterfall model, each phase must be
completed before the next phase can begin and there is no overlapping in the
phases.
• The Waterfall model is the earliest SDLC approach that was used for software
development.
• The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins
only if the previous phase is complete. In this waterfall model, the phases do
not overlap.
• In "The Waterfall" approach, the whole process of software development is
divided into separate phases. In this Waterfall model, typically, the outcome of
one phase acts as the input for the next phase sequentially.
The sequential phases in Waterfall model are:
• Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification doc.
• System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and helps in defining overall system architecture.
• Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.
• Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system: Once the functional and non-functional testing is done, the
product is deployed in the customer environment or released into the market.
• Maintenance: There are some issues which come up in the client environment. To fix
those issues patches are released. Also, to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
 Pros Cons
No working software is
Simple and easy to understand
Some situations where the use of and use
produced until late during the
life cycle.
Waterfall model is most appropriate Easy to manage due to the
are: rigidity of the model. Each phase High amounts of risk and

• Requirements are very well has specific deliverables and a uncertainty.

review process.
documented, clear and fixed. Phases are processed and Not a good model for complex
• Product definition is stable. completed one at a time. and object-oriented projects.
Works well for smaller projects
• Technology is understood and is where requirements are very
Poor model for long and ongoing
projects.
not dynamic. well understood.
Not suitable for the projects
• There are no ambiguous where requirements are at a
requirements. Clearly defined stages.
moderate to high risk of
changing. So, risk and
• Ample resources with required uncertainty is high with this
expertise are available to support process model.
It is difficult to measure progress
the product. Well understood milestones.
within stages.
• The project is short. Easy to arrange tasks.
Cannot accommodate changing
requirements.
Process and results are well Adjusting scope during the life
documented. cycle can end a project.
Iterative Waterfall Model
The iterative waterfall model
provides feedback paths from
every phase to its preceding
phases, which is the main
difference from the classical
waterfall model. When errors
are detected at some later
phase, these feedback paths
allow correcting errors
committed by programmers
during some phase. The
feedback paths allow the phase
to be reworked in which errors
are committed and these
changes are reflected in the
later phases.
 Iterative Waterfall Model
Pros Cons
Restricted Customer Interactions – In this model the
Feedback Path – In the iterative waterfall model
customer interaction is very least which may cause as
feedback path from one phase to its preceding phase
the final developed software may vary from the
allows correcting the errors that are committed
customers actual required software.

Change requests are difficult to incorporate –If

Simple – Iterative waterfall model is very simple to customer wants to change something in between of
understand and use the development, then there is no scope to incorporate
any change.

Well Organized – Due to less time consumption this Long time process – There is no scope of
model is beneficial as you can focus more on intermediate delivery. Customer will have to wait for
designing and development. a longtime to get their software.
Cost Effective – Changing the plan or requirements Overlapping is not supported – You cannot overlap
in the model is very cost-effective. Furthermore, it is phases like Real time Project. You will have to wait
ideally suited for dynamic businesses. for completion of phase to start another phase.
Prototype Model
What is Software Prototyping?

• Prototype is a working model of software with some limited

functionality.
• The prototype does not always hold the exact logic used in the
actual software application and is an extra effort to be considered
under effort estimation.
• Prototyping is used to allow the users evaluate developer
proposals and try them out before implementation.
• It also helps understand the requirements which are user specific
and may not have been considered by the developer during
product design.
Following is the stepwise approach to design a software prototype:
• Step-1: Requirements gathering and analysis: A requirement analysis is the first step in
developing a prototyping model. During this phase, the system’s desires are precisely defined.
During the method, system users are interviewed to determine what they expect from the
system.
• Step-2: Quick design: During this stage, the system’s basic design is formed. It provides the
user with a quick overview of the system. The rapid design aids in the development of the
prototype.
• Step-3: Build a Prototype: During this stage, an actual prototype is intended to support the
knowledge gained from quick design. It is a small low-level working model of the desired
system.
• Step-4: Initial user evaluation: The proposed system is presented to the client for preliminary
testing at this stage. Customer feedback and suggestions are gathered and forwarded to the
developer.
• Step-5: Refining prototype: When the user is satisfied with the upgraded model, a final system
based on the approved final type is created.
Rapid Throwaway Prototype
In this method, the prototype is developed rapidly based on the initial requirements and
given to the client for review. Once the client provides feedback, final requirements are
updated and work on the final product begins. As the name suggests, the developed
prototype is discarded, and it will not be part of the final product. It is also known as
close-ended prototyping.

Evolutionary Prototyping
In this method, a prototype is made, and the client feedback is received. Based on the
feedback, the prototype is refined until the client considers it the final product. It
follows an incremental development approach and saves time compared to the rapid
throwaway prototyping method as in evolutionary prototyping old prototype is
reworked rather than developing a new prototype from scratch. It is also known as
breadboard prototyping.
Incremental Prototyping:
The final product is decimated into small prototypes and developed individually in
incremental prototyping. The various prototypes are eventually combined into a single
product. This method is useful for reducing feedback time between the user and,
consequently, the application development team.

Extreme Prototyping: The extreme prototyping method is commonly used in web

development. It is divided into three stages that must be completed in order.
1. Static Prototype: The initial phase involves creating a basic prototype with all
existing pages in HTML format, along with a logical data model to support those
pages.
2. Functional UI Development: In the second phase, the screens are programmed and
made fully functional using a simulated services layer. This phase focuses on
developing the user interface with minimal regard to the actual services, except for
their contractual requirements.
3. Services Implementation: The final phase involves implementing the services,
integrating them with the UI, and refining the overall system.
 Prototype Model`
Pros Cons
Increased user involvement in the Risk of insufficient requirement analysis
product even before implementation owing to too much dependency on prototype
Since a working model of the system is
displayed, the users get a better Users may get confused in the prototypes and
understanding of the system being actual systems.
developed.
Practically, this methodology may increase
Reduces time and cost as the defects can
the complexity of the system as scope of the
be detected much earlier.
system may expand beyond original plans.
Developers may try to reuse the existing
Quicker user feedback is available
prototypes to build the actual system, even
leading to better solutions.
when its not technically feasible
Spiral Model
Each phase of Spiral Model is divided into four quadrants as shown in the figure. The
functions of these four quadrants are below:
1. Objectives determination and identify alternative solutions: Requirements are
gathered from the customers and the objectives are identified, elaborated and
analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible solutions
are evaluated to select the best possible solution. Then the risks associated with that
solution is identified and the risks are resolved using the best possible strategy. At
the end of this quadrant, Prototype is built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third quadrant,
the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for the
next phase is started.
Spiral Model as Meta Model

• The Spiral model is called as a Meta Model because it subsumes all the other
SDLC models. For example, a single loop spiral represents the Iterative
Waterfall Model.
• The spiral model incorporates the stepwise approach of the Classical
Waterfall Model.
• The spiral model uses the approach of Prototyping Model by building a
prototype at the start of each phase as a risk handling technique. Also, the
spiral model can be considered as supporting the evolutionary model – the
iterations along the spiral can be considered as evolutionary levels through
which the complete system is built.
 Pros Cons When Spiral Model is appropriate?
Changing requirements can Management is more
• When costs there is a budget
be accommodated. complex. constraint and risk evaluation is
Allows for extensive use of End of project may not be important.
prototypes known early. • For medium to high-risk projects.
Not suitable for small or • Long-term project commitment
Requirements can be low risk projects and could because of potential changes to
captured more accurately. be expensive for small economic priorities as the
requirements change with time.
projects.
• Customer is not sure of their
Users see the system early. Process is complex requirements which is usually the
Development can be divided case.
into smaller parts and more • Requirements are complex and
risky parts can be developed Spiral may go indefinitely. need evaluation to get clarity.
earlier which helps better • New product line which should
risk management. be released in phases to get
enough customer feedback.
Large number of
• Significant changes are expected
intermediate stages requires
in the product during the
excessive documentation. development cycle.
Iterative Enhancement Model
The iterative enhancement model in software engineering combines elements of the
linear sequential model with the iterative philosophy of prototyping. In this model, the
software is broken down into several modules which are incrementally developed and
delivered. Firstly, the development team develops the core module of the system. After
that, it is refined into increasing levels of capacity of adding new functionalities in
successive versions.
Iterative Model design
In this incremental model, the whole requirement is divided into various builds. During
each iteration, the development module goes through the requirements, design,
implementation and testing phases. Each subsequent release of the module adds function
to the previous release. The process continues till the complete system is ready as per the
requirement. During software development, more than one iteration of the software
development cycle may be in progress at the same time."
The key to a successful use of an iterative software development lifecycle is rigorous
validation of requirements, and verification & testing of each version of the software
against those requirements within each cycle of the model.
When to use Iterative Enhancement Model?
• Requirements of the complete system are clearly defined and understood.
• Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while
working on the project.
• Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
• There are some high-risk features and goals which may change in the future.
Advantages:
• Some working functionality can be developed quickly and early in the life
cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
Disadvantages:
• Not suitable for smaller projects.
• More management attention is required.
• Defining increments may require definition of the complete system
• End of project may not be known which is a risk.
• More resources may be required.
• System architecture or design issues may arise because not all requirements are
gathered in the beginning of the entire life cycle.
Evolutionary Model
Key Characteristics of the Evolutionary Model

• Iterative Process: The model is cyclic, meaning software evolves through

multiple iterations based on continuous feedback from customers.
• Customer-Centric: The focus is on customer feedback, with each version
improving based on customer input.
• Flexibility: As customer requirements change or new insights arise, the
design and functionality of the software can be adapted and improved in
subsequent versions.
In Evolutionary model, software requirements are fragmented into several chunks
that can be built and transferred incrementally. In other words, you develop a
skeleton of the product and in successive versions, you add more functionalities.
Services are not required for the core module (first stage) of the system. The
iterative waterfall model is used for developing an evolutionary model

Evolutionary software models resembles iterative enhancement model, but it

differs in the sense that this does not require a usable product at the end of each
cycle. In evolutionary development, requirements are implemented by category
rather than priority.
 “Iterative” + “Incremental model” = Evolutionary model

Application of Evolutionary Model

1. Large projects,
2. This model is used for the customer when they urge/want to use core features
rather than waiting for the complete software package.
3. They are widely used in object-oriented software development. As the system
can be partitioned into smaller object units.
Advantages:
• In evolutionary model, a user gets a chance to experiment partially developed
system.
• It reduces the error because the core modules get tested thoroughly.
Disadvantages:
• Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and
delivered.
The RAD (Rapid Application Development) model is a type of software
development methodology that emphasizes quick development and iteration of
prototypes with user feedback. It's designed to produce high-quality systems faster
than traditional methodologies like the Waterfall model, by focusing on reducing the
planning and prototyping time.
Phases of RAD:
1. Requirements Planning: A short phase where key stakeholders, including users,
meet to define the system requirements, scope, and objectives.
2. User Design: During this phase, users interact with the prototypes and provide
feedback. This is an iterative process where prototypes are revised based on user
input until they meet user expectations.
3. Rapid Construction: Developers focus on coding and creating working models
based on user designs and feedback. Modules are developed in parallel,
accelerating the process.
4. Cutover (Finalization): This phase includes system testing, data conversion, and
user training. Once the system is refined based on feedback, it is deployed for full
use.
Rapid Application Development (RAD)
Disadvantages of RAD

• Not Suitable for Large Projects: RAD works best for smaller to medium-
sized projects where requirements are flexible and well understood.
• Requires Strong Team Collaboration: It relies heavily on constant
communication between developers and stakeholders.
• Requires Highly Skilled Developers: Rapid prototyping demands a team
capable of quick and efficient development.

When to use RAD Model

• When a project requires fast delivery.

• Projects with well-understood and flexible requirements.
• Systems where user feedback and involvement are crucial during development.
 Comparison
of
SDLC Models
 Iterative
Features ↓ Waterfall Prototype Spiral Evolutionary
Enhancement
Not
Large Projects Not Suitable Suitable Suitable Suitable
Suitable
Detailed Yes, but not Yes, but not
Yes Yes Yes
Documentations much much
Cost Low Low Expensive Low Low
Risk High High Low Low Low
Linear Linear
Linear
+ +
Framework Linear Linear +
Iterative Iterative
Iterative

User Average (at Average (After

Low High High
Involvement initial stage) each cycle)
Change in
No Initial Level Yes Yes Yes
Requirements
 Case Study
for
SDLC Models
Case Study 1: I have a software project “Election management system ” and I want to
choose a process model what do you think is the suitable one?

Case Study 2: ABC is an international software house. ABC is currently working on a

project that is totally new for the development team and even the client is confused
about the requirements of this project. Hence this company is facing difficulties
because they fail to apprehend user requirements properly. For this project, it is
decided to build a sample application and show it to the client for feedback.
In the context of this above scenario as a project manager what will be the choice of
the software life cycle model?

Case Study 3: Suppose you are a project manager for a software product in a new and
growing market with your competitors who are also developing a product will be the
same product. Which model to select and why?
Case Study 4: We are creating an online hospital management system and it is
needed immediately, what kind of SDLC model should be used in our
documentation?

Case Study 5: Suppose, you are going to develop a system to control an Aircraft.
You have to design a perfect system, but you do not have any previous experience
about this project. Your system will be pioneer in this case, and you have to ensure
quality, but budget is not a fact because error may lead to a life-threatening
situation.

Case Study 6: A university wants to develop an “online student admission

system”. Explain which software development model should be suitable for this
application.
Contents of Unit-2

• Requirement Engineering Process: Elicitation, Analysis, Documentation

• Requirement Engineering Process: Review & Management of User Needs,
• Feasibility Study
• Information Modelling: Data Flow Diagrams & Entity Relationship
Diagrams
• Information Modelling: Decision Tables,
• SRS Document, IEEE Standards for SRS
• Software Quality Assurance (SQA): Verification and Validation
• SQA Plans
• Software Quality Frameworks, ISO 9000 Models, SEI-CMM Model