Scribd
Upload
42 views7 pages

Umbrella Activities in Software Engineering

umbrealla activites important topic

Uploaded by

rhattarde12
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
42 views7 pages

Umbrella Activities in Software Engineering

umbrealla activites important topic

Uploaded by

rhattarde12
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Umbrella Activities in Software Engineering


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.

Introduction:
In software development, the concepts of tight coupling and loose
coupling are crucial in designing maintainable and flexible systems.
Tight coupling refers to strong dependencies between components,
making it challenging to modify or replace one component without
affecting others. On the other hand, loose coupling promotes
decoupling between components, allowing for independent
development, modification, and testing. This article will explore the
differences between tight coupling and loose coupling, and provide
Kotlin examples to illustrate their practical implications.
Tight Coupling:
Tight coupling occurs when components directly depend on specific
implementations of other components. This dependency results in
several drawbacks, including:

1. High dependency: Components tightly coupled to specific


implementations are highly dependent on those implementations,
making it difficult to substitute them with alternatives.
2. Code fragility: Modifying a tightly coupled component can lead
to a cascade of changes throughout the system, increasing the risk of
introducing bugs or unintentional side effects.
3. Reduced testability: Tightly coupled components are
challenging to isolate and test independently, requiring complex
setups and potentially affecting the validity and coverage of unit
tests.

Example of Tight Coupling in Kotlin:


Consider an example where a `PaymentProcessor` class depends on
a specific `PaymentGateway` implementation:

class PaymentProcessor {
private val paymentGateway = PayPalGateway() // Tight coupling to
PayPalGateway
fun processPayment(amount: Double) {
paymentGateway.authenticate()
paymentGateway.processPayment(amount)
paymentGateway.sendConfirmation()
}
}

In this example, the `PaymentProcessor` class directly instantiates


the `PayPalGateway` class, tightly coupling the two. If we wanted to
switch to a different payment gateway implementation, we would
need to modify the `PaymentProcessor` class, potentially causing
ripple effects throughout the codebase.

Loose Coupling:
Loose coupling emphasizes designing components with minimal
dependencies on specific implementations. This approach offers
several benefits, including:

1. Increased flexibility: Loosely coupled components can be


easily replaced or modified without affecting other parts of the
system, allowing for more flexible and modular software design.
2. Improved maintainability: Modifying a loosely coupled
component has minimal impact on other parts of the system,
reducing the risk of introducing bugs or unintended consequences.
3. Better testability: Loosely coupled components are easier to
isolate and test independently, enabling more comprehensive unit
testing and easier integration testing.

Example of Loose Coupling in Kotlin:


To achieve loose coupling, we can introduce abstraction and
dependency injection. Let’s refactor the previous example to
demonstrate loose coupling using interfaces and dependency
injection:

interface PaymentGateway {
fun authenticate()
fun processPayment(amount: Double)
fun sendConfirmation()
}
class PayPalGateway: PaymentGateway {
// Implementation of PayPalGateway
}
class PaymentProcessor(private val paymentGateway: PaymentGateway) {
fun processPayment(amount: Double) {
paymentGateway.authenticate()
paymentGateway.processPayment(amount)
paymentGateway.sendConfirmation()
}
}

In this refactored code, the `PaymentProcessor` class now depends


on the `PaymentGateway` interface rather than a specific
implementation. The actual implementation is provided through
dependency injection when creating an instance of the
`PaymentProcessor` class. This decoupling allows us to switch the
payment gateway implementation by simply providing a different
implementation of the `PaymentGateway` interface, without
modifying the `PaymentProcessor` class.

Conclusion:
Understanding the concepts of tight coupling and loose coupling is
essential for building flexible and maintainable software systems.
Tight coupling introduces strong dependencies between
components, making changes and testing challenging. On the other
hand, loose coupling promotes independent development, easier
modifications, and better testability. By utilising abstraction and
dependency injection, we can achieve

loose coupling in our code, enabling more flexible and robust


systems.
By adopting loose coupling principles, such as dependency injection
and interfaces, developers can build software that is easier to
maintain, test, and evolve over time, ultimately leading to more
reliable and adaptable applications.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy