Reusable software resources

• Different types of reusable software resources that can be used in

software development to improve efficiency, reduce costs, and
shorten development time.

• Off-the-shelf components:
• These are pre-built, ready-to-use software components or modules
that are available for purchase or free download. They are designed
to meet common needs across different applications and industries.
• Examples: A pre-built payment gateway, logging libraries, or
authentication modules.
• Full-experience components:
• These components are more comprehensive and are designed to provide a
complete functionality for a specific task or use case. They may require
minimal integration and can be quickly added to a project to handle
complex features.
• Examples: An entire customer relationship management (CRM) system or a
full e-commerce solution.
• Partial-experience components:
• These components provide only a part of the required functionality for a
specific task or use case. They typically need to be combined with other
components or custom code to form a complete solution.
• Examples: A component for handling user authentication but requiring
additional code to integrate with a user profile management system.
• New components:
• These are custom-built or newly developed components that don't
exist off-the-shelf or as full/partial experience components. These are
often developed in-house or through collaboration and are tailored to
the specific needs of a project.
• Examples: A proprietary algorithm for data analysis or a custom API
for integrating with a unique internal system.
Environmental Resources

• Environmental resources in the context of software development refer

to the hardware and software components required to support and
enable the development, testing, and deployment of software
applications.
• Hardware Resources:
• These are the physical devices and infrastructure required for the
development process.
• Development Machines/Workstations:
• These are the computers or devices used by developers to write, compile, and
test the code. The specifications (e.g., CPU, RAM, storage) should be
appropriate for the programming languages, tools, and frameworks being used.
• Example: A powerful laptop for a developer working on machine learning
models, or a desktop for game development.
• Servers:
• Servers are needed for hosting software applications, databases, and
development environments. These can be on-premises or cloud-based
(like AWS, Azure, Google Cloud).
• Example: A web server to host your application or a database server
to store data.
• Networking Equipment:
• Network infrastructure like routers, switches, and firewalls are needed
to facilitate communication between development systems and
servers, and to maintain security in the development environment.
• Example: A secure VPN for remote access to the development
environment.
• Storage Devices:
• These are used for storing project files, databases, code repositories,
backups, etc. Storage devices can be local (e.g., external hard drives)
or cloud-based (e.g., AWS S3, Google Drive).
• Example: A network-attached storage (NAS) for shared team access.
• Testing and Simulation Devices:
• Specialized devices or virtual environments are needed for testing
applications in various conditions, such as mobile devices, IoT devices,
or virtual machines.
• Example: Emulators for testing mobile applications or virtual
environments for simulating production workloads.
• Software Resources:
• These are the tools, platforms, and environments needed to build,
test, and deploy software applications.
• Integrated Development Environments (IDEs):
• IDEs are software applications that provide a comprehensive
environment for writing, debugging, and compiling code.
• Example: Visual Studio, JetBrains IntelliJ IDEA, Eclipse.
• Version Control Systems (VCS):
• VCS tools help teams manage changes to source code, track versions,
and collaborate effectively.
• Example: Git (with platforms like GitHub, GitLab, or Bitbucket).
• Build and Continuous Integration (CI) Tools:
• These tools automate the process of building, testing, and deploying
software, ensuring that new code is integrated smoothly into the
project.
• Example: Jenkins, CircleCI, Travis CI.
• Databases:
• Databases store and manage data required by the application.
• Example: MySQL, PostgreSQL, MongoDB, Firebase.
• Libraries and Frameworks:
• Pre-built code modules, libraries, or frameworks provide reusable
functions to accelerate development.
• Example: React, Angular, Django, TensorFlow.
• Containerization and Virtualization Tools:
• Tools like Docker and Kubernetes allow developers to create
consistent development environments and deploy applications in
containers, simplifying the management of dependencies and
configurations.
• Example: Docker, Kubernetes, Vagrant.
• Testing and Debugging Tools:
• These tools are used to identify bugs, test software functionality, and
ensure quality before deployment.
• Example: Selenium for web application testing, Postman for API
testing, or Xcode’s debugger for iOS apps.
• Collaboration and Project Management Tools:
• These tools are used to facilitate communication and project tracking
among team members.
• Example: Jira for task management, Slack for team communication,
Trello for project organization.
• Cloud Services:
• Cloud-based platforms provide resources for hosting applications,
managing databases, performing machine learning tasks, etc.
• Example: AWS, Google Cloud Platform, Microsoft Azure.
Software project estimation

• It is an effective activity in software development project.

• It is the procedure that predicts the time and budget required for
completing a project.
• It requires the use of complex tools and good mathematical as well as
knowledge about planning.
• One of the main reasons software programs fails is our inability to
accurately estimate software size.
• Responsible persons :
• Software managers
• Cognizant engineers
• Software estimaters
Factors affect on Software Project Estimation

1. Cost : Project will fail if you don’t have sufficient funds to complete it.
So, at early stage , ensure that you have enough money to comple
work.
2. Time : Estimate overall project duration and time for individual task. It
help to manage client expectations.
3. Size and scope : All the tasks must be completed in order to deliver
product on time. For that, you should have right materials and
expertise on the project by estimating how much work is involved and
exactly what tasks must be completed.
4. Risk : Estimating predicting risks. Create risk management plans.
5. Resources : Ensure that you have all the resources (like tools, people,
material, hardware, software etc)you require and make best use of
them.
• To achieve reliable cost and effort estimates, there are different
approaches that you can follow.
• Delay Estimation Until Late in the Project (Achieving 100% Accuracy After
Completion)
This approach suggests postponing the estimation until the project is almost
complete, as you can then have a 100% accurate estimate of the cost and
effort based on the actual work done.

• Base Estimates on Similar Projects That Have Already Been Completed

This method involves using historical data from similar projects that have
been completed in the past. By comparing the current project with these
reference projects, you can create an estimate based on what was required
for similar past efforts.
• Use Relatively Simple Decomposition Techniques to Generate Project Cost
and Effort Estimates
This approach involves
, usually using a Work Breakdown Structure (WBS). Each smaller task can then
be estimated, and the total effort is calculated by summing the estimates for
individual tasks.

• Use One or More Empirical Models for Software Cost and Effort Estimation
Empirical models are data-driven estimation techniques that rely on historical
project data and statistical analysis to predict the cost and effort of a new
project. Well-known models include COCOMO (Constructive Cost Model),
Function Point Analysis (FPA), and other parametric models. These models use
parameters such as project size, complexity, and the development
environment to generate estimates.
Decomposition techniques
• These take a "divide and conquer" approach.
• Cost and effort estimation are performed in a stepwise fashion by breaking
down a project into major functions and related software engineering
activities.
• Software project estimation is a form of problem solving.
• The problem to be solved is too complex to be considered in one piece.
• Two different points of view for the decomposition approach
Decomposition of the problem
Decomposition of the process
• But first, the project planner must
Understand the scope of the s/w to be built
Generate an estimate of its “size”
Different decomposition techniques
are :
1. Software sizing
Software sizing is used to estimate the size of a software application or
component to support cost estimating, progress tracking, and other software
project management activities.
• Estimation Accuracy:
• (1) the degree to which you have properly estimated the size of the product to
be built.
• (2) the ability to translate the size estimate into human effort, calendar time,
and dollars .
• (3) the degree to which the project plan reflects the abilities of the software
team.
• (4) the stability of product requirements and the environment that supports the
software engineering effort.
• In the context of project planning, size refers to a quantifiable
outcome of the software project.
▪ size can be measured in lines of code (LOC)
▪ size is represented as function points (FP)

• Different approaches to the sizing problem

1. Fuzzy logic” sizing
2. Function point sizing
3. Standard component sizing
4. Change sizing
• Different approaches to the sizing problem:
1. “Fuzzy logic” sizing
• The planner must identify the type of application (Decide size according to type i.e. web or app
project).
• establish its magnitude on a qualitative scale, then refine the magnitude within the original
range

2. Function point sizing

• The planner develops estimates of the information domain characteristics (size decides on basis
of features, information, specification of project).

3. Standard component sizing

• Software is composed of a number of different “standard components” that are generic to a
particular application area like subsystems, modules, screens, reports, interactive programs,
batch programs, files ,LOC and object level instructions.
• Uses historical project data to determine the delivered size per standard component.
4. Change sizing
• This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of a project.
• The planner estimates reuse, adding code, changing code, deleting
code of modifications that must be accomplished.
2. Problem-Based Estimation
• LOC(Lines of source code) and FP(Function Point) data are used in two ways
during software project estimation:
(1) as estimation variables to “size” each element of the software
(2) as baseline metrics collected from past projects and used in conjunction with
estimation variables to develop cost and effort projections.
▪ The LOC and FP estimation techniques differ in the level of detail required for
decomposition and the target of the partitioning.
▪ When LOC is used as the estimation variable, decomposition is absolutely
essential and is often taken to considerable levels of detail.
▪ The greater the degree of partitioning, the more likely reasonably accurate
estimates of LOC can be developed.
▪ For FP estimates, decomposition works differently. Rather than focusing on
function, each of the information domain characteristics—inputs, outputs, data
files, inquiries, and external are estimated.
• Project planner begins by estimating a range of values for each
function or information domain value.(i.e. regardless of the
estimation variable)
• ▪Planner estimates an optimistic (low), most likely, and pessimistic
(high) size value for each function or count for each information
domain value.
▪The expected value for the estimation variable (size), S, can be
computed as a weighted average of the optimistic (Sopt), most likely
(Sm), and pessimistic (Spess) estimates
S = (Sopt + 4Sm + Spess)/6
▪Once the expected value for the estimation variable has been
determined, historical LOC or FP productivity data are applied.
Function Point (FP)
• A Function Point (FP) is a unit of measurement to express the amount
of business functionality, an information system(as a product)
provides to a user
• ▪There are multiple parameters in functional point analysis process
calculation.
• They are as follows:
▪ External Inputs(EI)
▪ External Outputs(EO)
▪ External Inquiries (EI)
▪ Internal Logic Files(ILF)
▪ External Logic Files(ELF)
Difference between FP and LOC
Function Point (FP Line of Code (LOC
Function Point metric is specification-based. LOC metric is based on analogy
Function Point metric is language independent. LOC metric is dependent on language
Function Point metric is user-oriented. LOC metric is design-oriented
Function Point metric is extendible to Line of Code It is changeable to FP (i.e, backfiring)
Function Point is used for data processing systems LOC is used for calculating the size of the computer
program
Function Point can be used to portray the project time LOC is used for calculating and comparing the
productivity of programmers.
Process-Based Estimation
• The most common technique for estimating a project is to base the
estimate on the process that will be used.
• ▪Process-based estimation begins with a delineation of software
functions obtained from the project scope.
• ▪A series of framework activities must be performed for each function
Estimation with Use-case
• Use cases are described using many different formats and styles—
there is no standard form.
• ▪Use cases represent an external view of the software and can
therefore be written at many different levels of abstraction.
• ▪Use cases do not address the complexity of the functions and
features that are described.
• ▪Use cases can describe complex behavior that involve many
functions and features
• It is argued that any level of Use-case Structural Hierarchy a) Can be described by
no more than 10 Use-cases b) Each Use-case would contain no more than 30
distinct Scenarios.
▪ Before Use-cases can be used for Estimation
a) The Level within the Structural Hierarchy is established
b) The Average Length (in pages) of each Use-case is determined,
c) Type of Software is defined (eg. Real time, Business, Engineering / Scientific, etc)
d) Rough architecture for the System is considered
▪ Once these characteristics are established, Empirical Data may be used to
establish the Estimated number of LOC or FP per Use-case (for each level of
hierarchy).
▪ The Structured Hierarchical data then used to compute the Effort required to
develop the System
Reconciling Estimates
• The results gathered from the various estimation techniques must be
reconciled to produce a single estimate of effort, project duration and
cost
▪Examination of the four different Problem-Based Estimation
techniques indicate different Total Estimated Efforts for the CAD
Software range from
▪ 46 Person-months to a high of 68 Person-months
▪ The Average Estimate Of Efforts is 56 Person-months
▪The variation from Average estimate is approximately 18% on the low
side and 21% on the high side.
What Happens When Agreement
Between Estimates is poor?
• The answer to this question requires a re-evaluation of information used to
make the Estimates.
▪Widely divergent Estimate can often be traced to one of the two causes
1. The Scope of the Project is not adequately understood or has been
misinterpreted by the Project planner
2. Productivity data used for Problem-Base Estimation Techniques is
inappropriate for the Application
▪ Productivity Data is either obsolete (no longer accurately reflects the Software
Engineering Organization) , or has been misapplied.
▪ The Project Planner must determine the cause of divergence and then
reconcile the Estimates.
Empirical Estimation models
• An Estimation model for Computer Software uses Empirically derived formulas to predict
Effort as a Function of LOC or FP.
▪ Values for LOC and FP are estimated using LOC based Estimations and FP Based
Estimations.
▪ The resultant Values out of these Estimation are plugged into the Estimation
Model.
▪ The Empirical data that support most Estimation Models are derived from a limited
sample of Projects. For this reason, no Estimation Model is appropriate for all Classes of
Software and in all Development Environments.
▪ Therefore, the results obtained from such Models must be used judiciously.
▪ An Estimation Model should be calibrated to reflect local conditions.
▪ The Estimation Model should be tested by applying data collected from completed
projects, plugging the data into model, and then comparing Actual to Predicted results.
▪ If agreement is poor the Estimation Model must be tuned and reflected before it
can be used