Software Engineering

PCCCS403
Module - 2
Piyali Chandra
Assistant Professor
UEMK
Software requirement
• Software requirements are a way to identify and clarify
the why, what and how of a business's application.
• The software requirements are description of features and
functionalities of the target system. Requirements convey the
expectations of users from the software product. The requirements
can be obvious or hidden, known or unknown, expected or
unexpected from client’s point of view.
Types of Software requirements
Software requirements typically break down into:
• functional requirements
• nonfunctional requirements
• domain requirements
Functional Requirements
• Functional requirements are such software requirements that are
demanded explicitly as basic facilities of the system by the end-users.
• They describe system behavior under specific conditions.
• These are represented as inputs to the software system, its behavior,
and its output.
• It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what
function a system is likely to perform.
• Functional requirements are relatively easy and straightforward to
test because they define how the system behaves.
Non-functional Requirements(NFRs)
• Nonfunctional requirements relate to software usability.
Nonfunctional software requirements define how the system must
operate or perform.
• A system can meet its functional requirements and fail to meet its
nonfunctional requirements.
• The process of specifying non-functional requirements requires the
knowledge of the functionality of the system, as well as the
knowledge of the context within which the system will operate.
Non-functional Requirements(cont..)
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Domain requirements
• Domain requirements are expectations related to a particular type of
software, purpose or industry vertical. Domain requirements can be
functional or nonfunctional.
• Domain requirements engineering is a continuous process of
proactively defining the requirements for all foreseeable applications
to be developed in the software product line. The basic functions that
a system of a specific domain must necessarily exhibit come under
this category.
Requirements Verification and Validation
• Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.
• Validation: It refers to a different set of tasks that ensures that the
software that has been built is traceable to customer requirements.

The main steps for this process include:

• The requirements should be consistent with all the other requirements i.e
no two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.
Factors of Management Dependency in Software
Development
• People
Of course, the management has to deal with people in every stage of
the software developing process. From the ideation phase to the final
deployment phase, including the development and testing phases in
between, there are people involved in everything, whether they be the
customers or the developers, the designers or the salesmen.
• Project
From the ideation phase to the deployment phase, we term the
process as a project. Many people work together on a project to build a
final product that can be delivered to the customer as per their needs
or demands.
Factors of Management Dependency in
Software Development(cont..)
• Process
Every process that takes place while developing the software, or we can say
while working on the project must be managed properly and separately. For
example, there are various phases in a software development process and
every phase has its process like the designing process is different from the
coding process, and similarly, the coding process is different from the testing.
• Product
Even after the development process is completed and we reach our final
product, still, it needs to be delivered to its customers. Hence the entire
process needs a separate management team like the sales department.
Software Project Estimation
• Software project estimation approaches assist project managers in
effectively estimating critical project parameters such as cost and
scope.
• Without accurate estimates, it’s impossible to plan your project. If
you don’t have an idea of how long the project will take or what
resources you will need, there is no way to ensure you’ll have the
right people, materials, or tools available when you need them.
What types of estimations take place during a
project?
• Cost- Cost is one of the three main constraints in project
management. If you don’t have enough money to complete the
project, it will fail.
• Time- Time is another of the three main project constraints. Being
able to estimate both the overall project duration and when
individual tasks will take place is vital to project planning.
• Scope- Scope is the third key project constraint. Project scope is all
the work that must be done to finish the project or deliver a product.
Major project estimation techniques
• Expert Judgment: In this technique, a group of experts in the relevant
field estimates the project size based on their experience and
expertise. This technique is often used when there is limited
information available about the project.
• Analogous Estimation: This technique involves estimating the project
size based on the similarities between the current project and
previously completed projects. This technique is useful when
historical data is available for similar projects.
Major project estimation techniques(cont..)
• Bottom-up Estimation: In this technique, the project is divided into smaller
modules or tasks, and each task is estimated separately. The estimates are
then aggregated to arrive at the overall project estimate. This type of
estimate is more accurate than the top-down approach because each
activity is assessed individually.
• Top-Down Estimate: Top-down estimating assigns an overall time for the
project and then breaks it down into individual phases, work, and tasks
based on the work breakdown structure of your project. If a client specifies
that the project must be completed in six months, a top-down approach
allows you to take that overall timeline and estimate how much time you
can commit to each project activity while still meeting the deadline that
has been given by the client.
Major project estimation techniques(cont..)
• Three-point Estimation: This technique involves estimating the
project size using three values: optimistic, pessimistic, and most likely.
These values are then used to calculate the expected project size
using a formula such as the PERT(Project Evaluation and Review
Technique) formula.
Estimation = (p + 4m + o) / 6 (P – pessimistic, O – optimistic,
M– most likely)
• Parametric Estimation: For precise size estimation, mathematical
models founded on project parameters and historical data are used.
Major project estimation techniques(cont..)
• Function Points: This technique involves estimating the project size
based on the functionality provided by the software. Function points
consider factors such as inputs, outputs, inquiries, and files to arrive
at the project size estimate.
• Use Case Points: This technique involves estimating the project size
based on the number of use cases that the software must support.
Use case points consider factors such as the complexity of each use
case, the number of actors involved, and the number of use cases.
• Wideband Delphi: Consensus-based estimating method for balanced
size estimations that combines expert estimates from anonymous
experts with cooperative conversations.
Major project estimation techniques(cont..)
COCOMO (Constructive Cost Model): It is an algorithmic model that
estimates effort, time, and cost in software development projects by
taking into account a number of different elements.
• The key parameters that define the quality of any software products,
which are also an outcome of the Cocomo are primarily Effort and
schedule:
• Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.
• Schedule: This simply means the amount of time required for the
completion of the job, which is, of course, proportional to the effort
put in. It is measured in the units of time such as weeks, and months.
Major project estimation techniques(cont..)
COCOMO(cont..)
• Organic: A software project is said to be an organic type if the team size required
is adequately small, the problem is well understood and has been solved in the
past and also the team members have a nominal experience regarding the
problem(50KLOC or less).
• Semi-detached: A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various
programming environments lie in between organic and embedded. The projects
classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience better
guidance and creativity(50-300KLOC or less).
• Embedded: A software project requiring the highest level of complexity,
creativity, and experience requirement falls under this category. Such software
requires a larger team size than the other two models and also the developers
need to be sufficiently experienced and creative to develop such complex
models(300KLOC or more).
Major project estimation techniques(cont..)
• COCOMO(cont..)
• E = a(KLOC)^b
• Time = c(Effort)^d
• Person required = Effort/ time

Software Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

EXAMPLE
Qsn: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached &
embedded.
• Solution: The basic COCOMO equation takes the form:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM
Major project estimation techniques(cont..)
What is COCOMO 2?
• COCOMO 2 is another cost-estimating methodology utilized to
calculate the cost of software development. It was mainly designed to
resolve the shortcomings of the COCOMO 1 model.
• It is based on the non-linear reuse formula.
Differences between COCOMO 1 and
COCOMO 2
• COCOMO 1 is very useful in waterfall model of the software development cycle (SDLC). In contrast,
COCOMO 2 is useful in quick development, non-sequential, and reuses software models.
• COCOMO 1 is mainly based on the assumption of reasonable stable needs. In contrast, COCOMO
2 is based on the reuse model, which emphasizes the effort necessary to understand and
estimate.
• COCOMO 1 offers time estimations and effort. In contrast, COCOMO 2 offers estimates that are
one standard deviation from the most common estimate.
• The size of the program in COCOMO 1 is indicated in lines of code. In contrast, COCOMO 2 has
extra factors for expressing software size, including lines of code, object points, and function
points.
• COCOMO 1 has 3 submodels (basic, intermediate, and advanced). In contrast, COCOMO 2 has 4
submodels (application development model, post-architectural model, early design model, and
reuse model).
• COCOMO 1 makes utilize of 15 cost drivers. In contrast, COCOMO 2 makes utilize 17 different cost
drivers.
• As compared to the COCOMO 1 model, COCOMO 2 may reduce the amount of risk.
Major project estimation techniques(cont..)
• Line of code(LOC)
The size of a major project by counting the number of source
instructions in the development program.
LOC is any line of program text that is not comments or blank line.
It includes all lines containing program heads, declarations, executable
or non-executable lies.
Cyclomatic Complexity
It measures the number of linearly-independent paths through a program
module. Programs with lower Cyclomatic complexity are easier to
understand and less risky to modify.

• V(G)= e-n+2p(e=edges, n=node, p=connected component)

• V(G)= ∏+1 (∏= predicate node)
• No of regions
QUESTION: Write a function using C programming language to compute
whether a number input from the user is prime or not. Draw the
corresponding CFG for the said function and compute its cyclomatic
complexity.
What Is Work Breakdown Structure in
Project Management?
• Work breakdown structure (WBS) in project management is a method
for completing a complex, multi-step project. It's a way to divide and
conquer large projects to get things done faster and more efficiently.
• As the project manager, you want to ensure that all critical input and
deliverables are gathered and transparently prioritized. You may use
Gantt charts, flow charts, spreadsheets, or lists to show the
hierarchical outline of importance and connectivity between the tasks
needed to complete the project.
• Each WBS level represents a new and increasingly detailed definition
of work needed to complete the project.
Software Project Management Plan (SPMP)
Once project designing is complete, project managers document their plans during a software
package Project Management setup (SPMP) document.
List the important items of software project management plan (SPMP):
• Introduction (Objectives, Major Functions, Performance Issues, Management and Technical
Constraints)
• Project Estimates (Historical Data Used, Estimation Techniques Used, Effort, Resource, Cost, and
Project Duration Estimates)
• Schedule (Work Breakdown Structure, Task Network Representation, Gantt Chart Representation,
PERT Chart Representation)
• Project Resources (People, Hardware and Software, Special Resources)
• Staff Organization (Team Structure, Management Reporting)
• Risk Management Plan (Risk Analysis, Risk Identification, Risk Estimation, Risk Abatement
Procedures)
• Project Tracking and Control Plan
• Miscellaneous Plans (Process Tailoring, Quality Assurance Plan, Configuration Management Plan,
Validation and Verification, System Testing Plan, Delivery, Installation, and Maintenance Plan)
Schedule slippage for a software product
delivery
• Project slippage is the act of missing deadlines when managing a task
or series of tasks. This can happen during the project planning stages
or while a team is executing tasks, resulting in a delay between the
scheduled times and the actual completion dates. When project
slippage occurs, team members evaluate other milestones and tasks
to see where they might shorten deadlines to meet the originally
planned completion date.
What is egoless programming?
• egoless programming An approach to based on consensus within a
small team. The aim is to produce software that is the product of the
team rather than of one or a few individuals. The motivation is to
avoid personal identification with output, promote group
identification, and thus to make it easier for the team to conduct an
objective evaluation of the programs produced.
ISO9000 and SEI-CMM
• ISO 9000:
It is a set of International Standards on quality management and quality
assurance developed to help companies effectively document the quality
system elements needed to an efficient quality system. Focus of ISO9000 is
on customer supplier relationship, and to reduce the customer's risk.
ISO9000 is used by manufacturing industries. ISO9000 certificate is valid for
three years.
• SEICMM:
SEI (Software Engineering Institute), Capability Maturity Model (CMM)
specifies an increasing series of levels of a software development
organization. Focus of SEI-CMM is to improve the processes to deliver a
quality software product to the customer. SEI-CMM is used by software
industry. SEI-CMM certificate is valid for three years as well.
What is the Critical Path Method?
• To complete a project, we must perform all the activities that
compose it. Some activities can be done simultaneously, but others
must be done in a certain order.
Critical Path Method(cont..)
How to Calculate Early Start, Late Start, Early Finish, Late Finish and Slack (Float)
• Duration (t): Indicates the time it takes to complete the activity.
• Early Start Time (ES): This is the earliest time that an activity can be started assuming all previous activities
have been completed beforehand. For activities that have more than one precedent, the ES is the greatest of
the late start time of their precedents.
• Early finish Time (EF): This is the earliest time that an activity can finish. It is equal to the early start time
plus its estimated duration (t): EF = ES + t
• Late Finish Time (LF): This is the latest time at which an activity can be completed without delaying the
entire project. It is obtained by equaling the late start time of the activity that immediately follows. If
activities have more than one task immediately following them, the LF will be the least of the late start time
of those activities.
• Late Start Time (LS): It is the latest time an activity can begin without delaying the whole project. It is equal
to the Late Finish Time minus the expected duration of that activity (t): LS = LF – t
• Slack – Float (S): A period of time when an activity can be delayed without causing the entire project to be
delayed. All activities contained in the critical path have zero slack. Here is how it is calculated
mathematically: S = LS – ES = LF – EF
Six Sigma
• Six Sigma is the process of producing high and improved quality
output. This can be done in two phases – identification and
elimination. The cause of defects is identified and appropriate
elimination is done which reduces variation in whole processes. A six
sigma method is one in which 99.99966% of all the products to be
produced have the same features and are of free from defects.
Software Maintenance
• Software Maintenance refers to the process of modifying and updating a
software system after it has been delivered to the customer.
• The goal of software maintenance is to keep the software system working
correctly, efficiently, and securely, and to ensure that it continues to meet
the needs of the users.
• This can include fixing bugs, adding new features, improving performance,
or updating the software to work with new hardware or software systems.
• It is also important to consider the cost and effort required for software
maintenance when planning and developing a software system.
Types of Software Maintenance
• Corrective Maintenance: Corrective maintenance aims to correct any remaining
errors regardless of where they may cause specifications, design, coding, testing,
and documentation, etc.
• Adaptive Maintenance: It contains modifying the software to match changes in
the ever-changing environment.
• Preventive Maintenance: It is the process by which we prevent our system from
being obsolete. It involves the concept of reengineering & reverse engineering in
which an old system with old technology is re-engineered using new technology.
This maintenance prevents the system from dying out.
• Perfective Maintenance: It defines improving processing efficiency or
performance or restricting the software to enhance changeability. This may
contain enhancement of existing system functionality, improvement in
computational efficiency, etc.
Reliability Metrics
• Reliability metrics are used to quantitatively expressed the reliability of the
software product. The option of which metric is to be used depends upon the
type of system to which it applies & the requirements of the application domain.
• Some reliability metrics which can be used to quantify the reliability of the
software product are as follows:
1. Mean Time to Failure (MTTF)
MTTF is described as the time interval between the two successive failures.
An MTTF of 200 mean that one failure can be expected each 200-time units. The
time units are entirely dependent on the system & it can even be stated in the
number of transactions. MTTF is consistent for systems with large transactions. To
measure MTTF, we can evidence the failure data for n failures. Let the failures
appear at the time instants t1,t2.....tn. MTTF can be calculated as
Reliability Metrics(cont..)
2. Mean Time to Repair (MTTR)
Once failure occurs, some-time is required to fix the
error. MTTR measures the average time it takes to track the errors
causing the failure and to fix them.
3. Mean Time Between Failure (MTBR)
We can merge MTTF & MTTR metrics to get the MTBF metric.
MTBF = MTTF + MTTR
Thus, an MTBF of 300 denoted that once the failure appears, the next
failure is expected to appear only after 300 hours. In this method, the
time measurements are real-time & not the execution time as in MTTF.
Reliability Metrics(cont..)
• Rate of occurrence of failure (ROCOF)
• It is the number of failures appearing in a unit time interval. The number of
unexpected events over a specific time of operation. ROCOF is the frequency of
occurrence with which unexpected role is likely to appear. A ROCOF of 0.02 mean
that two failures are likely to occur in each 100 operational time unit steps. It is
also called the failure intensity metric.
• Probability of Failure on Demand (POFOD)
POFOD is described as the probability that the system will fail when a service is
requested. It is the number of system deficiency given several systems inputs.
POFOD is the possibility that the system will fail when a service request is made.
A POFOD of 0.1 means that one out of ten service requests may [Link] is an
essential measure for safety-critical systems. POFOD is relevant for protection
systems where services are demanded occasionally.
What is Software Quality?
• Software Quality shows how good and reliable a product is. To convey
an associate degree example, think about functionally correct
software.
• Factors of Software Quality
Factors of Software Quality(cont..)
• Portability: A software is claimed to be transportable, if it may be simply created to figure in several package
environments, in several machines, with alternative code merchandise, etc.
• Usability: A software has smart usability if completely different classes of users (i.e. knowledgeable and
novice users) will simply invoke the functions of the merchandise.
• Reusability: A software has smart reusability if completely different modules of the merchandise will simply
be reused to develop new merchandise.
• Correctness: Software is correct if completely different needs as laid out in the SRS document are properly
enforced.
• Maintainability: A software is reparable, if errors may be simply corrected as and once they show up, new
functions may be simply added to the merchandise, and therefore the functionalities of the merchandise
may be simply changed, etc.
• Reliability: Software is more reliable if it has fewer failures. Since software engineers do not deliberately
plan for their software to fail, reliability depends on the number and type of mistakes they make. Designers
can improve reliability by ensuring the software is easy to implement and change, by testing it thoroughly,
and also by ensuring that if failures occur, the system can handle them or can recover easily.
• Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk space, network
bandwidth, and other resources. This is important to customers in order to reduce their costs of running the
software, although with today’s powerful computers, CPU time, memory and disk usage are less of a
concern than in years gone by.
Thank you and Happy learning