Assignment 1

Aina Raziq
SE120182007
BSSE 8th A
SOFTWARE INTEGRATION ISSUES

The life of a software project usually involves the integration of new modules. Methods used to
integrate these new modules vary greatly but usually encounter many of the same problems.
Typical problems involve management of data, exchange of information and program flow
control.

Other challenges include:

Picking the right integration tool

There are many tools for software integration. Choosing one among them is a challenge. Today, a
software integration tool that supports hybrid integration is the most preferred.

Hybrid integration allows a local application to integrate with other cloud-based integrations. They
are preferred because developers may not want to go completely on the cloud for security and
privacy concerns.

Integrating with monolithic systems

Many enterprises have monolithic architecture systems. Therefore, it is not possible to do away
with those systems efficiently. Organizations heavily depend on monolithic systems, as they are
mostly legacy systems. Replacing these systems for the sake of integration is difficult. Thus, it
becomes a challenge.

Changes in the environment

Integrated software solutions are often not the same as before integration. Today, nothing stays the
same for a long period. Most integrated systems are designed to solve a particular problem.

Components and subsystems integrated may also not be well prepared for integration. Such
systems are unable to keep up with changes and become obsolete

ASPECT-ORIENTED SOFTWARE DEVELOPMENT (AOSD)

Aspect-oriented software development (AOSD) is a software design solution that helps address
the modularity issues that are not properly resolved by other software approaches, like
procedural, structured and object-oriented programming (OOP). AOSD complements, rather than
replaces, these other types of software approaches.

AOSD is also known as aspect-oriented programming (AOP).

AOSD features are as follows:

• Considered a subset of post-object programming technologies

• Better software design support through isolating application business logic from
supporting and secondary functions
• Provides complementary benefits and may be used with other agile processes and coding
standards
• Key focus - Identification, representation and specification of concerns, which also may
be cross-cutting
• Provides better modularization support of software designs, reducing software design,
development and maintenance costs
• Modularization principle based on involved functionalities and processes
• Because concerns are encapsulated into different modules, localization of crosscutting
concerns is better promoted and handled
• Provides tools and software coding techniques to ensure modular content support at the
source code level
• Promotes reusability of code used for the modularization of cross-cutting concerns
• Smaller code size, due to tackling cross cutting concerns
• Reduced efficiency from increased overhead

PROBLEM BENEFITS APPROACHES TO REUSE

Problems Of Software Reuse

• Maintenance cost increase

• Software tools require longer support
 • Software tools may become obsolete
• “Not invented here” attitude reduces acceptance
• Overhead of creating & maintaining a component library
• It takes time to select reusable software components.

Benefits Of Software Reuse

• Dependability & reliability may improve given previous testing and use
• Risk reduction as you avoid the elements of detailed software development
• Standards compliance accomplished with prior work
• Development time reduced by starting with blocks of reusable software
• Permits more resources for new functional elements of the system

Software Reusability Approaches

There are eleven software reusability approaches , which are design patterns,
component-based development, application frameworks, Legacy system wrapping,
Service-oriented systems, Application product lines, COTS integration, Program
libraries, Program generators, aspect-oriented software development and
configurable vertical applications.

1. Design patterns: In recent years, the influences of design patterns on the

quality of software have attracted the increase of attention in the area of
software development, design patterns encapsulate valuable information
to solve design problems and to enhance the quality of the design. Design
patterns are the amassed experiences by many programmers and
developers to solve software design problems. Design patterns have
proved as a significant piece that was needed from object -oriented design
approaches stated that, design pattern is a common reusable solution to a
commonly arising problem in software design, design pattern is a
description or pattern for how to solve a problem that can be adapted in
several different circumstances. Design pattern is a solution to the
problem of a specific case. Design pattern is a record and refining of
 effective solutions which can be frequently repeated and validated for the
system developers.
2. Component-based development: Component Based Software
Development (CBSD) is an emerging technology that emphases on
constructing systems by integrating existing software components. The
CBSD offers a range of benefits includes: Enhance efficiency, enhance
the ability to reuse components, managing growing complexity, reducing
the time and effort needed to develop software, decreasing production
costs through software reuse, enhancing the quality of the system,
reducing maintenance costs, ensuring a greater degree of consistency,
providing a wider variety of usability and supporting the effective use of
specialists and increasing development productivity . This is further
emphasized by who said, CBSD has become broadly accepted as a cost -
effective method to software development, as it ensure the construction
and design of software systems using reusable components. The CBD can
reduce developmental process costs and enhancing the reliability of
software system.
3. Application frameworks: Application frameworks are widely used in
order to boost efficiency and reliability in software de velopment. An
application framework is a reusable software product which delivers
reusable design and implementation common to applications of a specific
domain. Frameworks represents the core of software development reuse
methods, is the most proper solutions to simplify application
development and overcome their development problems, using
frameworks brings a many benefits to system development, enhancement
of overall software quality and reduces development time and efforts .
4. Legacy system wrapping: By wrapping a set of defining interfaces by
legacy systems offers access to interfaces. By rewriting a legacy system
from scratch can create equal functionality information system based on
modern software methods and hardware. Legacy systems that can be
 wrapped by defining a set of interfaces and providing access to these
legacy systems through these interfaces.
5. Service-oriented systems: In today’s rapidly changing environment it is
no longer possible for isolated systems to offer all the capabilities that
are necessary to fulfill a mission. Service-orientation delivers unique
benefits for heterogeneous and independently controlled systems
(Simanta et al., 2010). Service-oriented systems are possess of
distributable components using several technologies, working together to
accomplish a common goal.
6. Application product lines: Software Product Line (SPL) is a set of
software-intensive systems sharing a similar, managed set of features that
meet the particular needs of a specific market mission and that are
constructed from a similar set of essential assets. Software Product Line
(SPL) has proved very effective in developing large -scale software (Da
Silva et al., 2010). Software product line (SPL) is a set of software
systems which share a similar set of features and are constructed through
similar set of core resources in order to enhance the efficiency of the
product, reduce cost, time-to-market and boost software reusability, mass
customization (Mohabbati et al., 2011).
7. COTS integration: The software development world has rapidly evolved
in the last decade. In particular, the adapting of commercial off -the-shelf
(COTS) products as an essential elements of larger systems is becoming
sharply commonplace, due to accelerating rates of COTS enhancement,
shrinking budgets and expanding the requirement for systems. The term
COTS is very generic, it can refer to several different types and software
levels, for instance, software that is used as a tool to generate code
software that offers a specific functionality (Morisio et al., 2000).
8. Program libraries: No one can doubt the importance of a well-stocked
library of reliable routines to the successful of the practical computer
system. Libraries are written as programs and involved in function
literals, which are blocks that help as outer environments for other
 programs. Each library is conserved within some analyzer, which is a
result of continuation from semantic suspension of analysis sometime
modify the library itself has been analyzed. Some analyzer can be
continuously form a complete user system or private or public libraries.
(Wells et al., 1985). Program libraries considered at the top level of
automation. Program libraries allow building the element by particular
program according the specified commands
9. Program generators: Program generator is a program that allows an
individual to develop easily a program of their own with minimum
programming and effort knowledge. With a program generator a
developers may only be needed to state the phases or rules needed for his
or her program and do not need to write any code, a generator system
includes knowledge of a specific type of systems and can generate
programs or system fragments in that domain. Program generators
includes the reuse of algorithms and standard patterns (Jalender et al.,
2012). This is further emphasized by Singh et al. (2010) who contend that
generator program embeds knowledge of a specific types of application
and be able to generate programs or system fragments in that realm .
10. Aspect-oriented software development: In the last decade Aspect-
Oriented Software Development (AOSD) has gained a wide-range of
interest in both industry and academic institutions. The AOSD is an
advanced approach for separation of concerns, which offers candid to
modularize the crosscutting concerns and form it with the components of
the system.
11. Configurable vertical applications: Configurable vertical application is
a common system that is developed so that it can be configured to the
requirements of particular customers. Sample of a vertical application is
system that assists scientists manage their records, patient and insurance
billing (Jalender et al., 2012). Vertical application considers as a tool
which is concentrated on a narrow set of simulations (Ouyang et al.,
2009).
Software Types: S -Type, P –Type

S-Type software

S-Type software is one where specification is clear and detailed before the development even
begins. Thanks to this detailed specification, it is clear what the solution should be and
implementing it is trivial. But these kind of software are not interesting, as they are usually
already solved and implemented. So all it takes is to import a library or call a service.

P-Type software

P-Type software is one where specification exists, but it is high-level and not fully detailed. So
development needs to put effort into figuring out concrete solution. Also, but this might be just
me, there is distinct "done" milestone, after which development ceases. This is because in the
time of this division being formulated, there was no easy way to deliver updates to customers. So
it was paramount to get things right the first time. This is clear for games of the time. If you were
a game developer few decades back, game was "done" when it was put on disc and released. And
while it was possible to release updates, it would rarely find it's way to all your customers.

Metrics for Specification and Maintenance:

Metrics specification:
Following the development of system requirements, the software specifications document consists of a
definition of the software product. Each of the following phases of design, coding, and integration/testing
transforms the initial software specifications into lower levels of machine implementable details until the
final machine process able object code is generated. Therefore, the completeness, readability and accuracy
of the software specification directly influence the quality of the final software product. A waterfall
development model is not assumed. It is assumed however, that software specifications are kept "alive"
and relevant. The purpose of the article is to provide a methodology for deriving quantitative measures of
the quality of the software specifications document. These measures are designed to complement good
engineering judgment that has to be applied in order to judge the quality of a software specifications
document. Quantitative measures (i.e., metrics) will help reveal problem areas in various dimensions of
quality characteristics. We focus on completeness, readability and accuracy. The methodology presented
with real life examples.

Metrics Maintenance:
The leading indicator comprises from metrics like the Estimated vs. actual performance and PM
Compliance, while the lagging indicator are reflected in maintenance metrics like the Mean Time To
Repair (MTTR) , Overall Equipment Effectiveness OEE and Mean time between failure (MTBF).

Explanation:
Using these maintenance metrics and turning the data into actionable information, organizations can
acquire both qualitative and quantitative insights.
And there is no better way to spot opportunities for improvement.
Here are some important maintenance metrics you should track if you want to improve and optimize
maintenance operations.
Planned maintenance percentage (PPC):
This metrics represents the percentage of time spent on planned maintenance activities against the
unplanned.
In simpler terms, this metric tells you how much maintenance work done on a particular asset was a
part of your preventive maintenance plan versus how much time you’ve spent repairing it because it
unexpectedly broke down.
In a great system, 90% of the maintenance should be planned.
The calculation is as follows:
PPC= (scheduled maintenance time/total maintenance hours) x 100
Overall Equipment Effectiveness (OEE)
OEE is the measure of the productivity of a piece of equipment. It gives informed data on how
effective organization’s maintenance processes is running based on factors like equipment
quality, performance, and availability.
A 100% OEE means that your system is producing no defects, as fast as possible, and with no
stops in the production.
Understanding OEE and the underlying losses , organizations can gain significant insights into
how to improve their manufacturing processes. Using this metric, you can identify what
has a negative impact on your production, so you can eliminate it.
To calculate the OEE, you multiply the availability by the performance and quality :
OEE = availability x performance x quality
Mean time to repair (MTTR)
MTTR is the measure of the repairable items maintainability.
The MTTR clock starts ticking when the repairs start and it goes on until operations are restored. This
includes repair time, testing period, and return to the normal operating condition.
The goal of every organization is to reduce MTTR as much as possible. This is especially important for
critical assets as ever additional hour you need to restore an asset to a working condition amount to
huge losses for your firm.
To calculate MTTR, you divide the downtime period by the total number of downtimes:
MTTR= (SUM of downtime periods/ total number of repairs)
Mean time between failures (MTBF):
MTBF is the measure of the predicted time between one break down to the next during normal operation.
In essence, MTBF tells you the expected lifetime for a specific piece of equipment. Higher MTBF means
that the part (or product) you bought will work longer before it experiences failure.
If you know how long a specific part/equipment will last, it gets much easier to predict and prepare for a
failure or schedule some preventive work.
To calculate the MTBF, you divide the total operational time by the number of failures:
MTBF= (SUM of operational time/total number of failures)
Preventive maintenance compliance (PMC)
PM compliance is defined as the percentage of the preventive work scheduled and completed in a set
time.
For example, you might have 60 Work Orders (that are a part of the PM plan) scheduled but 51 completed
at the end of the month.
In this case:
PMC= (51/60) x 100 = 85%)
This tells you that 85% of all preventive WO’s have been covered for selected month.
The disadvantage of this metric is that it doesn’t tell you if the WO’s have been completed on time.
That is why you need to invest some additional effort and also track if the Work Orders are actually being
finished on time.
By the best way to do that is to use a CMMS as it allows you to quickly create, assign, and track all of your
WO’s from one place.