SEPM Module 1

Introduction to Software Engineering

Software Engineering
➢ It is the application of a systematic, disciplined and quantifiable approach
to the development, operation and maintenance of software.
➢ Applying technological, scientific and administrative approach to
designing, developing, testing and maintaining the software product in
order to meet customers' requirements with best quality of product is
referred as software engineering.
➢ Characteristics of software

➢ Software engineering Process

Waterfall Model

➢ Waterfall model is the first approach used in software development

process.
➢ It is also called as classical life cycle model or linear sequential model.
➢ In waterfall model any phase of development process begins only if
previous phase is completed.
➢ Requirement Analysis
• In this phase all business requirements of system are gathered and
analysed by communication between stakeholders and manager.
• At the end of this phase Requirement Specification Document (RSD)
is created,
➢ Design
• Based on requirement specification document design of systems is
created called software architecture.
• It is blue print of system representing system's internal structure and
behaviour.
➢ Implementation
• In implementation phase actual coding is constructed for software
architecture using hardware and software requirements of system.
• It is responsibility of developer.
➢ Verification/Testing
 • Here coding or job done by developer is verified against
requirements of user in order to ensure that software will satisfy all
business requirements of user.
• After the successful verification software is deployed at user's site
for their use.
➢ Maintenance
• While using software if user faces some problems, then those
problems must be solved time to time by development team. This
task comes under maintenance of software.
• Maintenance also includes adding new functionalities in software as
per user requirements.
➢ Advantages of waterfall model
• It is very simple to understand and easy to use.
• Phases of waterfall model do not overlap with each other.
• It is useful for small projects in which requirements are clear initially.
• Since development is linear it is easy to manage development
process.
➢ Disadvantages of waterfall model
• It is not useful for large projects.
• Not suitable for projects in which requirements are not clear initially.
• System or product is available only at the end of development
process.
• It is very difficult to modify system requirements in the middle of
development process.
➢ Practical situations in which Waterfall model can be used
• This model is used only when the requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements.
• Ample resources with required expertise are available freely.
• The project is short.
V MODEL

➢ In software development, the V-model represents a development process

that may be considered an extension of the waterfall model.
➢ Instead of moving down in a linear way, the process steps are bent
upwards after the coding phase to form the typical V shape.
➢ The V-Model demonstrates the relationships between each phase of the
development life cycle and its associated phase of testing.
➢ The horizontal and vertical axes represent time or project completeness
(left-to-right) and level of abstraction respectively.
➢ This model is basically divided into two phases:
• Verification phase
• Validation phase
1. Requirements Analysis
• In the requirements analysis phase, which is the first step in the
verification process, the requirements of the system are collected by
analysing the needs of the user(s).
• This phase is concerned with establishing what the ideal system has
to perform. However, it does not determine how the software will
be designed or built.
• Usually, the users are interviewed and a document called the user
requirements document is generated.
• The user requirements document will typically describe the system's
functional, interface, performance, data, security, etc. requirements
as expected by the user.
• It is used by business analysts to communicate their understanding
of the system to the users.
• The users carefully review this document as this document would
serve as the guideline for the system designers in the system design
phase.
• The user acceptance tests are designed in this phase.
• There are different methods for gathering requirements which
includes interviews, questionnaires, document analysis, observation,
throw-away prototypes.

2. System Design
• Systems design is the phase where system engineers analyse and
understand the business of the proposed system by studying the
user requirements document.
 • They figure out possibilities and techniques by which the user
requirements can be implemented.
• If any of the requirements are not feasible, the user is informed
regarding the issue. A resolution is found and the user requirement
document is edited accordingly.
• The software specification document which serves as a blueprint for
the development phase generated.
• This document contains the general system organization, menu
structures, data structures etc. may also hold business scenarios,
sample windows, reports for the better understanding.
• Other technical documentation like entity diagrams, data dictionary
will also be produced in this phase.

3. Architecture Design
• This phase of the design of computer architecture and software
architecture can also be referred to as high-level design.
• The baseline in selecting the architecture is that it should realize all
which typically consists of the list of modules, brief functionality of
each module, their interface relationships, dependencies, database
tables, architecture diagrams, technology details etc.
• The integration testing design is carried out in the particular phase.

4. Module Design
• The module design phase can also be referred to as low-level design.
The designed system is divided into smaller units or modules and
each of them is explained so that the programmer should be able to
start coding directly.
• The low-level design document or program specifications will
contain a detailed functional logic of the module, in pseudo-code:
• Database tables, with all elements, including their types and
sizes.
• All interface details with complete API (Application Programming
Interface) references.
• All dependency issues.
• Error message listings.
• Complete input and outputs for a module.
• The unit test design is developed in this stage.
1. Unit Testing
• Unit Test Plans (UTPs) are developed during module design phase.
• These UTPs are executed to eliminate bugs at code level or unit level.
• A unit is the smallest entity which can independently exists t, e.g.
program module
• Unit testing verifies that the smallest entity can function correctly when
isolated form rest of the codes/units.
2. Integration Testing
• Integration Test Plans are developed during the Architectural Design
Phase.
• These tests verify that units created and tested independently can
coexist and communicate among themselves.
• Test results are shared with customer's team.
3. System Testing
• System Tests Plans are developed during System Design Phase.
• Unlike Unit and Integration Test Plans, System Test Plans are composed
by client's business team.
• System Test ensures that expectations from application developed are
met. The whole application is tested for its functionality,
interdependency and communication.
• System Testing verifies that functional and non-functional requirements
have been met.
• Load and performance testing, stress testing, regression testing, etc., are
subsets of system testing.
4. User acceptance Testing
• User Acceptance Test (UAT) Plans are developed during the
Requirements Analysis phase.
• Test Plans are composed by business users. UAT is performed in a user
environment that resembles the production environment, using realistic
data. UAT verifies that delivered system meets user's requirement and
system is ready for use in real time.

➢ Advantages of V-model
1. This model is simple and easy to use.
2. The testing activities such as planning, test designing are occurred prior
to coding. This avoids wastage of time. Hence it has better chance of
success compared to waterfall model.
3. Proactive defect tracking - that means the diagnosis of defects is done at
early stage.
4. Avoids the downward flow of the defects.
5. It is considered as good for small projects in which requirements are
easily understood.

➢ Disadvantage of V-Model
1. This model is considered as very rigid and least flexible.
2. The development of software is done in the implementation phase
hence no early prototypes regarding the software are produced.
3. If there are changes in midway, then there is need to update the test
documents along with requirement documents.
Incremental Model

➢ The incremental model applies the waterfall model incrementally.

➢ The series of releases is referred to as "increments", with each increment
providing more functionality to the customers.
➢ After the first increment, a core product is delivered, which can already
be used by the customer.
➢ Based on customer feedback, a plan is developed for the next
increments, and modifications are made accordingly.
➢ This process continues with increments being delivered until the
complete product is delivered. The incremental philosophy is also used in
the agile process model.

➢ Characteristics of Incremental Model

• System is broken down into many mini development projects.
• Partial systems are built to produce the final system.
• First tackled highest priority requirements.
• The requirement of a portion is frozen once the incremented portion is
developed.

➢ Following tasks are common to all the models:

• Communication: Helps to understand the objective.
• Planning: Required as many people (software teams) work on the same
project but different functions at same time.
• Modelling: Involves business modelling, data modelling, and process
modelling.
 • Construction: This involves the reuse of software components and
automatic code.
• Deployment: Integration of all the increments.

➢ Advantages of Incremental Model

• After each iteration, regression testing should be conducted. During
this testing, faulty elements of the software can be quickly identified
because few changes are made within any single iteration.
• It is generally easier to test and debug than other methods of software
development because relatively smaller changes are made during each
iteration. This allows for more targeted and rigorous testing of each
element within the overall product.
• Customer can respond to features and review the product for any
needed or useful changes.
• Initial product delivery is faster and costs less.

➢ Disadvantages of Incremental Model

• Resulting cost may exceed the cost of the organization.
• As additional functionality is added to the product, problems may arise
related to system architecture which were not evident in earlier
prototypes.
Agile Process
➢ Agile Principles
• Customer satisfaction by early and continuous delivery of valuable soft
• Welcome changing requirements, even in late development.
• Working software is delivered frequently (weeks rather than months).
• Close, daily cooperation between business people and developers.
• Projects are built around motivated individuals, who should be trusted.
• Face-to-face conversation is the best form of communication (co-
location).
• Working software is the primary measure of progress.
• Sustainable development, able to maintain a constant pace.
• Continuous attention to technical excellence and good design.
• Simplicity is essential.
• Best architectures, requirements, and designs emerge from self-
organizing teams.
• Regularly, the team reflects on how to become more effective, and
adjusts accordingly.

➢ Advantages of Agile Process

• Stakeholder Engagement
• Transparency
• Early and Predictable Delivery
• Predictable Costs and Schedule
• Allows for Change
• Focuses on Business Value
• Focuses on Users
• Improves Quality.

➢ Example of Agile Process

• Extreme Programming (XP)
• Scrum
• Kanban
Scrum

➢ Scrum is a widely used framework for managing complex projects,

particularly in the realm of software development. At its core, Scrum
promotes a collaborative approach to work, emphasizing teamwork,
transparency, and adaptability.
➢ In Scrum, work is organized into short iterations known as “sprints,”
typically lasting one to four weeks. During each sprint, the team focuses on
delivering a small, tangible piece of the overall project, known as an
increment.

➢ Roles in Scrum
• Product owner (PO) -- Is the representative of the stakeholders and
customers who use the software. They focus on the business part and is
responsible for the ROI of the project. They Translate the vision of the
project to the team, validate the benefits in stories to be incorporated
into the Product Backlog and prioritize them on a regular basis.
• Scrum master -- The person who leads the team guiding them to comply
with the rules and processes of the methodology. Scrum master
manages the reduction of impediments of the project and works with
the Product Owner to maximize the ROI. The Scrum Master is in charge
of keeping Scrum up to date, providing coaching, mentoring and training
to the teams in case it needs it.
 • Scrum Team -- A group of professionals with the necessary technical
knowledge who develop the project jointly carrying out the stories they
commit to at the start of each sprint.

➢ How Sprint Works?

• Sprint Planning: At the beginning of each Sprint, the Scrum Team
conducts a Sprint Planning meeting. This event focuses on setting the
Sprint Goal and selecting items from the Product Backlog to work on
during the Sprint.
• Daily Scrum: The Daily Scrum, or Daily Standup, is a brief, daily event
where the Development Team synchronizes its activities. Each member
shares what they’ve worked on, what they plan to do, and any
impediments they’re facing.
• Sprint Review: After the Sprint, the Scrum Team holds a Sprint Review
to showcase the work completed during the Sprint. Stakeholders
provide feedback, and the Product Backlog is adjusted as needed.
• Sprint Retrospective: The Sprint Retrospective takes place after the
Sprint Review and is a reflective event. The Scrum Team inspects its
processes and identifies improvements for the next Sprint.

➢ Scrum Artifacts
• Product Backlog (PB): The product backlog is a list that collects
everything the product needs to satisfy the potential customers. It is
prepared by the product owner and the functions are prioritized
according to what is more and less important for the business. The goal
is for the product owner to answer the question “What should be
done”.
• Sprint Backlog (SB): It is a subset of items of the product backlog,
which are selected by the team to perform during the sprint on which
they are going to work. The team establishes the duration of each
Sprint. Usually the sprint backlog, is displayed on physical boards called
as Scrum board – that makes the development process visible to
everyone who enters the development area.
• Increment: The Increment is the sum of all the tasks, use cases, user
stories, product backlogs and any element that was developed during
the sprint and that will be made available to the end user in the form
of Software.
➢ Advantages
• Adaptability: Scrum allows teams to adapt to changing requirements and
priorities quickly. The framework is designed to be flexible, making it
easier to respond to customer feedback and market changes.
• Transparency: Scrum promotes transparency by making the entire
process and progress visible to all stakeholders. This transparency helps
build trust and collaboration among team members and stakeholders.
• Higher Productivity: Scrum's iterative approach helps teams deliver
working products incrementally. This can lead to higher productivity as
teams can focus on delivering small, manageable pieces of work.
• Improved Quality: By emphasizing regular testing and reviews, Scrum
helps identify and address issues early in the development process. This
leads to higher-quality products and reduces the risk of major defects.
• Customer Satisfaction: Scrum focuses on delivering value to customers
early and continuously. This customer-centric approach often leads to
higher levels of customer satisfaction.
• Better Team Dynamics: Scrum promotes self-organizing teams that are
responsible for their work. This can lead to better team morale,
collaboration, and a sense of ownership over the project.
• Faster Time-to-Market: Scrum's iterative approach and focus on
delivering working products quickly can lead to faster time-to-market for
products and features.
• Continuous Improvement: Scrum encourages teams to regularly reflect
on their processes and look for ways to improve. This focus on
continuous improvement can lead to more efficient and effective teams.
Kanban Model
➢ Kanban methodology is an agile method that aims at continuous
improvement, flexibility in task management and enhanced workflow.
➢ With this illustrative approach, the progress of the whole project can be
easily understood in a glance.
➢ Kanban was used in manufacturing settings to control inventory
throughout the supply chain, using a practice called just-in-time (JIT)
manufacturing.

➢ How does Kanban work?

• Visualize the Workflow: The first step in Kanban is to visualize the
workflow. This is done by creating a Kanban board, which is typically
divided into columns representing different stages of the workflow
(e.g., To Do, In Progress, Done).
• Limit Work in Progress (WIP): One of the core principles of Kanban is
to limit the amount of work that can be in progress at any given
time. This helps prevent overloading team members and ensures
that work flows smoothly through the system.
• Manage Flow: As work progresses through the workflow, team
members move tasks from one column to the next. This helps
identify bottlenecks and areas where the flow of work can be
improved.
• Make Process Policies Explicit: Kanban encourages teams to make
their process policies explicit. This includes defining things like how
work is prioritized, how tasks are assigned to team members, and
what criteria must be met for a task to move to the next stage.
• Continuous Improvement: Kanban is based on the principle of
continuous improvement. Teams regularly review their process and
look for ways to make it more efficient.
➢ Advantages of Kanban
• Flexibility: Kanban is highly flexible and can be adapted to a wide range
of processes and workflows.
• Efficiency: By visualizing the workflow and limiting work in progress,
Kanban helps teams work more efficiently and deliver value faster.
• Improved Communication: The visual nature of Kanban boards makes it
easy for team members to see what everyone is working on and
communicate effectively.
• Better Focus: Limiting work in progress helps teams focus on completing
tasks rather than starting new ones.
• Continuous Improvement: Kanban encourages a culture of continuous
improvement, where teams are always looking for ways to improve their
process.

➢ Specific Terms in Kanban:

• Kanban Board: A visual representation of the workflow, typically divided
into columns representing different stages of the process.
 • Work In Progress (WIP) Limit: The maximum number of work items that
can be in progress at any given time.
• Backlog: A list of work items that are waiting to be worked on.
• Cycle Time: The time it takes for a work item to move through the entire
workflow, from start to finish.
• Lead Time: The time it takes for a work item to be completed once work
begins on it.
• Blocked: A work item that cannot progress to the next stage due to some
impediment.

Evolutionary Process Model

➢ Evolutionary Development Model is based on the principle that "stages
consist of growing increments of an operational software product, with the
way of evolution being discovered by operational experience".
➢ According to the business need and the changing nature of the market
there are lot of improvements required in the software product over a
time.
➢ Due to this lot of improvement is required in the product hence
evolutionary developments model is iterative in nature.
Spiral Model
➢ Spiral model is a combination of iterative model and waterfall model.
➢ Spiral model has four phases of development each of these phases is
called as spiral.

➢ Identification
• This phase identifies all business requirements of system at the
beginning. It involves clear understanding of requirements by
communication between stakeholders and customer.
• In the subsequent iterations all subsystem requirements and unit
requirements are identified.
➢ Design
• In first iteration, design phase develops conceptual design of system
based on initially gathered requirements.
• In further spirals or iterations, it develops logical design, physical
design, architectural design and final design of system.
➢ Construct
• Initially construct phase develops a code for conceptual design to get
user feedback.
 • In next subsequent spirals, detailed working model of software is
constructed with increment number and are delivered to customer for
feedback.
➢ Evaluation and risk analysis
• In this phase management risks like cost overrun are identified and
monitored, technical feasibility of system is also done.
• At end of each spiral customer evaluates software for potential risks in
system and provides feedback.
• Spiral model can be used for projects where budget and risk evaluation
are important factors.
• If customers are not sure about their requirements, then spiral model
is useful than waterfall model.
➢ Advantages of spiral model
• It is more flexible to changing requirements.
• Requirements are achieved more accurately.
• User can see the system from 1 iteration to end of development.
• Risk management is easier.
➢ Disadvantages of spiral model
• It is difficult to manage development process.
• Not useful for small projects development.
• Spiral can run indefinitely.
• It requires excessive documentation work as documentation is
prepared for each iteration.
 Module 2
Requirements Analysis and Cost Estimation

Functional Requirements
➢ The Functional requirements specification create document regarding the
operations as well as activities which a system must be able to carry out.
➢ In software engineering, a functional requirement is used to define a
function regarding or its component, in which a function is described as a
specification of behaviour between and inputs.
➢ In the functional requirements there may be elements such as calculations,
technical detail, manipulation and processing and other specific
functionality which define what is supposed to implement.
➢ As defined in requirements engineering, functional requirements are used
to mention results of a system.
➢ This should be contrasted with non-functional requirements that mention
overall character like as cost and reliability.
➢ Functional requirements drive the application architecture of a system,
while non-functional requirements drive the technical architecture of a
system.
➢ Functional Requirements should include:
• Descriptions of data to be entered into the system.
• Descriptions of operations performed by each screen.
• Descriptions of work-flows performed by the system.
• Descriptions of system reports or other outputs.
• Persons who can enter the data into the system.
• Way the system meets applicable regulatory requirements.

➢ Examples of Functional Requirements

• Interface requirements
• Field 1 accepts numeric data entry.
• Field 2 only accepts dates before the current date.
• Screen 1 can print on-screen data to the printer.
• Business Requirements
• Data must be entered before a request can be approved.
 • Clicking the Approve button moves the request to the Approval
Workflow.
• All personnel using the system will be trained.
• Regulatory/Compliance Requirements
• The database will have a functional audit trail.
• The system will limit access to authorized users.
• The spreadsheet can secure data with electronic signatures.
• Security Requirements
• Members of the Data Entry group can enter requests but cannot
approve or delete requests.
• Members of the Managers group can enter or approve a request but
cannot delete requests.
• Members of the Administrators group cannot enter or approve
requests but can delete requests.
Non-Functional Requirements
These are basically the quality constraints that the system must satisfy
according to the project contract.
The priority or extent to which these factors are implemented varies from one
project to other. They are also called non-behavioural requirements. They
basically deal with issues like:
Portability, Security, Maintainability, Reliability, Scalability, Performance,
Reusability, Flexibility
The process of specifying non-functional requirements needs the knowledge of
the functionality of the system, and also the knowledge of the context within
which the system will operate.

Product requirements: Requirements which mention that the delivered

product should have behaviour in a specific way, e.g. execution speed,
reliability etc.
Organizational requirements: Requirements that are a result of organizational
policies well as procedures, such as process standards which has been used,
implementation necessities, etc.
External requirements: Requirements which are generated from the factors
that are extern to the system and its development process, e.g. interoperability
requirements, legislative requirement.
Software Requirement Specification (SRS)
➢ IEEE defines software requirements specification as, 'a document that
clearly and precisely’ describes each of the essential requirements
(functions, performance, design constraints and quality attributes) of the
software and the external interfaces.
➢ The outcome of the requirements gathering and analysis phase of the
SDLC is Software Requirements Specification (SRS).
➢ SRS is also called as requirements document.
➢ SRS is base for software engineering actions and is generated when all
requirements of software project are gathered and analysed.
➢ It is generally signed at the end of requirements engineering phase.
➢ Following are 6 requirements stated by Heninger, which SRS document
should follow:
1. SRS document should specify external system behaviour.
2. SRS document should specify implementation constraints.
3. It should be easily changeable if any changes occur.
4. It should act as reference tool for maintaining the system.
5. SRS document record forethought about the lifecycle of the system i.e.
predicts changes.
6. t must include acceptable response to undesired events.
➢ Advantages of SRS
• SRS contains the base for agreement among the client and the
company who develop the product as per expectations.
• An SRS gives a base for verification of the completely developed
product.
• Using high-quality SRS, we can develop high-quality software product.
• A high-quality SRS decreases the cost of development.

➢ Characteristics of SRS
1. Correct
• SRS is correct when all requirements of user are described in the
requirement document.
• The listed requirements must be matched with desired system.
• Remember that there is no specific tool or process to ensure the
correctness of SRS.
2. Unambiguous
• SRS does not contain any confusion when each specified
requirement has single interpretation.
• In situation, where one term has number of meanings, then its
meaning must be specified in the SRS so that it will be non-
confusing and simple to understand.
3. Complete
• SRS is complete when the requirements undoubtedly specified that
which work the software product is required to perform.
• This contains each and every requirement associated to
performance, design and functionality.
4. Ranked for importance/stability
• Each and every requirement has not same importance, so every
requirement is recognized to make differentiation between
requirements.
• For this purpose, it is needed to undoubtedly recognize every
requirement.
5. Modifiable
• The requirements given by user are changeable, so requirement
document must be generated in such a way that those
modifications can be included easily in SRS by preserving
consistently the structure and style of the SRS.
6. Traceable
• SRS is observable when the source of every requirement is
unambiguous and facilitates the description of every requirement
in future.
• Forward tracing and backward tracing methods are used for this
purpose.
• Forward tracing state that every requirement must be referencing
to design and code of components.
• Backward tracing state every requirement explicitly addressing its
source.
7. Verifiable
• SRS is testable when the stated requirements can be tested with a
cost-effective procedure to verify whether the final software fulfils
those requirements.
• Requirements are tested through reviews.
➢ Format of SRS
3 P’s
1. The People
➢ People of a project includes from manager to developer, from
customer to end user.
➢ But mainly people of a project highlight the developers.
➢ It is so significant to have highly skilled as well as motivated developers
that a PM-CMM (People Management Capability Maturity Model) is
developed by the Software Engineering Institute to enhance the
readiness of software enterprises to handle more and more robust
applications by assisting to attract, grow, motivate, deploy, and retain
the talent necessary for the improvement Project Scheduling and
Tracking of their software development capability.
➢ Enterprises which attain high levels of maturity in the area of people
management have a great probability of carrying efficient software
engineering practices.
2. The Product
➢ Product is nothing but any software which has to be designed and
developed. For successful development of product there is need to set
product objectives and scope, there must be consideration of
substitute solutions, and also identification of technical and
management constraints must be done.
➢ If there is lack of this information, it is not possible to define
reasonable as well as correct estimates of the cost, an efficient
estimation of risk, a practical breakdown of project tasks or a
controllable project schedule which provides a meaningful indication
of progress.
3. The Process
➢ A-software process is used to provide the framework from which it is
possible to establish a complete plan for software development.
➢ There are different elements such as different tasks, milestones, work
products, as well as quality assurance points which help to enable the
framework regarding activities to be made compatible with the
functionalities of the respective software project and the related
necessities of the project team.
➢ At last, umbrella activities handle the process model. Umbrella
activities are not dependent on any one framework activity and are
carried out throughout the whole process.
Line of Code (LOC)
➢ LOC is the simplest among all metrics available to estimate project size.
This metric is very popular because it is the simplest to use.
➢ Using this metric, the project size is estimated by counting the number of
source instructions in the developed program.
➢ While counting the number of source instructions, lines used for
commenting the code and the header lines should be ignored.
➢ Determining the LOC count at the end of a project is a very simple job.
However, accurate estimation of the LOC count at the beginning of a
project is very difficult.
➢ In order to estimate the LOC count at the beginning of a project, project
managers usually divide the problem into modules, and each module into
sub-modules and so on, until the sizes of the different leaf-level modules
can be approximately predicted.
➢ To be able to do this, past experience in developing similar products is
helpful. By using the estimation of the lowest level modules, project
managers arrive at the total size estimation.

Functional Points (FP)

➢ As a normalization value, a measure of the functionality which is given by
the application is taken by the Function-oriented software metrics.
➢ It is not possible to measure the functionality directly. Hence using other
direct measures, it is necessary to derive it indirectly.
➢ The concept of Function-oriented metrics was proposed initially by
Albrecht. A measure called the function point is suggested by him.
➢ Function points are basically derived with the help of an empirical
relationship depending upon countable (direct) measures regarding the
information domain of software and software complexity assessments.
➢ Five information domain characteristics are determined and counts are
provided. These are as follows:
• Number of user inputs: Each user input should be considered.
• Number of user outputs: Reports, screens, error messages, etc.
• Number of user inquiries: An on-line i/p which results on on-line o/p.
• Number of files: Each logical master file is counted.
• Number of external interfaces: Data files on storage media.
➢ Once these data have been collected, a complexity value is associated with
each count. Organizations that use function point methods develop criteria
for determining whether particular entry is simple, average, or complex.
Nonetheless, the determination of complexity is somewhat subjective.

➢ The constant values which are present in the equation and the weighting
factors which are applied to the information domain counts are decided
based on the facts.
➢ As soon as the calculation of function points is completed, they are used so
as to normalize measures for the different factors such as software
productivity, quality, and other attributes like Errors per FP, Defects per FP, $
per FP, Pages of documentation per FP, FP per person-month.
COCOMO II Model
➢ The COCOMO (Constructive Cost) model is an empirical model that was
derived with the help of gathering data from a large number of software
projects.
➢ These data were analysed to determine formulae that are the best fit to
the observations.
➢ These formulae link the size of the system and product, project and team
factors to the effort to develop the system.
➢ We can select to use the COCOMO model for number of reasons:
• It is well documented, accessible in the public domain and supported
by public domain and commercial tools.
• It has been widely used and evaluated in several organizations.
➢ COCOMO 81, first version of the COCOMO model was a three-level model.
➢ The first level presents an original rough estimate. The second level
modifies this using a several project and process multipliers; and the most
detailed level creates estimates for different stages of the project.
➢ The multiplier M reflects team, process and project characteristics.
COCOMO II Sub Model

➢ Reuse Model
• Reuse model is used to calculate the effort needed to integrate reusable
software or program code that are automatically created by design or
program translation tools.
• For COCOMO II, reused code is of 2 types. First is the black-box code
which can be reused without having knowledge of code or making
changes in it. The effort regarding development for black-box code is
taken to be zero.
• Code that has to be adapted to combine with new code is called white-
box code. Some development effort is needed to reuse this because it
has to be known and changed before it can work accurately in the
system.
• The formula for effort estimation is:
• PMAuto = (ASLOC x AT/100)/ATPROD
• Where, AT-Percentage of adapted code that is automatically created
• ATPROD - Productivity of engineers in integrating such code.
 • For example,
• If there is a total of 10,000 lines of white-box reused code in a system
and 40% of this is automatically generated, and ATPROD is 2400 then
the effort required to integrate this generated code is:
• (10,000 x 40/100)/2400 = 1.67 person months
➢ Early design model
• This model is used at the time of early stages of the system design after
the requirements have been established.
• Estimates are depending on function points, which are then changed to
number of lines of source code.
• Estimates can be completed after the user requirements have been
agreed.
• Depend on standard formula for algorithmic models.
Effort = A x SizeB x M
• The multiplier M in COCOMO II is depends on a simplified collection of
seven projects and process characteristics that influence the estimate.
These can increase or decrease the effort needed. These characteristics
used in the early design model are product reliability and complexity
(RCPX), reuse required (RUSE), platform difficulty (PDIF), personnel
capability (PERS), personnel experience (PREX), schedule (SCED) and
support facilities (FCIL).
• This results in an effort computation as follows:
PM = 2.94 x SizeB x M
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED
 Module 3
Design Engineering

Qualities Of Design
➢ Innovative - Innovative design can be either completely new design or
redesign of existing product.
New design gives unseen value to market where as redesign improves the
quality of an existing product.
➢ Functional - Good design fulfils all its intended functions to solve user's
problem. It focuses on usefulness of a product by optimizing its
functionality.
➢ Honest - A good design is honest. An honest design expresses the
functions and values it offers. It never attempts to modify Organiser's and
User's view with promises it can't keep.
➢ User-oriented - Good design is developed based on its use and intended to
improve solution to problem for the user.
User-oriented design gives intellectual as well as material value to system
which in turn achieving user's satisfaction.
➢ Correctness - Correctness is an important quality of good design. A good
design should correctly achieve all required functionalities as per SRS
document.
Design Concepts

➢ Abstraction
• IEEE defines abstraction as 'a view of a problem that extracts the
essential information relevant to a particular purpose and ignores the
remainder of the information.'
• There are two ways to use the concept of abstraction; as a process and
as an entity.
• As a process, abstraction refers to a mechanism of hiding irrelevant
extra details and representing just the important essential features of
an element so that one can concentrate on essential things at a time.
• As an entity, abstraction refers to a model or view of an item.
• There are different types of abstraction
• Functional Abstraction
• Data Abstraction
• Control Abstraction
➢ Information Hiding
• It is important to specify and design modules in such a manner that the
data structures as well processing details of one module should not be
accessible to any other modules.
• Only required information is transferred between the modules. The
way of hiding unnecessary details is referred to as information hiding.
• Advantages of information hiding:
• High Quality Software
• Low Coupling
• Controls the impact of change in one module to others.

➢ Structure
• Software architecture refers to the structure of the system, which
consists of several components regarding a program/ system, the
attributes (properties) of those components and the relationship
among them.
• The software architecture helps the software engineers in the process
of analysing the software design proficiently.

➢ Modularity
• Modularity can be achieved by the process of dividing the software
into components which are uniquely named and addressable. These
components are also known as modules.
• A complex system (huge application) is partitioned into a set of discrete
modules in such a manner that one should be able to develop those
modules independent of each other.
• After development is completed, the modules are integrated to form
an entire project.
• Example - The television set is made up of a number of modules -
speakers, projection tube, channel buttons, volume buttons, etc.
• Each module has its own defined functionality but when they are put
together, the complete functionalities of a television are realized.

➢ Concurrency
• It is important to utilize the resources efficiently as much as possible.
For this purpose, multiple tasks must be executed concurrently.
 • This aspect makes concurrency one of the important concepts of
software design.
• Every system should be designed in such a manner that it should
facilitate multiple processes to execute concurrently.
• For example, if the currently executing process is waiting for some
resource, the system must able to execute any other process in the
meantime.

➢ Verification
• Verification is described as a mechanism of confirmation by examining
giving evidence that there is no mismatch in design output and the
design input specifications.

➢ Aesthetics
• Aesthetics is the philosophical study of beauty and taste.
• Software engineering is a largely creative design discipline, where new
designs (both graphical design models as well as code) are created
from scratch.

Cohesion
➢ Cohesion defines the degree to which components of system are related to
each other i.e. it measures the strength of relationship between two
components of system.
➢ Good system design must have high cohesion between the components of
system.
➢ Types of cohesion
• Co-incidental cohesion - An unplanned cohesion which results into
decomposition of a program into smaller components for the
modularization of system is called co-incidental cohesion. Typically,
these types of cohesions are never accepted.
• Logical cohesion - When logically classified elements are combined into
a single module then it is called as logical cohesion. Here all elements
of modules contribute to same system operation.
• Temporal cohesion - Temporal cohesion occurs when component of a
system performs more than one function and these functions must
 occur within same time span. It is generally found in initiation and
termination activities.
• Procedural cohesion - When components of system are related to each
other only by sequence then there exists procedural cohesion. Loop in
programming language is good example of procedural cohesion.
• Communication cohesion - When elements of module perform
different functions but each function accepts same input and generates
same output then that module is said to be communicational cohesive.
It is sometimes acceptable if no other alternative is easily found.
• Sequential cohesion - A module is said to be sequentially cohesive if its
functions are related in a way such that output of one function acts as
an input data to other function. This type of cohesion is easily
maintainable.
• Functional cohesion - If elements of module are grouped together
since they contribute to a single function then such a module is
functionally cohesive module. All elements of such a module are
necessary for successful execution of function.

➢ Advantages of Cohesion
• High cohesion among system components results in better program
design.
• High cohesion components can be easily reused.
• High cohesion components are more reliable.

➢ Disadvantages of Cohesion
• Low cohesion components are difficult to maintain
• Low cohesion components cannot be reused.
• Low cohesion components are difficult to understand.
• Low cohesion components are less reliable.

Coupling
➢ Coupling is an indication of strength of interconnection between various
components of a system.
➢ Highly coupled components are more dependent on each other whereas
low-coupled components are less dependent or almost independent on
each other.
➢ Good design always has low coupling between components of system.
➢ Coupling types
• Data coupling - Data coupling occurs between two components of
system when they pass data to each other by parameters using
argument list and each element in argument list is used. A component
becomes difficult to maintain if too many parameters are passed.
• Control coupling - When data are passed between two components
and that affects internal logic of a component then there exists control
coupling between those two components. It passes the control flags
between system components.
• Common coupling - Common coupling is also called as global coupling
since in these coupling components of system communicates with each
other by using global area. Common coupling becomes difficult to track
when data in global area is changed.
• Content coupling - When one component refers to the internals of the
other component then those two components are said to be content
coupled. As content coupling is worst type of coupling it should not be
used in designing.
• External coupling - If two components of system share an externally
imposed data format, communication protocol or device interface then
they are said to be externally coupled. External coupling refers to
communication between system components and external tools or
devices.
• Message coupling - Message coupling occurs between two
components of system when those components communicate with
each other via message passing. In this coupling components are
independent of each other thus it is low type coupling.
• Stamp coupling - Stamp coupling occurs between two components of
system when data between them are passed by arguments using a
data structure containing elements which may or may not be used.
Stamp coupling is also low type coupling.

➢ Advantages of Coupling
• Low coupling components do not force ripple effect to other
components.
• Low coupled components can be reused.
• With low coupling among components, system can build faster.
➢ Disadvantages of Coupling
• High coupling components are difficult to understand.
• High coupling components forces change in other components if one
component changes.
• High coupling slows down the development process.
User Interface Design
➢ User interface is considered as a front-end application view which is
interacted by the user so as to use the software.
➢ User is able to manipulate as well as control the software and hardware
with the help of user interface.
➢ Now-a-day, user interface appears in each and every place where there is
existence of digital technology, right from desktops, smart phones, cars,
music players, airplanes, ships etc.
➢ User interface is an integral component of software and is designed in such
a manner that it should be able to provide the user insight of the software.
➢ Ul offers a fundamental platform for the communication of user and
computer.
➢ The form of UI can be graphical, text-based, audio-video based. It is usually
depending upon the underlying platform (hardware and software
combination).
➢ The popularity of software depends upon following aspects:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interfacing screens
➢ UI is broadly divided into two categories:
• Command Line Interface
• Graphical User Interface

Golden Rule
(1) Strive for Consistency
• Users should not have to wonder whether different words, situations,
or actions mean the same thing. Do not confuse your user keep words
and actions consistent.
• Use "The Principle of Least Surprise".
• Example: Car Climate Control
(2) Visibility of system status or Offer informative feedback
• The system should always keep users informed about what is going on.
Through appropriate feedback in a reasonable time. Don't keep the
users guessing tell the user what's happening.
• Example: OS Installation status

(3) Match between system and the real world or Design dialog to yield closure
• Again, the less the users have to guess the better. The system should
speak the users' language (use words, phrases and concepts familiar to
the user), rather than special system terms.
• Example: Payment proceeding (by Ramakrishna)

(4) User control and freedom or Permit easy reversal of actions

• Schneiderman puts it nicely "This feature relieves anxiety, since the
user knows that errors can be
• undone; it thus encourages exploration of unfamiliar options."
• Example: Document History

(5) Error Prevention and Simple Error Handling]

• Users hate errors, and even more so hate the feeling that they
themselves have done something wrong.
• Either eliminate error-prone conditions or check for them and notify
users about that before they commit to the action.
• Example: Password Enter

(6) Reduce short-term memory load or Recognition rather than recall

• As Nielsen says, recognizing something is easier than remembering it.
Minimize the user's memory load by making objects, actions, and
options available.
• The user should not have to remember information from one part of
the dialogue to another.
• Instructions should be visible.
• Example: Ring/Silent switch

(7) Enable frequent users to use shortcuts

• Allow users to tailor (manipulate and personalize) frequent actions.
 • Abbreviations, function keys, hidden commands, and macro facilities
are very helpful to an expert user.
• Example: Click Commands and Shortcuts

(8) Aesthetic and Minimalist design

• Minimalist doesn't mean limited. All information should be valuable
and relevant.
• Example: Simple Interface.

(9) Help users recognize, diagnose, and recover from errors

• Error messages should be expressed in plain language (don't use
system language to describe what the system is doing), precisely
indicate the problem, and constructively suggest a solution.
• Example: Plain Message

(10) Help and documentation

• Even though it is better if the interface can be used without
documentation, it may be necessary to provide help and
documentation.
• Any help information should be easy to search, focused on the user's
task, list of concrete steps, and not too large.

Architectural Design
➢ Architectural design in software engineering is the process of defining a
structured solution that meets all the technical and operational
requirements while optimizing common quality attributes like
performance, security, and manageability. It involves high-level structuring
of software systems, identifying the main components, their relationships,
and how they interact with each other and with external systems.
➢ Functions of Architectural Design
1. It describe an abstraction level at which the designers can state the
functional and performance behaviour of the system.
2. It estimates all top-level designs.
3. It acts as a guideline for improving the system by illustrating those
features of the system that can be changed easily while maintaining the
system integrity.
 4. It develops and documents top-level design for the external and internal
interfaces.
5. It develops initial versions of user documentation.

➢ Different Architectural Styles

1. Data-Flow Architecture:
• Definition: Characterized by the movement of data through a series
of processing steps, which can be represented as a directed graph
of data flowing between operations.
• Function: Suitable for systems where the main task is transforming
streams of input data into output data, such as in signal processing
or data analytics.
• Example: Pipe-and-filter architecture, where data passes through a
sequence of filters (processing elements) connected by pipes (data
streams).
2. Layered (N-Tier) Architecture:
• Definition: Divides the system into layers, each with a specific
responsibility, such as presentation, business logic, and data access.
• Function: Enhances modularity and separation of concerns, making
the system easier to manage and maintain.
• Example: A typical web application with presentation layer (UI),
application layer (business logic), and data layer (database).
3. Object-Oriented Architecture:
• Definition: Based on the concept of "objects," which are instances
of classes, encapsulating both data and behaviour.
• Function: Promotes reuse and flexibility through inheritance and
polymorphism, making it easier to manage and scale complex
systems.
• Example: A system designed using object-oriented principles with
classes representing entities and their interactions.
4. Data-Cantered Architecture:
• Definition: Focuses on a central data repository that is accessed
and manipulated by various components of the system.
• Function: Ensures data integrity and consistency by centralizing
data management, and is often used in systems where data sharing
and persistence are critical.
 • Example: Client-server databases, where a central database server
provides data to multiple client applications.
5. Call-and-Return Architecture:
• Definition: Structures the system based on a hierarchical
decomposition of components, where higher-level components call
lower-level ones.
• Function: Simplifies control flow and error handling, making it
suitable for systems with clear, hierarchical functional
decompositions.
• Example: Traditional procedural programming, where functions or
procedures call other functions to perform tasks.

Component Level Design

➢ The main function of component level design is to define data structures,
algorithms, interface characteristics as well as communication mechanisms
for all the present software components which are identified in the phase
of architectural design.
➢ The phase of component level design is expected when the data,
architectural, and interface designs are completed.
➢ The software is represented by the component-level design in such a
manner which lets the designer to review it for correctness as well as
consistency prior to its built.
➢ A component is a modular, deployable, replaceable part of a system which
encapsulates implementation and exposes a set of interfaces.
➢ Principles for Designing Class-based Components
• Open-Closed Principle (OCP): Extensions should be allowed in the class
but not modification.
• Liskov Substitution Principle (LSP): It should be possible to substitute
subclasses for their base classes.
• Dependency Inversion Principle (DIP): Depend on abstractions, do not
depend on concretions.
• Interface Segregation Principle (ISP): Multiple client oriented interfaces
are considered as better compared to one general purpose interface.
• Release Reuse Equivalency Principle (REP): The granule of reuse is the
granule of release.
 • Common Closure Principle (CCP): Classes that change together belong
together.
• Common Reuse Principle (CRP): Classes that can't be used together
should not be grouped together.

➢ Component-Level Design Guidelines

1. Components
• Establish naming conventions in the phase of architectural
modelling.
• Names of Architectural components should be meaningful for
the stakeholders.
• Names of Infrastructure components must have implementation
specific meanings.
• The nature of components can be identified with the help of
UML stereotypes.
2. Interfaces
• Use of lollipop representation is considered as better as
compared to formal UML box and arrow notation.
• For the purpose of consistency, the flow of interfaces should be
from the left-hand side of the
• component box.
• Display only those interfaces which are relevant to the
component under construction.
3. Dependencies
• To improve readability, it should be better to have the model
dependencies from left to right and inheritance from bottom
(child classes) to top (parent classes).
• Interfaces must be used to represent component
interdependencies rather than component to component
dependencies.
 Module 4
Software Risk, Configuration Management

Risk Management
➢ Risk management in software engineering is the process of identifying,
assessing, and mitigating risks that could potentially affect the success of a
software project. It involves a systematic approach to managing
uncertainties and ensuring that any threats to the project's objectives are
addressed proactively.
➢ Types of Risk:
• Schedule Risk
• Budget Risk
• Technical Risk
• Operational Risk
• Other unavailable Risk
Risk Identification
➢ It is a process of stating which risk may occur during development of the
project.
➢ In order to identify the risks that project may be subjected to, it is
important to first study the problems faced by previous projects.
➢ Study the project plan properly and check for all the possible areas that
are vulnerable to some or the other type of risks.
➢ The best way of analysing a project plan is by converting it to a flowchart
and examines all essential areas.
➢ It is important to conduct few brainstorming sessions to identify the
known and unknowns that can affect the project.
➢ Any decision taken related to technical, operational, political, legal, social,
internal or external factors should be evaluated properly.
➢ All the details of the risk such as unique Id, date on which it was identified,
description and so on should be clearly mentioned.
➢ There are in general two types of risks:
• Generic risks are considered as a potential threat to each and every
software project.
 • Product-specific risks can be identified only by those who are having a
clear understanding regarding the technology, the people, and the
particular environment in which software is to be built.
Risk Assessment
➢ Risk assessment is the systematic process of identifying and evaluating
potential risks that could negatively impact a project. It involves analysing
the risks to understand their nature, sources, and potential consequences.
The goal of risk assessment is to prioritize risks based on their severity and
likelihood so that appropriate mitigation strategies can be developed.
➢ Risk Analysis: Evaluating the identified risks to understand their potential
impact and likelihood. This involves both qualitative and quantitative
analysis:
➢ Qualitative Analysis: Assessing risks based on their severity and likelihood
using subjective measures, such as high, medium, or low.
➢ Quantitative Analysis: Using numerical measures and statistical techniques
to estimate the probability and impact of risks.
➢ Risk Prioritization: Ranking risks based on their assessed impact and
likelihood. This helps in focusing on the most critical risks that need
immediate attention and resources.
Risk Projection
➢ Risk projection, also known as risk estimation or risk forecasting, is the
process of predicting the future occurrence and impact of identified risks.
It involves estimating the probability of risk events happening and their
potential effects on the project. The goal of risk projection is to understand
how risks might evolve over time and prepare for them accordingly.
➢ Key Aspects of Risk Projection:
• Probability Estimation: Estimating the likelihood that a risk event will
occur. This can be based on historical data, expert judgment, or
statistical models.
• Impact Estimation: Assessing the potential consequences of the risk
event if it occurs. This includes evaluating the severity of the impact on
project objectives such as cost, schedule, quality, and scope.
• Risk Exposure Calculation: Combining the probability and impact
estimates to calculate the overall risk exposure. This can be done using
a risk matrix or other quantitative methods.
RMM Plan
➢ RMMM, which stands for Risk Mitigation, Monitoring, and Management, is
a systematic approach used in project management to handle risks
throughout a project’s lifecycle. It involves identifying potential risks,
developing strategies to reduce or eliminate these risks, continuously
monitoring them, and managing responses when risks become issues.
➢ Risk Mitigation
• This involves taking proactive steps to reduce the probability or impact
of potential risks.
• Strategies can include:
• Changing plans to eliminate the risk.
• Taking actions to minimize the likelihood or impact of the risk.
• Shifting the risk to a third party (e.g., through insurance or
outsourcing).
• Acknowledging the risk and preparing a contingency plan.
➢ Risk Monitoring
• This involves keeping track of identified risks and any new risks that
may arise. It includes regular reviews and updates to the risk
management plan, ensuring that mitigation strategies are effective and
adjusting them as needed.
➢ Risk Management
• This is the overarching process that includes risk identification,
assessment, prioritization, and response planning. It ensures that risks
are systematically managed throughout the project.

➢ Example: Developing a new mobile application for online banking.

• Risk Identified: Security vulnerabilities in the app.
• Risk Mitigation
• Implement secure coding practices, conduct regular security audits,
and use encryption for sensitive data.
• Risk Monitoring
• The project team sets up weekly meetings to review the status of
identified risks.
• They use a risk register to document and track the progress of
mitigation efforts.
 • Automated tools are employed to continuously scan the
application for vulnerabilities.
• Risk Management
• Identification: During the planning phase, the team identifies
potential risks, such as delays in development, security breaches,
and compliance issues.
• Assessment: Each risk is assessed for its likelihood and potential
impact. High-likelihood, high-impact risks are prioritized.
• Response Planning: For security vulnerabilities, the response plan
includes immediate patches and notifying affected users if a breach
occurs.

Software Configuration Management (SCM)

➢ Software Configuration Management (SCM) is a critical aspect of software
development that focuses on identifying, organizing, and controlling
changes in software. It ensures that the software maintains its integrity
and quality throughout the development lifecycle. Here’s an illustration of
the SCM process with key stages:
➢ Key Stages of the SCM Process:
1. Configuration Identification:
• Identifying the components and artifacts of the software project
that need to be managed.
• Defining baselines, which are fixed references for the software at a
particular point in time.
• Example: Identifying source code files, documentation,
requirements, design documents, test scripts, and binaries.
2. Configuration Control:
• Managing changes to the software artifacts in a controlled and
systematic manner.
• Involves change request procedures, impact analysis, and approval
or rejection of changes.
• Example: A developer submits a change request to add a new
feature. The change control board reviews the request, assesses
the impact, and approves it for implementation.
 3. Configuration Status Accounting:
• Recording and reporting the status of configuration items and
change requests.
• Maintaining records of changes, versions, and configurations.
• Example: Generating reports that show the current status of all
configuration items, including the version history and approved
changes.
4. Configuration Auditing:
• Conducting audits to ensure that the configuration items conform
to their specifications and that changes have been properly
implemented.
• Verifying that the SCM process is being followed correctly.
• Example: Performing a configuration audit before a software
release to ensure all changes are documented and all configuration
items are in the correct state.
5. Build Management:
• Automating the process of compiling and linking source code to
create executable software.
• Ensuring that builds are repeatable and traceable.
• Example: Using a continuous integration system to automatically
build the software whenever changes are committed to the version
control system.
6. Release Management:
• Managing the distribution of software releases to users.
• Coordinating release schedules and ensuring that all components
of the release are ready.
• Example: Preparing a release package that includes the compiled
software, release notes, and installation instructions, and deploying
it to the production environment.
➢ SCM Tools:
• Version Control Systems: Git, Subversion (SVN), Mercurial
• Build Automation Tools: Jenkins, Travis CI, Bamboo
• Configuration Management Tools: Puppet, Chef, Ansible
• Issue and Change Tracking Systems: JIRA, Redmine, Bugzilla
 ➢ Advantages of SCM
• Enhanced Collaboration:
• Improved Quality Assurance:
• Efficient Release Management:
• Traceability and Auditability:
• Disaster Recovery:
• Support for Parallel Development:
• Documentation and Communication:

Format Technical Review (FTR)

➢ A formal technical review is a process performed to give assurance of
software quality.
➢ This testing activity is done by software engineers and other persons.
➢ The objectives of the Formal Technical Review are:
• To find out errors in function, logic, or coding in the software.
• To check that the software fulfils the requirements for which it is built.
• To give assurance that software has been designed as per customer
requirements.
• To create software developed in uniform order.
• To create more manageable project.

➢ Steps in FTR
• Involvement of people: Between 3 to 5 people should be involve in the
review.
• Advance preparation: Advance preparation should occur but it should
be very short. At the most 2 hours of work for each person can be
spent in this preparation
• Short duration: The duration of the review meeting should be less than
two hours.
• Rather than attempting to review the entire design, walkthrough is
conducted for modules or for small group of modules.
• The focus of the FTR is on work product (a software component to be
reviewed). The review meeting is attended by the review leader, all
reviewers and the producer.
 • The review leader is responsible for evaluating the product for its
deadlines. The copies of product material are then distributed to
reviewers.
• The producer organizes "walkthrough" for the product, explaining the
material, while the reviewers raise the issues based on their advance
preparation.
• During the FTR, a reviewer (the recorder) actively records all issues that
have been raised.
• These are summarized at the end of the review meeting, and a review
issues list is produced. In addition, a formal technical review summary
report is completed.
• A review summary report answers three questions:
1. What was reviewed?
2. Who reviewed it?
3. What were the findings and conclusions?

Walkthrough
➢ Walkthrough is a Review meeting but it is different from Inspection as it is
not a formal process.
➢ Generally, it is started by the author of code.
➢ In walkthrough, document or code is read by author and others can write
note on the defects and suggestions about it.
➢ Walkthrough is informal way of testing so there is no need of moderator
while performing walkthrough.
➢ We can call it as Open-Ended discussion because preparation before
meeting and creation of a list of observation is not necessary.
➢ It is the informal way of review so it does not focus on documentation.
Defect tracking is challenging task in walkthroughs.
➢ The following are the objectives of Walkthrough:
• Understand and learn the development of software product till date.
• Detecting defects in the developed software product.
• To explain information present in the document.
• To verify and discuss about the validity of the proposed system.
• Reporting the suggestions given by the others (other employees).
 Module 5
Software Testing and Maintenance

Alpha Testing
➢ Alpha Testing is software testing which is done to find out bugs before
deploying the software application to end user.
➢ Alpha testing is a type of acceptance testing.
 ➢ This testing is called as an alpha testing since it is performed when
development phase of software application is near to Beta Testing.
➢ The objective of alpha testing is to refine the software product by finding
(and fixing) the bugs that were not discovered through previous tests.
➢ Alpha testing is typically performed by in-house software engineers or QA
staff.
➢ It is the final testing stage before the software is released into the real
world.
➢ Alpha testing is performed in two phases:
• In first phase software is tested by development team members. They
perform debugging of software to catch bugs quickly.
• In second phase software is tested by software quality analyst team for
additional testing in actual user's environment setup.
➢ Advantages of alpha testing
• Better insight about the software's reliability at its early stages.
• Free up team for other projects.
• Reduce delivery time to market.
• Early feedback helps to improve software quality.

Beta testing
➢ Beta testing is testing which is performed at the location of customer. In
this testing actual as well as intended users will test the software to
determine whether the software is satisfying their needs and expectations.
➢ Beta testing allows users to test software before it is released to public.
➢ Beta testing minimizes the product failure risks and delivers qualitative
product through customer validation. It gives direct feedback from the
user.
➢ It ensures reliability, security, robustness etc. from user's perspective.
➢ Types of Beta testing are: Traditional, public, technical, focused and past
release.
➢ Beta testing is also called as User Acceptance Testing, Customer
acceptance Testing, Customer Validation testing and Pre-Release testing.
➢ Beta testing gives assurance that we deliver quality software to our
customers by testing the product under various situations in real world
environment that can't be created in a lab setting.
➢ Advantages Beta Testing
• Beta testing decreases product failure risk by performing customer
validations.
• Beta Testing permits tester to test the software application in post-
launch infrastructure.
• Beta testing improves the quality of software product by using
feedback of customer.
• Beta testing is cost effective as compared to other data collection
techniques.
• Beta testing helps to increases customer satisfaction.
➢ Types of beta testing
1. Traditional Beta testing: Software Product is provided to targeted end
user and associated data is collected in all aspects. This data is useful
for the improvement of Product.
2. Public Beta Testing: In this type of beta testing, product is released
publicly in real world using online channels and data can be collected
from anyone. Using feedback from end users, improvements in product
are done.
3. Technical Beta Testing: In this type of beta testing, software Product is
released in internal group of an organization and collect data from the
employees of the organization.
4. Focused Beta: In this type of beta testing, software Product is released
in the market for collecting feedback about specific features of the
program.
5. Post release Beta: In this type of beta testing, software Product is
released in the market and data is collected to improve the software
product for the next release.
White Box Testing

➢ White Box Testing is testing process in which we verify internal coding and
infrastructure of software product under the test.
➢ White box testing is based on analysing the internal implementation of
system under test. Thus, programming knowledge or detailed functional
knowledge of system is major pre-requisite for tester.
➢ White box testing mainly concentrates on the testing flow of inputs and
outputs through the software, strengthening security and improving
design and usability of software product.
➢ White box testing is also called as Clear Box testing, Open Box testing,
Structural testing, Transparent Box testing, Code-Based testing, and Glass
Box testing.
➢ The term "white box" is used to indicate testing of code of software
because we can see what is present inside the box.
➢ The clear box or white box term indicate the capability to see via outer
part of software into its internal workings.
➢ It uses following methods:
➢ Statement coverage i.e. testing all programming statements using
minimum number of tests.
➢ Branch coverage: This is to ensure that all branch conditions in system are
tested at least once.
➢ Path coverage: It includes ensuring that each statement and branch in
system is tested at least once.
➢ Other than above there are different coverage types such as Condition
Coverage, Multiple Condition Coverage, Path Coverage, Function Coverage
etc.
➢ Every technique has its own advantages and tries to cover all parts of
software's product code.
➢ By using Statement and Branch coverage, we can perform 80-90% code
coverage which is enough.
➢ White box testing involves two steps
• Step 1: Understand the source code
• In this step, testers understand the source code of the software
product.
 • White box testing includes testing of internal working of software
product. So, the tester must has very high level knowledge of
programming languages used in the software product under
• Security is basic purpose of performing the software testing. So,
the tester should be able detect security problems and protect the
software from attacks by hackers and naive users who may add
malicious code in software product knowingly or unknowingly.
• Step 2: Create test cases and execute
• The second step involved in white box testing includes testing the
source code of software product under the test for checking of
proper flow of control and structure,
• The tester will generate small test cases for every process or group
of processes in the software product.
• This method requires that the tester should have high level
knowledge about source code.

➢ Advantages of White Box Testing

• As it tests all possible paths of system it is a through testing.
• White Box Testing can be applied at earlier testing stage as there is
no need to wait for GUI.
• As tester has knowledge of internal coding, it becomes easy for
tester to find out which type of input helps is testing.
• White box testing performs Code optimization through finding
hidden bugs.
• Automation of White box tests cases can be done easily.
• White box testing is strict because each and every statement of code
tested at least one time.
• We can start white box testing early as soon as first module of
software is created.

➢ Disadvantages of White Box Testing

• White Box Testing is complex and expensive process.
• For testing larger applications using White Box Testing, it becomes
impossible to perform exhaustive testing.
• White Box Testing tests the software as it exists, hence missing
functionality of system may not be discovered.
 • It is necessary to select all possible inputs to test each path which is
time consuming process.
• If white box testing performed by developers who develop code
present in software, then there is less possibility to find out
development related errors.
• While performing White box testing, we need expert persons who
have deep knowledge of programming language in which
Application Under Test (AUT) builds.

Black Box Testing

➢ The software testing methods which test the functionality of an application
without knowing its internal structure, coding information and knowledge
of internal paths of the software is called black box testing.
➢ In this method test cases are built based on what application is supposed
to do.
➢ It is also known as behavioural testing or specification-based testing.
➢ In Black Box Testing we concentrate on inputs provided to software
product and output from the software product without applying
compulsion about knowledge of the programming language used in
software under the test.
➢ Black box testing can be applied during each level of software testing
process.
➢ It makes use of various testing techniques like Boundary Value Analysis
(BVA), equivalence class decision models etc.
 ➢ Following are the steps which are used to perform black box testing:
1. First the requirements and specifications of the system are analysed.
2. Tester selects valid test data i.e. data for positive test scenario to verify
whether application under test is able to processes that data and give
output as expected.
3. Also, tester selects invalid test data for negative test scenario to verify
whether application under test is able to processes that data and give
output as expected.
4. Tester state expected outputs for each test data.
5. [Link] tester generates test cases with the selected test data. Then
test cases are run.
6. Software tester performs comparison between the actual output and
expected output.
7. Defect is detected if actual result is not same as expected result.
8. Then detected defect is reported to developer.
9. Developer can then fix that defect and then application is retested by
tester.

➢ Types of Black Box Testing

1. Functional testing
• Functional testing is a type of software testing which checks that
every function present in our software application works as per
requirements of user or not.
• Functional testing includes black box testing and it does not focus on
the source code of the software application.
• All functionalities of the system are verified by tester with the help
of suitable test data and compare actual result with expected result.
• If there is difference between actual result and expected result then
bug is detected.
• Functional testing is done using Requirement Specification
Document.
2. Non-functional testing
• In this type of black box testing, we do not perform testing to test
specific functionality. Non-functional testing is used to check non-
 functional requirements such as performance, scalability, usability,
and security are fulfilled or not.
3. Regression testing
• Regression Testing is used to check whether changes which have
been made in code because of some errors or change in
requirement does not affect existing working functionality.
• In Regression Testing, we execute already executed test cases to give
assurance that old functionalities work well after performing
changes in code.
• This testing is performed to give guarantee that new code added in
our software does not make any interruption in working of existing
functionalities.

➢ Advantages of Black Box Testing

• It is efficient for large systems.
• It identifies contradictions in functional specification.
• Detailed functional knowledge of system is not prerequisite for tester.
• Tester and developer work independently.

➢ Disadvantage of Black Box Testing

• It is difficult to find out all possible inputs for test-case in limited time.
• Test method cannot be used for complex code.
• Test cases cannot be designed without knowledge of functional
specifications.
• It may leave many program paths untested because of time constraint.
Reverse Engineering

➢ Reverse engineering is the process of analysing software to understand its

structure, functionality, and operation. This is typically done by examining
the compiled code or executable files, rather than the original source code.
➢ The goals of reverse engineering can vary, including:
• Understanding Legacy Systems: To understand how an existing system
works, especially when documentation is lacking or the original
developers are unavailable.
 • Bug Fixing and Maintenance: To identify and fix bugs in the absence of
source code.
• Security Analysis: To find vulnerabilities, backdoors, or malicious code.
• Interoperability: To ensure that new software can work with older
systems or software from other vendors.
• Software Piracy and Intellectual Property: To detect software piracy or
to protect intellectual property by understanding how competitors’
software works.
➢ Methods Used:
• Decompilation: Converting executable code back into a higher-level
programming language, albeit less readable and maintainable than the
original source code.
• Disassembly: Converting machine code into assembly language, which
is closer to the hardware's instructions but still quite low-level.
• Static Analysis: Examining the code without executing it, often using
tools to analyse structure and dependencies.
• Dynamic Analysis: Running the software to observe its behaviour and
interactions with other systems or software components.

Forward Engineering

➢ Forward engineering is the traditional process of software development,

where systems are designed and developed from the ground up based on
specified requirements.
➢ It involves:
• Requirement Analysis: Understanding and documenting what the
stakeholders need from the system.
• System Design: Creating architecture and design plans that fulfill the
requirements.
 • Implementation: Writing the source code based on the design
documents.
• Testing: Ensuring the software works as intended through various
levels of testing (unit, integration, system, and acceptance testing).
• Deployment: Releasing the software to users.
• Maintenance: Updating and improving the software over time based
on user feedback and changing requirements.
➢ Methods Used:
• Model-Driven Development: Using UML diagrams or other modelling
languages to design the software.
• Agile Methodologies: Iterative and incremental development
approaches like Scrum and Kanban.
• DevOps Practices: Integrating development and operations to
streamline and automate the software delivery process.
• Test-Driven Development (TDD): Writing tests before the actual code to
ensure each piece of functionality works as expected.
 Module 6
IT Project Management and Project Scheduling

4 P’s of Project Management

➢ People - The most important component of a product and its successful
implementation is human resources. In building 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.
➢ 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.
➢ 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.
➢ Project - The last and final P in software project planning is Project. It can
also be considered as a blueprint of process. 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.
W5HH Principle

W5HH The Question What It Means

Why is the system This focuses a team on the business

Why?
being developed? reasons for developing the software.

This is the guiding principle in

What? What will be done? determining the tasks that need to be
completed.

When will it be This includes important milestones and

When?
completed? the timeline for the project.

This is where you determine which

team member takes on which
Who is responsible for
Who? responsibilities. You may also identify
each function?
external stakeholders with a claim in
the project.

Where are they This step gives you time to determine

Where? organizationally what other stakeholders have a role in
located? the project and where they are found.

How will the job be In this step, a strategy for developing

How? done technically and the software and managing the project
managerially? is concluded upon.

The goal of this step is to figure out

How How much of each
the number of resources necessary to
Much? resource is needed?
complete the project.
Project Lifecycle
1. Initiation:
• Define the project at a high level.
• Establish the project's feasibility and justification.
• Identify key stakeholders.
• Develop a project charter and get approval to proceed.
2. Planning:
• Develop a detailed project plan that includes scope, schedule, cost,
quality, communication, risk, and resource management plans.
• Set clear objectives, deliverables, and performance measures.
• Identify and allocate resources.
• Plan for risk management and mitigation strategies.
3. Execution:
• Carry out the project plan by performing the activities and tasks.
• Coordinate people and resources.
• Manage stakeholder expectations and communication.
• Ensure quality assurance and adherence to the project plan.
4. Monitoring and Controlling:
• Track, review, and regulate the progress and performance of the
project.
• Identify any deviations from the plan and take corrective actions.
• Update project plans as necessary to reflect changes and ensure
project objectives are met.
5. Closure:
• Finalize all project activities.
• Complete and hand over the final deliverables.
• Obtain formal acceptance of the project.
• Conduct a post-project evaluation to document lessons learned and
best practices.
• Release project resources and provide closure to stakeholders.
Project Feasibility
➢ Feasibility:
• Feasibility describes how easy or difficult it is to do something. When
you set a goal at work, think about the long-term feasibility of
accomplishing what you want.
➢ Technical Feasibility
• This assessment focuses on the technical resources available to the
organization.
• It helps organizations determine whether the technical resources meet
capacity and whether the technical team is capable of converting the
ideas into working systems.
• Technical feasibility also involves the evaluation of the hardware,
software, and other technical requirements of the proposed system.
➢ Economic Feasibility
• This assessment typically involves a cost/ benefits analysis of the
project, helping organizations determine the viability, cost, and
benefits associated with a project before financial resources are
allocated.
➢ Legal Feasibility
• This assessment investigates whether any aspect of the proposed
project conflicts with legal requirements like zoning laws, data
protection acts or social media laws. • Let's say an organization wants
to construct a new office building in a specific location. A feasibility
study might reveal the organization's ideal location isn't zoned for that
type of business.
• That organization has just saved considerable time and effort by
learning that their project was not feasible right from the beginning.
➢ Operational Feasibility
• This assessment involves undertaking a study to analyse and determine
whether-and how well-the organization's needs can be met by
completing the project.
• Operational feasibility studies also examine how a project plan satisfies
the requirements identified in the requirements analysis phase of
system development.
 ➢ Scheduling Feasibility
• This assessment is the most important for project success; after all, a
project will fail if not completed on time. In scheduling feasibility, an
organization estimates how much time the project will take to
complete.

➢ Benefits of conducting a feasibility study:

• Improves project teams' focus
• Identifies new opportunities
• Provides valuable information for a "go/no-go" decision
• Narrows the business alternatives
• Identifies a valid reason to undertake the project
• Enhances the success rate by evaluating multiple parameters
• Aids decision-making on the project
• Identifies reasons not to proceed

Request for Proposal (RFP)

➢ A request for proposal is an early stage in procurement process, issuing an
invitation for suppliers, often through a bidding process, to submit a
proposal on a specific commodity or service.
➢ For example, let’s say you are a car parts business looking to take on a few
bids for a new ad campaign promoting the opening of a new body shop.
You’ll want to make sure that the contractors or digital marketing agencies
that are bidding to take this job know: What the scope of the project is?
How much your budget is for the project? What your deadline is? Any
possible roadblocks that would make the job more difficult or labour
intensive?
➢ RFP Process
• Project Planning
• Drafting the RFP
• Issuing the RFP
• Reviewing proposals and awarding contracts

➢ RFP Template
• Introduction and Background:
• Purpose of the request for Proposal
 • Project Objectives and additional background information about
project or business objectives in order to gain more trust from
vendors.
• Administrative Information:
• Technical Contact - Name, Address, phone, FAX, email
• Contractual Contact - Name, Address, phone, FAX, email
• Due Dates - Written confirmation of vendor’s intent to respond to
this RFP is required by XX/XX/XX. All proposal is due by time am/pm
on XX/XX/XX
• Proposal Submission
Award the contract which is given by a vendor whose offer is more
advantageous to ABC company.
• ABC company can:
• Reject any or all offers & discontinue this RFP process.
• Accept other than the lowest priced offer.
• Award more than one contact.

➢ Evaluation Factors for Award:

• Completion of all required responses in correct format.
• Vendor’s proposed solution fulfils ABC company’s stated requirements
• Vendor’s ability to deliver the indicated service in accordance to the
specification given in RFP.
• Vendor’s stability, experience and record of past performance in
delivering such services.
• Overall Cost of vendor’s proposal.

PMBOK Knowledge Areas

1. Integration Management:
• Overview: Ensures that project processes are properly coordinated.
• Example: Developing a project charter to formally start a project and
integrating various project plans into a cohesive whole.
2. Scope Management:
• Overview: Ensures that the project includes all the work required,
and only the work required, to complete the project successfully.
 • Example: Creating a Work Breakdown Structure (WBS) to detail all
the deliverables and work packages.
3. Schedule Management:
• Overview: Manages the timely completion of the project.
• Example: Developing a Gantt chart to visualize the project schedule
and track progress.
4. Cost Management:
• Overview: Ensures the project is completed within the approved
budget.
• Example: Creating a detailed budget and using Earned Value
Management (EVM) to track project performance and costs.
5. Quality Management:
• Overview: Ensures that the project meets the defined quality
standards.
• Example: Implementing a quality assurance plan to monitor
processes and conducting quality control tests on deliverables.
6. Resource Management:
• Overview: Ensures that the project has the necessary resources with
the right skills.
• Example: Creating a resource allocation plan and managing team
performance through regular reviews.
7. Communications Management:
• Overview: Ensures timely and appropriate planning, collection,
creation, distribution, storage, retrieval, management, control,
monitoring, and disposition of project information.
• Example: Developing a communication plan to ensure stakeholders
receive regular project updates.
8. Risk Management:
• Overview: Identifies, analyses, and responds to project risks.
• Example: Creating a risk register to document potential risks and
develop mitigation strategies.
9. Procurement Management:
• Overview: Manages the procurement of goods and services from
external sources.
• Example: Developing a procurement plan to outline how goods and
services will be acquired and managing contracts with suppliers.
 [Link] Management:
• Overview: Identifies and manages project stakeholders to ensure
their needs and expectations are met.
• Example: Conducting stakeholder analysis to understand their
interests and developing a stakeholder engagement plan.

WBS

➢ Starting point of WBS is to identify the main deliverables of a project.

Items can be broken down to different levels. One can break down one
task to ten items whereas other can break down same in 20 items.
➢ The effectiveness of a work breakdown structure can decide the success of
a project.
➢ The WBS provides the base for all project management work like planning,
cost, effort estimation, resource allocation and scheduling.
➢ Benefits of WBS
• Project budget and schedule can be easily calculated.
• Helps for identifying the project risk in a given project.
• If project is falling, the work breakdown structure can find out the
major
➢ The figure shows an example of a WBS for manufacturing of new toy. Here
each level is created by breaking down the work items (Decomposition)
 such as Market Research, Product Design etc. Project Scheduling and
Tracking
➢ Decomposition is the process of breaking down the items into smaller
items. The element which is present at the low level is called as Task. In the
example below, brochures, advertising and commercials are all work
packages or tasks.
➢ Therefore, creating WBS is critical step in the process of project
management.
Critical Path Method
➢ In a project, various activities are executed in parallel by different teams.
➢ Some activities are dependent on others and hence cannot start before
another task is complete. For example, team A cannot test database
connectivity unless team B updates the same data.
➢ When all the activities along with dependencies are documented, one can
determine the task that would consume the longest duration.
➢ Considering this longest duration, all other activities can be executed in
parallel with this activity (An activity which takes longest duration to
complete).
➢ Critical Path is longest sequence activities in a project plan which must be
completed on time for the project to complete on date.
➢ Based on which logic has been used in the project, some project can have
one critical path some can have many critical paths.
➢ If the delay occurs in any of the activity involving the critical path, then it
will ultimately lead the delay in the project deliverables. If such condition
occurs then re-sequencing is done so if the project deadlines can be
achieved.
➢ Critical path is considered as a method which is based on mathematical
calculations that a used for the purpose of scheduling project activities.
➢ Critical path method was first introduced in 1950s as a joint venture
between Remington R Corporation and DuPont Corporation.
➢ Initially critical path method was used for managing plant maintenance
projects.
➢ The original critical path method was developed for construction project.
Now the CPM can be used in any project where interdependent activities
are involved.
➢ In the critical path method, the critical activities of a project are first
identified.
➢ There are generally 5 steps involved the CPM:
1. Activity specification
• Work Break Down structure (WBS) is used to find out which
activities are involved in the project and hence it is the main input
of the CPM.
2. Activity sequence reorganization
• The correct activity sequence is recognized.
• Following are the steps to recognize the sequence of the CPM:
 • Identify the task that takes place before the critical task
happens.
• Identify the tasks that should be completed at the same time.
• Identify the tasks that should happen immediately after
critical task.
3. Network diagram
• Once the activity sequence is identified, the network diagram can
be drawn.
4. Estimates for each activity
• This is the direct input from the WBS based estimation sheet.
5. Identification of the critical path
• For this, there is need of determining 4 parameters of each
activity of the network.
1. Earliest start time (ES) - When the earlier dependent activities
are completed, one can start the earliest time of an activity.
2. Earliest finish time (EF) - ES + activity time.
3. Latest finish time (LF)- The most recent time of an activity can
be completed without delay in the project.
4. Latest start time (LS) - LF- activity duration.
5. Float Time - ES-LS
➢ Advantages of Critical Path Method
• Visual representation of the project activities
• To calculate Project deadlines.
• To track the critical activities.
Program Evaluation and Review Technique (PERT)
➢ PERT is related to management probabilities.
➢ PERT methods is included in many simple statistical methods. A PERT is a
project management technique used to plan, organize, and coordinate
tasks during the project.
➢ PERT is for Program Evaluation Review Technique, which was developed by
the U.S. Navy in 1950s for the purpose of managing the Polaris submarine
missile program.
➢ A PERT chart is a graphical representation of project network diagram that
will consist of numbered nodes.
➢ These nodes represent events. The project is linked by the directional line
which represents the tasks in the project. The direction of the arrow on the
diagram represents the sequence of task.

➢ In the above figure, the tasks between nodes 1, 2, 4, 8, and 10 have to be

completed in series. The are called as dependent or serial tasks. The tasks
between nodes 1 and 2, and nodes 1 and not dependent on each other
and hence they can be started simultaneously. These tasks are called
parallel or concurrent tasks.
➢ Tasks which can be carried out in sequence but doesn't need any resources
or completion time called as an event dependency. These are denoted
with the help of dotted lines with arrows are known as dummy activities.
For example, the dashed arrow between nodes 5 and 4 is termed as
dummy activity.
➢ Following are further details on each estimate:
1. TOPT (Optimistic time estimate)
• This is the fastest time during which activity can be finished. The
assumption is made that all the required resources are available and
all the previous activities are completed as planned.
2. TLIKELY (Most likely time estimate)
• Generally, project managers are asked to present one estimate
during the initial project period. In that case, this is the estimate
which goes to the upper management.
3. TPESS (Pessimistic time estimate)
• This is the maximum time required to complete an activity. It is
assumed that many things related to project activity will go wrong. A
lot of reworks will need to do and resource unavailability is
considered when such estimation is derived.
Earned Value Analysis (EAV)
➢ Earned Value Analysis (EVA) is the key technique used in project
management.
➢ The purpose of Earned Value Analysis is to understand how the project is
progressing.
➢ EVA used to estimate the progress of a project based on earnings or money
and schedules calculated on the basis of EVA
➢ In simple words Earned Value is a measure of Progress to evaluate
Percentage of Completeness.
➢ Features of EVA
• Earned Value Analysis's objective is to measure project performance in
terms of scope, cost and time.
• EVA is used to evaluate project health and project performance.
• Earned Value Analysis is also used for monitoring the progress of a
software project / team which involves tasks allocated to the Project
Schedule.
• Total time required to complete the project is calculated and each task is
given an Earned Vale based on its estimated (%) out of the total.

➢ Need for EVA

• Time to recover - If the project is not going as per plan and it is found
that there is some delay in the project. Then at this time, situation is
needed to be taken care by finding out the reasons that are causing
delay and by taking the required corrective actions.
• Request for additional funds/resources - While there is time to recover,
the need for extra resources or money can be calculated with an early
warning.
➢ Key Elements of EVA
• Planned Value (PV) - The allocated cost for the project which is approved.
It was known as Budgeted Cost of Work Scheduled (BCWS)
• Earned Value (EV) -The budgeted value of the completed work packages.
It used to be known as Budgeted Cost of Work Performance at a
specified point (BCWP).
• Actual Cost (AC) - The actual cost involved during the execution of
project work. It was previously called Actual Cost of Work Performed
(ACWP).
➢ Tools and techniques
• Schedule maker
• Planisware OPX2
• RiskTrak
• Winsight
• Primavera
Total slack, also known as total float, represents the amount of time a task can
be delayed without delaying the project's completion date.
Free slack, also known as free float, represents the amount of time a task can
be delayed without delaying the start of its successor tasks.