MURARAI GOVERNMENT

POLYTECHNIC
Topics
4th Sem 1. Introduction to Software
Engineering

Software 2. Software Development

Activities

Engineering
3. Software Testing Basics
4. Project Management
5. Software Quality Management
& Estimation
Wasim Hossain
Lecturer in Computer Science & Technology
Introduction to Software
Engineering
Unit 1
SDLC - Software Development Life Cycle
❏ SDLC stands for Software Development Life Cycle and is also referred to as the
Application Development life-cycle.
❏ SDLC is a systematic process for building software
❏ It ensures the quality and correctness of the software built.
❏ SDLC process aims to produce high-quality software
❏ The system development should be
complete in the pre-defined time frame and
cost.
❏ SDLC consists of a detailed plan which
explains how to plan, build, and maintain
specific software.
❏ Every phase of the SDLC life Cycle has its
own process and deliverables that feed into
the next phase.
SDLC Phases
The entire SDLC process divided into the following SDLC steps:

Phase 1: Requirement gathering and analysis Popular SDLC Models:

Phase 2: Feasibility study ● Waterfall Model
Phase 3: Design ● Agile Model
Phase 4: Coding/ Development ● Spiral Model
Phase 5: Testing ● V-Model
Phase 6: Deployment/ Installation ● Iterative Model
Phase 7: Maintenance ● RAD
● Prototype Model
● Incremental Model
● Big Bang Model
Phase 1: Requirement collection and analysis
❏ The requirement is the first stage in the SDLC process.
❏ It is conducted by the senior team members with inputs from all the
stakeholders and domain experts in the industry.
❏ Planning for the quality assurance requirements and recognition of the risks
involved is also done at this stage.
❏ This stage gives a clearer picture of the scope of the entire project and the
anticipated issues, opportunities, and directives which triggered the project.
❏ Requirements Gathering stage need teams to
get detailed and precise requirements. This
helps companies to finalize the necessary
timeline to finish the work of that system.
Phase 2: Feasibility study
❏ Once the requirement analysis phase is completed the next sdlc step is to
define and document software needs.
❏ This process conducted with the help of ‘Software Requirement Specification’
document also known as ‘SRS’ document.
❏ It includes everything which should be designed and developed during the
project life cycle.
❏ There are mainly five types of feasibilities checks:
1. Economic: Can we complete the project within the budget or not?
2. Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
3. Operation feasibility: Can we create operations which is expected by the client?
4. Technical: Need to check whether the current computer system can support the
software
5. Schedule: Decide that the project can be completed within the given schedule or
not.
Phase 3: Design
❏ In this third phase, the system and software design documents are prepared
as per the requirement specification document.
❏ This helps define overall system architecture.
❏ This design phase serves as input for the next phase of the model.
❏ There are two kinds of design documents developed in this phase:
1. High-Level Design (HLD) 2. Low-Level Design (LLD)
● Brief description and name of each module ● Functional logic of the modules
● An outline about the functionality of every ● Database tables, which include
module type and size
● Interface relationship and dependencies ● Complete detail of the interface
between modules ● Addresses all types of
● Database tables identified along with their key dependency issues
elements ● Listing of error messages
● Complete architecture diagrams along with ● Complete input and outputs for
technology details every module
Phase 4: Coding
❏ Once the system design phase is over, the next phase is coding.
❏ In this phase, developers start build the entire system by writing code using the
chosen programming language.
❏ In the coding phase, tasks are divided into units or modules and assigned to
the various developers.
❏ It is the longest phase of the Software Development Life Cycle process.
❏ In this phase, Developer needs to follow certain predefined coding guidelines.
❏ They also need to use
programming tools like
compiler, interpreters,
debugger to generate and
implement the code.
Phase 5: Testing
❏ Once the software coding is complete, and it is deployed in the testing
environment.
❏ The testing team starts testing the functionality of the entire system.
❏ This is done to verify that the entire application works according to the
customer requirement.
❏ During this phase, QA and testing team may find some bugs/defects which
they communicate to developers.
❏ The development team fixes the
bug and send back to QA for a
re-test.
❏ This process continues until the
software is bug-free, stable, and
working according to the
business needs of that system.
Phase 6: Deployment/ Installation
❏ Once the software testing phase is over and no bugs or errors left in the
system then the final deployment process starts.
❏ Based on the feedback given by the project manager, the final software is
released and checked for deployment issues if any.
Phase 7: Maintenance
❏ Once the system is deployed, and customers start using the developed
system, following 3 activities occur:-
1. Bug fixing – bugs are reported because of some scenarios which are
not tested at all
2. Upgrade – Upgrading the application to the newer versions of the
Software
3. Enhancement – Adding some new features into the existing software
❏ The main focus of this SDLC phase is to ensure that needs continue to be met
and that the system continues to perform as per the specification mentioned
in the first phase.
Waterfall Model
❏ Waterfall Model is a sequential model
❏ It divides software development into
pre-defined phases.
❏ Each phase must be completed before
the next phase can begin with no
overlap between the phases.
❏ Each phase is designed for performing
specific activity during the SDLC phase.
When to use Waterfall Model?
❏ Requirements are not changing frequently
❏ Application is not complicated and big
❏ Project is short
❏ Requirement is clear
❏ Environment is stable
❏ Technology and tools used are not dynamic and is stable
❏ Resources are available and trained
Advantages of WaterFall Model Disadvantages of WaterFall Model
● Before the next phase of development, ● Error can be fixed only during the phase
each phase must be completed

● Suited for smaller projects where ● It is not desirable for complex project
requirements are well defined where requirement changes frequently

● They should perform quality assurance ● Testing period comes quite late in the
test (Verification and Validation) before developmental process
completing each stage

● Elaborate documentation is done at ● Documentation occupies a lot of time of

every phase of the software’s developers and testers
development cycle

● Project is completely dependent on ● Clients valuable feedback cannot be

project team with minimum client included with ongoing development phase
intervention

● Any changes in software is made during ● Small changes or errors that arise in the
the process of the development completed software may cause a lot of
problems
Incremental Model
❏ Incremental Model is a process of software development where requirements
are broken down into multiple standalone modules of software development
cycle.
❏ Incremental development is done in steps from analysis design,
implementation, testing/verification, maintenance.
Incremental Model
❏ Each iteration passes through the requirements, design, coding and testing
phases. And each subsequent release of the system adds function to the
previous release until all designed functionality has been implemented.

❏ The system is put into production when the first increment is delivered.
❏ The first increment is often a core product where the basic requirements are
addressed, and supplementary features are added in the next increments.
❏ Once the core product is analyzed by the client, there is plan development for
the next increment.
When to use Incremental Model?
❏ Requirements of the system are clearly understood
❏ When demand for an early release of a product arises
❏ When software engineering team are not very well skilled or trained
❏ When high-risk features and goals are involved
❏ Such methodology is more in use for web application and product based
companies
Advantages of Incremental Model Disadvantages of Incremental Model
● The software will be generated quickly ● It requires a good planning designing
during the software life cycle

● It is flexible and less expensive to change ● Each iteration phase is rigid and does not
requirements and scope overlap each other

● Throughout the development stages ● Problems might cause due to system

changes can be done architecture as such not all requirements
collected up front for the entire software
lifecycle

● This model is less costly compared to ● Rectifying a problem in one unit requires
others correction in all the units and consumes a lot
of time

● Errors are easy to be identified

Spiral Model
❏ Spiral Model is a risk-driven software
development process model.
❏ It is a combination of waterfall model and
iterative model.
❏ Spiral Model helps to adopt software
development elements of multiple process
models for the software project based on
unique risk patterns ensuring efficient
development process.
❏ Each phase of spiral model begins with a
design goal and ends with the client
reviewing the progress.
❏ The spiral model was first mentioned by
Barry Boehm.
Spiral Model
❏ The development process in Spiral model, starts with a small set of
requirement and goes through each development phase for those set of
requirements.
❏ The software engineering team adds
functionality for the additional
requirement in every-increasing
spirals until the application is ready
for the production phase.
When to use Spiral Model?
❏ A Spiral model in software engineering is used when project is large
❏ When releases are required to be frequent, spiral methodology is used
❏ When creation of a prototype is applicable
❏ When risk and costs evaluation is important
❏ Spiral methodology is useful for medium to high-risk projects
❏ When requirements are unclear and complex, Spiral model in SDLC is useful
❏ When changes may require at any time
❏ When long term project commitment is not feasible due to changes in
economic priorities
 Advantages of Spiral Model Disadvantages of Spiral Model
● Additional functionality or changes ● Risk of not meeting the schedule or
can be done at a later stage budget

● Cost estimation becomes easy as the ● Spiral development works best for large
prototype building is done in small projects only also demands risk
fragments assessment expertise

● Continuous or repeated development ● For its smooth operation spiral model

helps in risk management protocol needs to be followed strictly

● Development is fast and features are ● Documentation is more as it has

added in a systematic way in Spiral intermediate phases
development

● There is always a space for customer ● Spiral software development is not

feedback advisable for smaller project, it might
cost them a lot
RAD Model
❏ RAD Model stands for Rapid Application Development model
❏ It is a software development process based on prototyping without any
specific planning.
❏ In RAD model, there is less attention paid to the planning and more priority is
given to the development tasks.
❏ It targets at developing software in a short span of time.
❏ SDLC RAD modeling has following phases
1. Business Modeling
2. Data Modeling
3. Process Modeling
4. Application Generation
5. Testing and Turnover
When to use RAD Model?
❏ When a system needs to be produced in a short span of time (2-3 months)
❏ When the requirements are known
❏ When the user will be involved all through the life cycle
❏ When technical risk is less
❏ When there is a necessity to create a system that can be modularized in 2-3
months of time
❏ When a budget is high enough to afford designers for modeling along with
the cost of automated tools for code generation
 Advantages of RAD Model Disadvantages of RAD Model
Flexible and adaptable to changes It can’t be used for smaller projects

It is useful when you have to reduce the Not all application is compatible with RAD
overall project risk

It is adaptable and flexible to changes When technical risk is high, it is not suitable

With less people, productivity can be Requires highly skilled designers or developers
increased in short time

Each phase in RAD delivers highest priority Progress and problems accustomed are hard
functionality to client to track as such there is no documentation to
demonstrate what has been done
Prototype Model
❏ In Prototyping Model, prototype is built, tested, and reworked until an
acceptable prototype is achieved.
❏ It also creates base to produce the final system or software.
❏ It works best in scenarios where the project’s requirements are not known in
detail.
❏ It is an iterative, trial and error method which takes place between developer
and client.
When to use Prototype Model?
❏ You should use Prototyping when the requirements are unclear
❏ It is important to perform planned and controlled Prototyping.
❏ Regular meetings are vital to keep the project on time and avoid costly delays.
❏ The users and the designers should be aware of the prototyping issues and
pitfalls.
❏ At a very early stage, you need to approve a prototype and only then allow
the team to move to the next step.
❏ In software prototyping method, you should never be afraid to change earlier
decisions if new ideas need to be deployed.
❏ You should select the appropriate step size for each version.
❏ Implement important features early on so that if you run out of the time, you
still have a worthwhile system
 Advantages of Prototype Model Disadvantages of Prototype Model
Users are actively involved in development. Prototyping is a slow and time taking process.
Therefore, errors can be detected in the initial The cost of developing a prototype is a total waste
stage of the software development process. as the prototype is ultimately thrown away.

Helps team member to communicate effectively Prototyping may encourage excessive change
requests.

Customer satisfaction exists because the customer Some times customers may not be willing to
can feel the product at a very early stage. participate in the iteration cycle for the longer time
duration.

Quicker user feedback helps you to achieve better There may be far too many variations in software
software development solutions requirements when each time the prototype is
evaluated by the customer.

Encourages innovation and flexible designing. Poor documentation because the requirements of
the customers are changing.

It is a straightforward model, so it is easy to It is very difficult for software developers to

understand. accommodate all the changes demanded by the
 Properties of WaterFall Incremental
Spiral Model RAD Model
Model Model Model
Planning in early stage Yes Yes Yes No

Returning to an earlier
No Yes Yes Yes
phase

Handle Large-Project Not Appropriate Not Appropriate Appropriate Not Appropriate

Detailed Documentation Necessary Yes but not much Yes Limited

Cost Low Low Expensive Low

Requirement Time boxed

Beginning Beginning Beginning
Specifications release

Flexibility to change Difficult Easy Easy Easy

User Involvement Only at beginning Intermediate High Only at the beginning

Maintenance Least Promotes Maintainability Typical Easily Maintained

 Properties of WaterFall Incremental
Spiral Model RAD Model
Model Model Model
Re-usability Least possible To some extent To some extent Yes

Time-Frame Very Long Long Long Short

Working software At the end of the At the end of every At the end of every At the end of the
availability life-cycle iteration iteration life cycle

Rapid
Objective High Assurance Rapid Development High Assurance
development

Team size Large Team Not Large Team Large Team Small Team

Customer control over

Very Low Yes Yes Yes
administrator
Software Development
Activities
Unit 2
Software Engineering core principles
Software engineering is a discipline that encompasses principles and practices for
developing high-quality defect free software systems. Some core principles are -
● Modularity: Break down software systems into smaller, self-contained modules.
● Abstraction: Hide unnecessary details and expose relevant information.
● Encapsulation: Bundle related data and functions into cohesive units.
● Modifiability: Design software systems to be easily adaptable.
● Maintainability: Develop software systems that are easy to understand,
enhance, and fix.
● Testability: Design software systems for effective testing and validation.
● Scalability: Build software systems that can handle increasing workloads.
● Reusability: Design software components for multiple contexts or projects.
● Security: Incorporate measures to protect software systems and data.
Communication in Software Engineering
Great communication is the most important characteristic for success as a software
engineer. It helps in-
● Requirement gathering: Effective communication for understanding and gathering
requirements.
● Team collaboration: Clear communication promotes coordination and problem-solving.
● Documentation: Concise documentation facilitates understanding and maintenance.
● Client/stakeholder engagement: Regular communication keeps clients informed and
involved. Engaging with users helps understand their needs.
● Technical discussions: Clear communication improves decision-making.
● Conflict resolution: Effective communication resolves conflicts.
● Change management: Communication facilitates managing changes.
● Risk and issue communication: Transparent communication addresses project risks and
issues
Project Planning in Software Engineering:
Before starting a software project, it is crucial to identify tasks and effectively
distribute them among project participants. Here are key aspects:
● Goal Definition: Clearly define project goals and objectives.
● Scope Definition: Determine the boundaries and deliverables of the project.
● Task Identification: Identify specific tasks required to achieve project goals.
● Task Scheduling: Determine the order and dependencies among tasks.
● Resource Allocation: Assign resources (people, time, budget) to tasks.
● Timeline Creation: Develop a realistic timeline for project execution.
● Risk Assessment: Identify potential risks and plan mitigation strategies.
● Communication Plan: Establish a plan for effective project communication.
● Monitoring : Regularly monitor progress and make necessary adjustments.
● Documentation: Maintain proper documentation for future reference and
knowledge transfer.
Software Modelling
● Software modeling creates representations of a software system.
● Models capture system structure, behavior, and interactions.
● UML, data flow diagrams, state diagrams, and more are common modeling
techniques.
● Models aid in understanding, visualizing, and communicating system design
and requirements.
● Models serve as blueprints for software development, supporting analysis,
design, and documentation.
Software Construction
● Software construction involves writing and implementing the code for a
software system.
● It translates software design and specifications into functional programming
code.
● Key activities include coding, debugging, unit testing, and component
integration.
● Good coding practices, such as following standards and modular design, are
important.
● It is a critical phase of the
software development
lifecycle where the software
product is created and refined.
Software Deployment principles
Software deployment principles involve the process of releasing and installing
software into a production environment. Key principles include:
● Automation: Automate deployment processes to ensure consistency and
reduce human error.
● Version Control: Use version control systems to track software releases and
manage configurations.
● Environment Management: Maintain separate environments for development,
testing, and production to minimize disruptions.
● Rollback and Recovery: Implement mechanisms to rollback or recover from
failed deployments.
● Monitoring: Continuously monitor the deployed software for performance,
errors, and security vulnerabilities.
● Documentation: Maintain documentation of deployment procedures for
reference and knowledge transfer.
Software Requirements Engineering Tasks
● Requirement Gathering: Gathering information about system objectives and
stakeholder needs.
● Analysis: Understanding and resolving conflicts or ambiguities in requirements.
● Documentation: Structured documentation of requirements for clarity and
shared understanding. SRS
● Validation: Checking requirements for correctness, consistency, and feasibility.
● Prioritization: Collaboratively prioritizing requirements based on importance
and constraints.
● Change Management: Managing changes to requirements throughout the
project.
● Communication: Effective communication of requirements to stakeholders and
team members.
Initiating the requirement process
● Define project scope and objectives.
● Identify key stakeholders.
● Understand stakeholder needs and priorities.
● Plan the requirement process.
● Gather requirements through interviews, workshops, and surveys.
● Document requirements in a structured manner.
● Validate requirements for correctness and feasibility.
● Obtain stakeholder agreement and sign-off.
● Establish a baseline version of requirements.
● Implement change management for requirement updates.
Object oriented Analysis
● Identify Objects: Identify and define the key objects in the problem domain.
● Define Relationships: Determine the relationships between objects, such as
associations, dependencies, and inheritances.
● Analyze Behavior: Analyze the behavior of objects through scenarios, use cases,
and state diagrams.
● Identify Attributes: Determine the attributes and properties of objects.
● Refine and Iterate: Refine the analysis through iterations, ensuring accuracy
and completeness of the object model.
Flow-oriented model
● Flow-oriented model focuses on the flow of data and control between
components.
● Components represent data transformation or processing activities.
● Emphasizes sequential processing and data dependencies.
● Data flow diagrams depict the flow of data through the system.
● Useful for modeling information systems, business processes, and data
transformations.
● Supports analysis of system behavior and identification of bottlenecks or
inefficiencies.
● Provides a visual representation of the system's flow of data and control.
Class-Based model
● Class-based modeling is a modeling technique used in object-oriented
programming.
● Classes represent the blueprint for creating objects with shared characteristics
and behaviors.
● Classes encapsulate data and functions into cohesive units.
● Inheritance allows classes to inherit attributes and behaviors from other
classes.
● Associations define relationships between classes, such as one-to-one or
one-to-many.
● Class diagrams visualize the structure and relationships between classes.
Behavioural Model
● A behavioral model represents the dynamic aspects of a system's functionality
and behavior.
● It captures how the system interacts with external entities and responds to
events.
● Behavioral models use techniques like use cases, activity diagrams, state
diagrams, and sequence diagrams.
● These models help understand system behavior, requirements, and interactions
between components.
● They aid in system design, testing, and validation.
COMPARISON
FUNCTION ORIENTED DESIGN OBJECT ORIENTED DESIGN
FACTORS

The basic abstractions are not the real world functions but
The basic abstractions, which are given to the
Abstraction are the data abstraction where the real world entities are
user, are real world functions.
represented.

Function-Oriented Design organizes Object-Oriented Design structures the program around

Function
functionality into functions objects and their interactions

carried out using structured analysis and

execute Carried out using UML
structured design i.e, data flow diagram

In this approach the state information is not represented in

State In this approach the state information is often
a centralized memory but is implemented or distributed
information represented in a centralized shared memory
among the objects of the system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the use case diagrams

Begins basis Begins by identifying objects and classes.
Coupling
❏ The coupling is the degree of interdependence between software modules.
❏ There are two types of coupling:-
(i) Tight or High coupling
(ii) Loose or Low coupling.
❏ High coupling implies strong interdependency, increasing complexity.
❏ Low coupling promotes flexibility and reusability.
❏ A good software will have Loose or low coupling.
Cohesion
❏ Cohesion is an indication that shows the relationship within modules.
❏ Cohesion provides the information about the functional strength of the
modules.
❏ A good software design will have high cohesion.
❏ Cohesion is basically the dependency between internal elements of modules like
methods and internal modules.
❏ High cohesion will allow us to
reuse the classes and methods.
❏ Few of the most popular types of
cohesins are-
● Functional cohesion
● Sequential cohesion
● Logical cohesion.
 Cohesion Coupling
Cohesion is the measure of degree of relationship Coupling is the measure of degree of relationship
between elements of a module. between different modules.
It is an intra module concept. It is an inter module concept.
It represents relationships within the module. It helps represent the relationships between the
modules.
Increased cohesion is considered to be good for the Increased coupling has to be avoided in software.
software.
It represents the functional strength of the modules. It represents the independence among the
modules.
When modules are highly cohesive, a high quality When the modules are loosely coupled, it results
software is built. in a high quality software.
In cohesion, module focuses on the single thing. The modules would be connected to each other.
Software Testing Basics
Unit 3
Software testing
● Software Testing is the process of assessing/ evaluate software products.
● It is used to identify defects, errors, or gaps between expected and actual
results.
● The goal of ensuring quality and reliability.

Advantages of software testing:-

❏ Improved software quality and reliability
❏ Early identification and fixing of defects
❏ Improved customer satisfaction
❏ Increased stakeholder confidence
❏ Reduced maintenance costs
Types of Testing
Unit Testing
❏ Unit testing focuses on individual units or components of a software system.
❏ It is the first level of functional testing.
❏ Tested during the development phase of the software.
❏ Unit testing is typically performed by developers.
❏ The purpose of unit testing is to validate that each unit of the software works
as intended and meets the requirements.

Advantages of Unit Testing :

● Early defect detection and prevention.
● Improved code quality and design.
● Faster debugging and issue isolation.
● Rapid feedback loop for developers.
● Reduces time and effort in the long run.
Integration testing
● Integration testing is the second level of the software testing process comes
after unit testing.
● In this testing, units or individual components of the software are tested in a
group.
● The focus of the integration testing level is
to expose defects at the time of
interaction between integrated
components or units.
● It ensures that integrated components
function correctly together.
Regression Testing
● Regression testing ensures that changes or fixes in software do not introduce
new defects or cause previously working functionalities to fail.
● Regression Testing is nothing but a full or partial selection of already executed
test cases that are re-executed to ensure existing functionalities work fine.
● This testing is done to ensure that new code changes do not have side effects
on the existing functionalities.
● It ensures that the old code still works once the latest code changes are done.
● Regression testing is an important part of the software maintenance process to
maintain product quality over time.
Smoke Testing
● Smoke testing, also known as “Build Verification Testing” or “Build Acceptance
Testing”
● Smoke Testing is a software testing process that determines whether the
deployed software build is stable or not.
● Smoke testing is a confirmation for QA team to proceed with further software
testing.
● It consists of a minimal set of tests run on
each build to test software functionalities.
Smoke testing is also known as “Build
Verification Testing” or “Confidence
Testing.”
● In simple terms, smoke tests means
verifying the important features are
working and there are no showstoppers in
Unit Testing Technique
There are 3 types of Unit Testing Techniques. They are-

1. Black Box Testing: This testing technique is used in covering the unit tests for
input, user interface, and output parts.
2. White Box Testing:
● It involves testing the internal structure and workings of a software
application.
● The tester has access to the source code and uses this knowledge to design
test cases that can verify the correctness of the software at the code level.
● It is also called glass box testing or clear box testing or structural testing or
transparent testing or open box testing.
3. This technique is used in testing the functional behavior of the system by giving
the input and checking the functionality output including the internal design
structure and code of the modules.
 Criterion Alpha Testing Beta Testing
Performed Performed at the developer’s site. Performed at the client’s/ end-user site

Time of testing Before launching the product for release At the time of product marketing

Checks for functionality, internal design, and Checks for reliability and security in detail.
Validation
system requirements. Acceptance Testing. Acceptance Testing.

Ensures product quality and design, making it

Goals Evaluate customer satisfaction for full release
ready for beta testing

Testing Type Covers black-box and white-box testing Covers black-box testing

Duration More Time. Includes multiple test cycles. Less Time. A few test cycles are required

Developers immediately work on any identified Feedback received is usually implemented as future
After testing
issues or bugs versions of product
Recovery Testing
● Recovery Testing is software testing technique which verifies software’s ability
to recover from failures like software/hardware crashes, network failures etc.
● The purpose of Recovery Testing is to determine whether software operations
can be continued after disaster or integrity loss.
● Recovery testing involves reverting back software to the point where integrity
was known and reprocessing transactions to the failure point.
Performance Testing
● Performance Testing is a software testing process used for testing the speed,
response time, stability, reliability, scalability, and resource usage of a software
application under a particular workload.
● The main purpose of performance testing is to identify and eliminate the
performance bottlenecks in the software application.
● It is a subset of performance engineering and is also known as “Perf Testing”.
● The focus of Performance Testing is checking a software program’s
a. Speed – Determines whether the application responds quickly
b. Scalability – Determines the maximum user load the software application can
handle.
c. Stability – Determines if the application is stable under varying loads
Stress Testing
● Stress Testing is a type of software testing that verifies stability & reliability of
software application.
● The goal of Stress testing is measuring software on its robustness and error
handling capabilities under extremely heavy load conditions and ensuring that
software doesn’t crash under crunch situations.
● It even tests beyond normal operating points and evaluates how software
works under extreme conditions.
Security Testing
● Security Testing is a type of Software Testing that uncovers vulnerabilities,
threats, risks in a software application and prevents malicious attacks from
intruders.
● The purpose of Security Tests is to
identify all possible loopholes and
weaknesses of the software system
which might result in a loss of
information, revenue, repute at the
hands of the employees or outsiders
of the Organization.
Parameter Black Box testing White Box testing
Test the software without the knowledge of the It is a testing approach in which internal
Definition
internal structure of program or application. structure is known to the tester.

Knowledge Doesn’t require programming knowledge Require programming knowledge

The main goal to test the internal

Goal The main goal to test the behavior of the software
operation of the system

time It is not a time-consuming process It is a time-consuming process

Basis for test Testing can start after preparing requirement Testing can start after preparing for Detail
cases specification document. design document.

Tested by Performed by the end user, developer, and tester. Usually done by tester and developers.

Time It is less exhaustive and time-consuming. Exhaustive and time-consuming method.

Code Access Code access is not required Code access required

It allows removing the extra lines of code,

Benefit Well suited and efficient for large code segments.
which can bring in hidden defects.
 Testing Description Who performs
Unit Testing Testing is done on an individual unit or component to test its Developer/ Programmer

Integration Integration testing is testing in which a group of components is combined

QA/ Tester
Testing to produce output.

Every time a new module is added leads to changes in the program. This
Regression type of testing makes sure that the whole component works properly even QA/ Tester
after adding components to the complete program.

To make sure that the software under testing is ready or stable for further
Smoke Testing testing
QA/ Tester

Testing is performed without knowing the internal structure, design, or

Black box code of a system under test
QA/ Tester

White box testing is a test technique in which the internal structure or Developer
White box code of an application is visible and accessible to the tester. (QA also can also do it)

It is a type of acceptance testing which is done before the product is

Alpha released to customers
QA/ Tester

It is conducted by one or more customer sites by the end-user of the

Beta software.
Customer/ End user
Project Management
Unit 4
What is Project?
❏ A project is a group of tasks that need to
complete to reach a clear result.
❏ A project also defines as a set of inputs and
outputs which are required to achieve a
goal.
❏ Projects can vary from simple to difficult
and can be operated by one person or a
hundred.
❏ Projects usually described and approved by
a project manager or team executive. For
good project development, some teams
split the project into specific tasks so they
can manage responsibility and utilize team
strengths.
Software Project Management
❏ Software project management is an art and discipline of planning and supervising
software projects.
❏ It is a sub-discipline of software project management in which software projects
planned, implemented, monitored and controlled.
❏ It is a procedure of managing, allocating and timing resources to develop
computer software that fulfills requirements.
❏ In software Project Management, the client and the developers need to know the
length, period and cost of the project.
❏ There are three needs for software project management. These are:
1. Time
2. Cost
3. Quality
❏ It is an essential part of the software organization to deliver a quality product,
keeping the cost within the client's budget and deliver the project as per schedule.
❏ There are various factors, both external and internal, which may impact this triple
factor. Any of three-factor can severely affect the other two.
Project Manager
❏ A project manager has the overall responsibility for the planning, design,
execution, monitoring, controlling and closure of a project.
❏ Who represents an essential role in the achievement of the projects.
❏ Who is responsible for giving decisions, both large and small projects.
❏ The project manager is used to manage the risk and minimize uncertainty.
❏ Every decision the project manager makes must directly profit their project.
Responsibilities of a Project Manager:
❏ Managing risks and issues.
❏ Create the project team and assigns tasks to several team members.
❏ Activity planning and sequencing.
❏ Monitoring and reporting progress.
❏ Modifies the project plan to deal with the situation.
The Management Spectrum - 4 P’s
❏ To properly build a product, there’s a very important concept that we all
should know in software project planning while developing a product.
❏ There are 4 critical components in software project planning which are known
as the 4P’s namely:
1. Product
2. Process
3. People
4. Project
The Management Spectrum - 4 P’s - People
❏ The most important component of a product and its successful
implementation is human resources.
❏ To build a proper product, a well-managed team with clear-cut roles defined
for each person/team will lead to the success of the product.
❏ We need to have a good team in order to save our time, cost, and effort.
❏ Some assigned roles in software project planning are project manager, team
leaders, stakeholders, analysts, and other IT professionals.
❏ Managing people successfully is a tricky process which a good project manager
can do.
The Management Spectrum - 4 P’s - Product
❏ As the name inferred, this is the deliverable or the result of the project.
❏ The project manager should clearly define the product scope to ensure a
successful result, control the team members, as well technical hurdles that he
or she may encounter during the building of a product.
❏ The product can consist of both tangible or intangible such as shifting the
company to a new place or getting a new software in a company.
The Management Spectrum - 4 P’s - Process
❏ In every planning, a clearly defined process is the key to the success of any
product.
❏ It regulates how the team will go about its development in the respective time
period.
❏ The Process has several steps involved like, documentation phase,
implementation phase, deployment phase, and interaction phase.
The Management Spectrum - 4 P’s - Project
❏ The last and final P in software project planning is Project.
❏ In this phase, the project manager plays a critical role.
❏ They are responsible to guide the team members to achieve the project’s
target and objectives, helping & assisting them with issues, checking on cost
and budget, and making sure that the project stays on track with the given
deadlines.
Project Scheduling
❏ Project Scheduling refers to roadmap of all activities to be done with
specified order and within time slot allotted to each activity.
❏ Project scheduling is an important project planning activity.
❏ It is used to decide which tasks would be taken up when and by whom.
❏ The project schedule must be accessible to every team member.
❏ So, it must be comprehensive and easy to understand.
Project Scheduling
To schedule the project plan, a project manager needs to do the following:
1. Identify all the major activities required to complete the project.
2. Break down each activities into small tasks.
3. Determine the dependency among different activities.
4. Establish the estimates for the time durations necessary to
complete the tasks
5. Allocate resources to tasks.
6. Plan the Start and End dates for different tasks.
7. Determine the critical path. A critical way is the group of activities
that decide the duration of the project.
Advantages of Project Scheduling
❏ It simply ensures that everyone remains on same page as far as tasks get
completed, dependencies, and deadlines.
❏ Assists with tracking, reporting, and communicating progress.
❏ It helps in identifying issues early and concerns such as lack or unavailability of
resources.
❏ It also helps to identify task relationships and to monitor process.
❏ Monitors progress and identify issues early
❏ It provides effective budget management and risk mitigation.
Relationship between People and Effort
❏ If software size is small single person can handle same project by performing
steps like requirement analysis, designing, code generation, and testing etc.
❏ If the project is large additional people are required to complete the project in
stipulated in time it become easy to complete project by distributing work
among people and get it done as early as possible.
❏ It is possible to reduce a desire project completion date by getting more
people to same point. It also possible to expand the completion date by
reducing number of resources. And you can mention for the date of
completion.
 40-20-40 Distribution of Effort
❏ A recommended distribution of effort across the software process is-
40% (analysis and design), 20% (coding), and 40% (testing)
❏ Project planning rarely accounts for more than 2 - 3% of the total effort
❏ Requirements analysis may comprise 10 - 25% (Effort spent on prototyping and
project complexity may increase this Software design normally needs 20 – 25%)
❏ Coding should need only 15 - 20% based on the effort applied to software design
❏ Testing and subsequent debugging can account for 30 - 40%. (Safety or
security-related software requires more time for testing)

Example: 100-day project

Defining Task for Software Project
❏ Each software engineering action (Communication, Planning, Modeling, etc) can
be represented by a task set, or series of tasks to do to complete the action.
❏ A task set is a collection of software engineering work tasks , milestones and
work products that must be accomplished to achieve high software quality.
❏ Regardless of the process model that is chosen the work that a software team
performs is achieved through a set of tasks that enable us to define develop and
ultimately support computer software.
❏ Depending upon the size of the project, and the needs of the project, the
number of task could vary.
❏ No single task set is appropriate for all projects.
❏ A task set is the work breakdown structure for the project
❏ The task set should provide enough discipline to achieve high software quality.
Defining a Task Network
❏ Task network is also called an activity network
❏ It is a graphic representation of the task flow for a project.
❏ It depicts task length, sequence, concurrency, and dependency
❏ It points out inter- task dependencies
❏ Easy to find out the Critical Path.

Critical Path.
● A single path leading from start to finish in a task network
● It contains the sequence of tasks that must be completed on schedule
if the project as a whole is to be completed on schedule
● It also determines the minimum duration of the project
Risk Management
❏ A risk is any anticipated unfavourable event or circumstance that can occur
while a project is underway.
❏ These potential issues might harm cost, schedule or technical success of the
project and the quality of our software device, or project team morale.
❏ Risk Management is the system of identifying, analysis and eliminating/Risk
control these problems before they can damage the project.
❏ Need to differentiate risks, as potential
issues, from the current problems of the
project.
❏ We need to differentiate risks, as
potential issues, from the current
problems of the project.
Risk Management Process
1. Risk identification
Identify project, product and business risks;
2. Risk analysis
Assess the likelihood and consequences of these risks;
3. Risk planning
Draw up plans to avoid or minimise the effects of the risk;
4. Risk monitoring
Monitor the risks throughout the project;
Risk Management: classifications
Risk management can be further classify into the below categories:-
1. Known risks:
Those risks that can be uncovered after careful assessment of the project
program, the business and technical environment in which the plan is being
developed, and more reliable data sources (e.g., unrealistic delivery date)

2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)

3. Unpredictable risks: Those risks that can and do occur, but are extremely tough
to identify in advance.
Risk Identification
❏ Identifying risk is one of most important or essential and initial steps in risk
management process.
❏ The project organizer needs to anticipate the risk in the project as early as
possible so that the impact of risk can be reduced by making effective risk
management planning.
❏ For identifying risk, project team should review scope of program, estimate cost,
schedule, technical maturity, parameters of key performance, etc.
❏ There are different types of risks which can affect a software project:
1. Technology risks
2. People risks
3. Organizational risks
4. Tools risks
5. Requirement risks
6. Estimation risks
Different types of risks which can affect a software project
1. Technology risks:
● Risks that assume from the software or hardware technologies that are
used to develop the system.
● E.g Irctc website suffers this risk…..
2. People risks:
● It is impossible to recruit staff with skills required.
● Key staff is ill and is unavailable at critical times.
● E.g if some very innovative project is taken by the company
3. Organizational risks:
● Organization is restructured so that different management is
responsible for the project.
● Organizational financial problems force reduction in the budget.
Different types of risks which can affect a software project
4. Tools risks:
● Risks that assume from the software tools and other support software
used to create the system.
5. Requirement risks:
● Changes in requirement that require major design rework are
proposed.
● Customers fail to understand the impact of requirement changes.
6. Estimation risks:
● The time required to develop software is underestimated.
● The rate of defect repair is underestimated.
● The size of software in underestimated.
 PROACTIVE STRATEGIES REACTIVE STRATEGIES

Meaning Strategies used to anticipate future events Strategies used to deal with events after
in the market they have occurred

Purpose Respond to anticipated challenges Dealing with unanticipated events

Used on threats, opportunities and

Applicable on events that take place in the
Applicability challenges that are expected to take place
present
in the future

Crisis
Decrease crisis management efforts React after crisis has taken place
management
 Reactive
vs
Proactive Strategies
 Risk analysis
❏ Assess probability and seriousness of each risk.
❏ Probability may be very low, low, moderate, high or very high.
❏ Risk effects might be catastrophic, serious, tolerable or insignificant.
Risk Probability Effect
Organizational financial problems force reduction in the project Low Catastrophic
budget.

It is impossible to recruit staff with skills required for the project. High Catastrophic

Key staff are ill at critical times in the project. Moderate Serious

Changes in requirement that require major design rework Moderate Serious

The organization is restructured so that different management are High Serious

responsible for the project.
 Risk analysis
Risk Probability Effect
The database used in the project cannot process as many Moderate Serious
transactions per second as expected.

The time required to develop software is underestimated. High Serious

Required Training for staff is not available Moderate Tolerable

The size of software is underestimated Moderate Tolerable

Risk Planning
❏ Consider each risk and develop a strategy to manage that risk.
❏ Three common strategies are used
1. Avoidance strategies
The probability that the risk will arise is reduced;
2. Minimisation strategies
The impact of the risk on the project or product will be reduced;
3. Contingency plans
If the risk arises, contingency plans are plans to deal with that risk;
Risk Management Strategies

Risk Strategy
Organizational Financial Prepare a brief document for senior management showing
Problems how project is making a very important contribution to goals of
the business.

Recruitment problems Alert customer of potential difficulties and the possibility of

delays, investigate buying-in components.

Staff illness Reorganize team so that there is more overlap of work and
people therefore understand each others jobs.

Defective components Replace potentially defective components with bought in

components of known reliability
Risk Management Strategies

Risk Strategy
Requirements Changes List information on requirements change impact, maximize
information hiding in the design.

Organizational restructuring Prepare a brief document for senior management showing

how the project is making a very important contribution to
goals of the business.

Database performance Investigate the possibility of higher-performance database.

Underestimated Investigate buying in components, investigate use of program

development generator.
Risk Monitoring
❏ Assess each identified risks regularly to decide whether or not it is becoming
less or more probable.
❏ Also access whether the effects of the risk have changed.
❏ Each key risk should be discussed at management progress meetings.
Risk Indicators
Risk Type Potential Indicators
Technology Late delivery of hardware or support software, may be reported
technology problems.

People Poor staff morale, poor relationship amongst team member, job
availability

Organizational Organizational Gossip,lack of attention by senior management.

Tools Reluctance by team members to use tools, Complaint about CASE

tools, demands for higher- powered workstations

Requirements Many requirement change request, customer complaints.

Estimation Failure to meet agreed schedule, failure to clear reported defects.

Risk Monitoring
❏ As the project proceeds, risk monitoring activities commence.
❏ The project manager monitors factors that may provide an indication of whether
the risk is becoming more or less likely.
❏ In the case of high staff turnover, the following factors can be monitored:
● General attitude of team members
based on project pressures.
● Interpersonal relationships among
team members.
● Potential problems with
compensation and benefits.
● The availability of jobs within the
company and outside it.
Risk Management
❏ Risk management and contingency planning assumes that mitigation efforts
have failed and that the risk has become a reality.
❏ Continuing the example, the project is well underway, and a number of people
announce that they will be leaving.
❏ If the mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team.
❏ In addition, the project manager may temporarily refocus resources (and
readjust the project schedule) to those functions that are fully staffed, enabling
newcomers who must be added to the team to “get up to the speed“.
Change control | Change Management
❏ Change Management in software development refers to the transition from an
existing state of the software product to another improved state of the product.
❏ It controls, supports, and manages changes to artifacts, such as code changes,
process changes, or documentation changes.
❏ Where CCP (Change Control Process) mainly identifies, documents, and
authorizes changes to a software application.
Change Management Steps
Importance of Change Management
● For improving performance
● For increasing engagement
● For enhancing innovation
● For including new technologies
● For implementing new requirements
● For reducing cost
Software Configuration Management - SCM
● Software Configuration
Management(SCM) is a process to
systematically manage, organize, and
control the changes in the
documents, codes, and other entities
during the Software Development
Life Cycle.
● The primary goal is to increase
productivity with minimal mistakes.
● SCM is part of cross-disciplinary field
of configuration management
● It can accurately determine who
Importance of SCM
❏ There are multiple people working on software which is continually updating
❏ It may be a case where multiple version, branches, authors are involved in a
software config project, and the team is geographically distributed and works
concurrently.
❏ Any change in the software
configuration Items will affect the final
product. Therefore, changes to
configuration items need to be
controlled and managed.
Participant of SCM process
Steps of SCM
1. Configuration Identification
2. Baselines
3. Change Control
4. Configuration Status Accounting
5. Configuration Audits and Reviews
Cleanroom software development
● Set of principles and practices for software management, specification, design,
and testing.
● Produce quality software
● Increase productivity
● Reduce cost
● Emphasis on defect prevention rather than defect removal.

Formal vs Cleanroom Software development

In formal software engineering Testing/ QA (Quality Assurance) is occurs at the
completion of all development stages while there is a chance of less reliable and
fewer quality products full of bugs, and errors and upset client, etc.
But in cleanroom software engineering, Testing/ QA (Quality Assurance) is
performed each and every phase of software devel
 Software Quality
Management & Estimation
Unit 5
Software Quality Assurance(SQA)
● Software Quality Assurance (SQA) is a systematic process that ensures the
development and maintenance of defect free high-quality software.
● It involves a set of activities and techniques designed to prevent defects, identify
and correct errors, and enhance the overall quality of software products.
● SQA aims to meet customer expectations, improve user satisfaction, and
minimize risks associated with software development.
● SQA involves a range of activities that are aimed at preventing defects or bugs in
the software, as well as detecting and fixing any defects that do occur.
● It involves both manual and automated testing, as well as the use of various
tools and techniques to detect defects.
Software Quality Assurance(SQA)
Quality Assurance methodology has a defined cycle called PDCA cycle. The phases are:
1. Plan: Recognize an opportunity and plan a change.
2. Do: Test the change. Carry out a small-scale study.
3. Check: Review the test, analyze the results, and identify what you’ve learned.

4. Act: Take action based on what you learned in the

study step. If the change did not work, go through the
cycle again with a different plan. If you were successful,
incorporate what you learned from the test into wider
changes. Use what you learned to plan new
improvements, beginning the cycle again.
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.
Software Quality Assurance(SQA) Cont.
1. Requirements analysis: This involves reviewing the software requirements to
ensure that they are clear, complete, and testable.
2. Design review: This involves reviewing the software design to ensure that it is
appropriate for the requirements.
3. Code review: This involves reviewing the software code to ensure that it is
correct, efficient, and maintainable.
4. Testing: This involves testing the software to ensure that it meets the
requirements and is free of defects.
5. Reporting and tracking defects: This involves reporting any defects that are
found during testing and tracking them through to resolution.
6. Process improvement: This involves analyzing the SQA process and identifying
areas for improvement, such as improving testing methodologies or refining
Statistical software quality assurance
❏ Statistical software quality assurance involves the process of ensuring that
statistical software is developed, tested, and maintained to a high standard, and
that it produces accurate and reliable results.
❏ Steps that can be taken to ensure quality assurance in statistical software:
1. Requirements Analysis: Define clear requirements for the software, including its
intended use and any regulatory or industry standards that must be met.
2. Design and Code Review: Perform regular reviews of the software design and
code to identify potential issues or defects.
3. Testing: Develop a comprehensive testing strategy that includes both manual
and automated testing to ensure that the software produces accurate and
reliable results.
Statistical software quality assurance Cont.
4. Documentation: Create detailed documentation that describes the software's
functionality, assumptions, limitations, and any known issues
5. Version Control: Use version control software to track changes to the software
code, and ensure that changes are properly tested and approved before being
incorporated into the production code.
6. Performance Monitoring: Monitor the software's performance over time, and
use data analytics to identify potential issues or areas for improvement.
7. User Support: Provide timely and responsive support to users of the software,
and maintain a user feedback loop to identify any issues or areas for improvement.
Six sigma strategy
● Six Sigma is a quality management approach that benefits individual or
organizations to minimize/eliminate defects in products and services.
● It is a group of techniques which helps you in quality improvement.
● Six Sigma methodology is based on statistical analysis instead of guesswork to
improve processes with unknown problems.
● The principles and methodologies of Six
Sigma can be applied to software
development and quality assurance to
improve the quality and reliability of
software products.
Six sigma strategy Cont.
1. Define: Clearly define the project goals and objectives, including the scope of
the software development effort, the quality standards to be achieved, and the
key performance indicators to be measured.
2. Measure: Establish a set of metrics and measures to monitor the quality of the
software throughout the development process, such as defect rates, cycle time,
and customer satisfaction.
3. Analyze: Use statistical analysis tools and techniques to identify the root causes
of defects and quality issues, and develop strategies to address them.
4. Improve: Implement process improvements and best practices to reduce
defects, minimize variability, and optimize software quality.
Six sigma strategy Cont.
5. Control: Establish controls and monitoring systems to ensure that the
improvements are sustained over time and that the software continues to meet
quality standards.
6. Lean: Apply lean principles and practices to eliminate waste, streamline
processes, and improve efficiency in software development.

By following these Six Sigma strategies, software development teams can improve
the quality and reliability of their products, reduce defects and variability, and
ultimately deliver better value to their customers.
Six sigma strategy
Six Sigma methodologies are:
1. DMAIC (define, measure, analyze, improve, control) is used to correct a
process that already exists.
2. DMADV (define, measure, analyze, design, validate) is used to create a new
process.
COMPARISON DMAIC DMADV

DMAIC is a six sigma methodology which DMADV is another six sigma methodology that
Meaning
attempts to improve the existing process. seeks to design new or existing processes.

Type of Process Reactive Process Proactive Process

Focuses on Process focused Customer-focused

Team
Small Team Large Team
Requirement

Time Horizon Short to Medium-term Long term

Used when Continuous improvement is required Reengineering is required

Approach Corrective Preventive

Tools used Statistical and quantitative tools Qualitative tools

Implemented
Incremental change is needed Evolutionary change is needed
when
Software Reliability
❏ Software reliability refers to the probability that software will perform its
intended functions without failure or errors, under specified conditions, for a
given period of time.
❏ It is a measure of how well the software meets its functional requirements, and
how dependable it is in delivering the intended results.
❏ Here are some factors that can affect software reliability:
1. Testing: The quality and thoroughness of testing can significantly impact software
reliability. Software should be tested in a variety of scenarios and conditions to
identify and address defects and errors before deployment.
2. Design: The software design should be robust and flexible, and should anticipate
potential failure points and errors. The design should also be easy to maintain and
update to address issues as they arise.
Software Reliability
3. Code quality: The quality and readability of code can affect software reliability, as
poorly written or hard-to-maintain code can introduce errors and defects.
4. Environment: The software environment, including hardware, operating systems,
and network configurations, can impact software reliability.
5. User behavior: User behavior, including how the software is used and the quality
of the data input, can impact software reliability.
6. Maintenance: Regular maintenance, including updates and bug fixes, is essential
to maintaining software reliability over time.
To improve software reliability, it is important to implement a comprehensive quality
assurance and testing process, ensure a robust and flexible software design, use
high-quality coding practices, maintain a stable and reliable software environment,
and provide regular maintenance and updates.
The ISO 9000 quality standards
● ISO (International Standards Organization) is a group or consortium of 63
countries established to plan and fosters standardization.
● It serves as a reference for the contract between independent parties.
● It determines the guidelines for maintaining a 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.
● An organization who wishes to be certified as ISO 9000 is audited based on their
functions, products, services and their processes.
● The primary objective is to evaluate organizational compliance with expected
processes and identify areas for process improvement, if necessary.
The ISO 9000 quality standards- Advantages
● Better products and services result from continuous improvement process.
● Increased employee participation, involvement, awareness and systematic
employee training are reduced problems.
● Increase the profit of the organization
● Improves Domestic and International trade
● Reduces waste and increase the productivity of the employees
● Provide Excellent customer satisfaction
McCall’s quality factors
Decomposition Techniques
❏ Decomposition techniques refer to methods used to break down complex
problems into smaller, more manageable parts or components. Types are:-

1. Top-Down Decomposition:
● In this approach, the problem is divided into subproblems or modules at a high
level.
● Each subproblem is further decomposed into smaller components until the
desired level of granularity is achieved.
2. Bottom-Up Decomposition:
● This technique starts with individual components or smaller elements and
gradually combines them to form larger, more complex structures.
● It focuses on building up from the smallest units to create a complete system.
Decomposition Techniques Cont.
3. Functional Decomposition:
● This technique involves breaking down a problem based on its functional
requirements.
● Each function or task is isolated and analyzed separately to determine its role in
the overall solution.

4. Object-Oriented Decomposition:
● Object-oriented decomposition identifies the objects or entities involved in the
problem domain.
● Each object is analyzed individually, considering its attributes and behaviors, and
then integrated into a cohesive system.
Decomposition Techniques Cont.
5. Data Decomposition:
● Data decomposition focuses on the division of data or information.
● It involves identifying data entities and breaking them down into smaller data
sets or elements to simplify analysis and processing.

6. Task Decomposition:
● Task decomposition involves breaking down a problem into smaller, more
manageable tasks or activities.
● Each task is defined, assigned, and executed independently, contributing to the
overall solution.
COCOMO II
● COCOMO II (Constructive Cost Model II) is a software cost estimation model that
assists in predicting project effort, duration, and cost.
● It was developed by Barry Boehm
● The objective is to provide quantitative analytic structure, techniques, and tools.
● It is based upon the non-linear reuse formula.
● This cost estimation model helps in providing estimates that represent one
standard deviation near to the most likely estimate.
● It is useful in non-sequential, rapid development, reengineering and reuse
models of software development cycle.
● It has three stages.
COCOMO II Stages
Stage 1: Application Composition Model (ACM)
● Estimates effort and cost during early stages of software development.
● Considers size, complexity, and reuse/familiarity with technology.
● Uses Function Points (FP) or Source Lines of Code (SLOC) for estimation.
Stage 2: Early Design Model (EDM)
● Refines estimation during early design phase.
● Considers product attributes, platform attributes, and personnel attributes.
● Applies cost drivers to adjust estimation based on project-specific characteristics.
Stage 3: Post-Architecture Model (PAM)
● Focuses on estimation after architectural design.
● Considers additional factors like database size and modern programming practices.
● Utilizes detailed cost drivers to fine-tune estimation based on project attributes.
 COCOMO I COCOMO II

It is used in waterfall model of software It is used in non-sequential, rapid development of

development cycle models.

It helps reuse the models of software. It also helps

It helps give estimates required for the efforts and
provide estimates which represent a standard
schedule.
deviation near the most likely estimate.

It is based on the linear reuse formula. It is based on the non-linear formula of reuse.

The development begins after the requirements are

It uses spiral development method.
assigned to software.

The size of the software is measured in terms of The size of software is stated in terms of object
lines of code. points, function points and lines of code.
References
● “Fundamentals of Software Engineering”, Fourth Edition, Rajib Mall
● “Software Engineering – A Practitioner's Approach” by R. S. Pressman
● https://www.javatpoint.com/
● https://www.guru99.com/
● https://www.tutorialspoint.com/
● https://www.geeksforgeeks.org/