Software engineering is a collection of
interconnected phases. These steps are expressed
or available in different ways in different software
process models. Umbrella activities, such as
project management, quality assurance, and
documentation, support these phases, ensuring
consistency, quality, and efficient progress
throughout the development process.
Table of Content
What is Umbrella Activities?
Tasks of Umbrella Activities
Conclusion
Frequently Asked Questions related to
Umbrella Activities
What is Umbrella Activities?
Umbrella activities are a series of steps or
procedures followed by a software development
team to maintain the progress, quality, changes,
and risks of complete development tasks. These
steps of umbrella activities will evolve through the
phases of the generic view of software
development.
The activities in the software development
process are supplemented by many general
activities. Generally, common activities apply to
the entire software project and help the software
development team manage and track progress,
quality, changes, and risks.
Tasks of Umbrella Activities
Umbrella activities consist of different tasks:
Software Project Tracking and Control
Formal Technical Reviews
Software Quality Assurance
SCM or Software configuration management
Document Preparation and Production
Re-usability Management
Measurement and Metrics
Risk Management
Umbrella Activities
Software project tracking and control: This
activity allows the software team to check the
progress of software development. Before the
actual development starts, make a software
development plan and develop on this basis,
but after a certain period of time, it is
necessary to analyze the development progress
to find out what measures need to be taken. It
must be accepted at an appropriate time after
the completion of development, testing, etc.
The test results may need to reschedule the
development time.
Risk management: Risk management is a
series of steps to help software development
teams understand and manage uncertainty. It is
a very good idea to identify it, assess the
likelihood of it happening, assess its impact,
and develop an “if the problem does happen”
contingency plan.
Software quality assurance: As its name
suggest this defines and conducts the
activities required to ensure software quality.
The quality of the software, such as user
experience, performance, workload flexibility,
etc., must be tested and verified after reaching
the specified milestones, which reduces the
tasks at the end of the development process,
which must be performed by a dedicated team
so that the development can continue.
Technical reviews: It assesses software
engineering work products in an effort to
uncover and remove errors before they are
propagated to the next activity. Software
engineering is done in clusters or modules,
after completing each module, it is good
practice to review the completed module to
find out and remove errors so their
propagation to the next module can be
prevented.
Measurement: This includes all measurements
of all aspects of the software project. Define
and compile process, project, and product
metrics to help the team deliver software that
meets the needs of stakeholders; it can be used
in conjunction with all other frameworks and
general operations.
Software configuration management: It
manages the impact of changes throughout the
software development process. Software
Configuration Management (SCM) is a set of
activities designed to manage changes by
identifying work products that can be changed,
establishing relationships between them, and
defining mechanisms for managing different
versions of them. Work product.
Reusability management: Define the standards
for the reuse of work products (including
software components), and develop
mechanisms to implement reusable
components. This includes the approval of any
part of a backing-up software project or any
type of support provided for updates or
updates in the future. Update the software
according to user/current time requirements.
Work product preparation and production: It
encompasses the activities required to create
work products such as models, documents,
logs, forms, and lists.
Software Myths:
Most, experienced experts have seen myths or
superstitions (false beliefs or interpretations) or
misleading attitudes (naked users) which creates
major problems for management and technical
people. The types of software-related myths are
listed below.
`Types of Software Myths
(i) Management Myths:
Myth 1:
We have all the standards and procedures available
for software development.
Fact:
Software experts do not know all the
requirements for the software development.
And all existing processes are incomplete as
new software development is based on new
and different problem.
Myth 2:
The addition of the latest hardware programs will
improve the software development.
Fact:
The role of the latest hardware is not very high
on standard software development; instead
(CASE) Engineering tools help the computer,
they are more important than hardware to
produce quality and productivity.
Hence, the hardware resources are misused.
Myth 3:
With the addition of more people and program
planners to Software development can help
meet project deadlines (If lagging behind).
Fact:
If software is late, adding more people will
merely make the problem worse. This is
because the people already working on the
project now need to spend time educating the
newcomers, and are thus taken away from
their work. The newcomers are also far less
productive than the existing software
engineers, and so the work put into training
them to work on the software does not
immediately meet with an appropriate
reduction in work.
(ii)Customer Myths:
The customer can be the direct users of the
software, the technical team, marketing / sales
department, or other company. Customer has
myths leading to false expectations (customer) &
that’s why you create dissatisfaction with the
developer.
Myth 1:
A general statement of intent is enough to start
writing plans (software development) and details
of objectives can be done over time.
Fact:
Official and detailed description of the
database function, ethical performance,
communication, structural issues and the
verification process are important.
Unambiguous requirements (usually derived
iteratively) are developed only through
effective and continuous
communication between customer and
developer.
Myth 2:
Software requirements continually change, but
change can be easily accommodated because
software is flexible
Fact:
It is true that software requirements change,
but the impact of change varies with the time
at which it is introduced. When requirements
changes are requested early (before design or
code has been started), the cost impact is
relatively small. However, as time passes, the
cost impact grows rapidly—resources have
been committed, a design framework has been
established, and change can cause upheaval
that requires additional resources and major
design modification.
Different Stages of Myths
(iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed
with the writing of the plan.
Fact:
It is true that every 60-80% effort goes into the
maintenance phase (as of the latter software
release). Efforts are required, where the
product is available first delivered to
customers.
Myths 2:
There is no other way to achieve system quality,
until it is “running”.
Fact:
Systematic review of project technology is the
quality of effective software verification
method. These updates are quality filters and
more accessible than test.
Myth 3:
An operating system is the only product that can
be successfully exported project.
Fact:
A working system is not enough, the right
document brochures and booklets are also
required to provide guidance & software
support.
Myth 4:
Engineering software will enable us to build
powerful and unnecessary document & always
delay us.
Fact:
Software engineering is not about creating
documents. It is about creating a quality
product. Better quality leads to reduced
rework. And reduced rework results in faster
delivery times
