INTRODUCTION
1.1 Background
Software engineering aims to deal with the challenges of the software development process by
means of an engineering discipline. A characteristic of such is the availability of a catalog of
methods and practices plus guidelines for the systematic selection of these practices. The goal
is to deliver predictable quality, cost and time-to-market for the engineered product.
In software engineering a non-functional attribute which is often of high importance during
software development is the performance of the developed system. If systems suffer from
insufficient performance, they are usually not applicable and cause projects to fail. Therefore,
performance prediction of software systems is in the focus of research since the end of the
1990's [Zvegintzov 94]. The term performance often characterizes the timing behavior and
resource efficiency of hard- and software systems. The most important performance properties
are response time, throughput and resource utilization [McCall 00]. It aims at evaluating the
performance of (software) systems by following different methods like analytical modeling,
simulation, and taking measurements. The SPE's goal is to conduct performance evaluation of
software architectures as early as possible [Stroustrup 03].
Preliminary phase for most approaches in SPE is the system's software architecture [McCall
00] [Pigoski 03]. The architecture can be enhanced with performance annotations. This
software model must then be transformed into a performance model (e.g. Queuing Networks,
Petri Nets, Markov Chains) and solved for the metrics of interest. In the area of SPE, the idea
to use model-driven techniques gained attention because they provide automated
transformation from source to target performance model(s). However, model-driven
performance prediction methods require suitable meta-models like. These metamodels
formalize the syntax and semantics of the source and target model. The automatic
transformation and processing simplifies the software performance engineering approach and
makes it less error-prone.
Software systems square measure utilized in several important applications wherever a failure
will have serious consequences (loss of lives or property). Thus important applications have
the subsequent characteristics:
1
• The applications have long life cycles (decades instead of years) and need biological process
upgrades.
• The applications need continuous or nearly non-stop operation.
• The applications need interaction with hardware devices.
• The applications assign predominate importance to quality attributes like timeliness,
reliableness, safety, ability, etc.
Developing systematic ways in which to relate the software package quality attributes of a
system to the system’s design provides a sound basis for creating objective choices regarding
style tradeoffs and allows engineers to form fairly correct predictions a couple of system’s
attributes that square measure free from bias and hidden assumptions. The final word goal is
that the ability to quantitatively appraise and trade off multiple software package quality
attributes to attain an improved overall system.
The software evolution is inseparable by software maintainability which emphatically goes
worsening as time goes along and alters keep implemented. Due to the unpredictability of
modification happening and kind of faults, the range and price of software product
maintainability are indefinite later on software product existence delivered. However, it is
sensible to set a threshold as the quantitative standards of software product maintainability and
then to decide the health condition of a software product if there is a path to know the
potential rate of the software acquiring deteriorated.
Thirteen year later the term engineering was introduced, Connie Smith coined the term
Software Performance Engineering (SPE) in her seminal paper published in 1981. That paper
brought attention to the fact that software development was expressed out with the “fix-it-later
“attitude while it come to performance. In other word, performance was never a design
condition, but reconsideration. The reason how come performance in SPE is not yet redundant
is that twenty year later Smith’s introduction of the concept backside SPE, SPE has not yet
been integrated into the exercise of Software Engineering. Thus, it is still significant to talk
regarding SPE until the P of SPE turns redundant, i.e., until it actually mix into SE. Lack of
Scientific Principle and Model: Education: IT Workforce
2
In software quality model includes the measurement of the attribute of constancy,
analyzability, changeableness and testability as sub-characteristics of a software product. Each
sub-characteristic can be measured by order through many methods of metrics and each
method of metrics can be utilized to more than one sub-characteristics. Though Multiplication
Rule of Statistics, the indexes of all attributes can be multiplied to get a joint statistics of all
the properties mixed. Based on this, the Table 2 below gives a listing of metrics as each
attribute so as to measure the character of a completed software product, which is health
position of a completed software product on the time of delivery.
Software maintenance includes correcting discovered faults, adapting the system to changes in
the environment, and improving the system’s reliability and performance. These activities
result in system modifications that are distributed to customers as updates However, any
incorrect changes will cause software regressions—failures in already stable features and parts
of the system. Regressions are exceptionally painful for customers: imagine what will happen
if your computer suddenly stops working after you install an update. Below figure 1 shows the
different phases of software development from the top to bottom from the initial phases of
cycle and the relation of each stage to the other component in reverse order.
Fig 1: Software Development Cycle from the initial phase and relation of the different
component.
3
As the 21st century advances over five hundredth of the worldwide software package
population is engaged in modifying existing applications instead of writing new applications.
This truth by itself mustn't be a surprise, as a result of whenever software industry business
has over fifty years of product expertise the personnel who repair existing merchandise tend to
total the personnel who build new merchandise. For example there are more automobile
mechanics in the United States who repair automobiles than there are personnel employed in
building new automobiles.
At the end of the twentieth century software maintenance grew rapidly during 1997-2000
under the impact of two “mass updates” that between them are required modifications to about
85% of the world’s supply of existing software applications. The first of these mass updates
was the set of changes needed to support the new unified European currency or Euro that
rolled out in January of 1999. About 10% of the total volume of world software needed to be
updated in support of the Euro. However in the European Monetary Union, at least 50% of the
information systems required modification in support of the Euro.
The second mass-update to software applications was the “Y2K” or year 2000 problem. This
widely discussed problem was caused by the use of only two digits for storing calendar dates.
Thus the year 1998 would have been stored as 98. When the century ended, the use of 00 for
the year 2000 would violate normal sorting rules and hence cause many software applications
to fail or to produce incorrect results unless updated. The year 2000 problem affected as many
as 75% of the installed software applications operating throughout the world. Unlike the Euro,
the year 2000 problem also affected some embedded computers inside physical devices such
as medical instruments, telephone switching systems, oil wells, and electric generating plants.
Although these two problems were taken care of, the work required for handling them
triggered delays in other kinds of software projects and hence made software backlogs larger
than normal.
Under the double impact of the Euro conversion work and year 2000 repair work it is
appeared that more than 65% of the world’s professional software engineering population was
engaged in various maintenance and enhancement activities during 1999 and 2000. Although
the Euro and the Y2K problem are behind us, they are not the only mass-update problems that
we will face. For example it may be necessary to add one or more digits to U.S. telephone
4
numbers by about the year 2015. The UNIX calendar expires in the year 2038 and could
troublesome like the year 2000 problem. Even larger, it may be necessary to add at least one
digit to U.S. social security numbers by about the year 2050. The imbalance between software
development and maintenance is opening up new business opportunities for software
outsourcing groups. It is also generating a significant burst of research into tools and methods
for improving software maintenance performance.
1.2 Methodology
This thesis is based on the goal to provide emphasis on different aspect of software attribute to
provide best QoS to end use. The comparative result shown in this thesis is used to identify,
quantify, analyze and provide details analyze to the industries for handling different software
conflict emerging during building software for better performance and provide maintenance
thereafter to end users.
In order to achieve this different empirical study has performed on industrial cases, their
approach in building and maintaining software for better performance. This thesis is divided
into mainly two different parts where first show the software conflicts, their identification and
analysis. In the second part solution is proposed on the basis of this evaluation of the cases to
reduce the software conflicts.
To identify, quantify, analyze, and propose solutions for handling software design conflicts
emerging when building maintainable applications with explicit and high demands on
performance and availability. Our analysis suggests that there are common themes throughout
the findings and recommendations. These themes involve tools, people, and process. The
theme looks at technology issues related to the development of software; the people theme
deals with personnel issues such as training and communication; and the process theme deals
with issues such as contractor management, schedule pressures, passing on expertise, and
coding philosophies. These themes are elaborated below and represent our major findings and
recommendations.
The purpose of this report is to require a tiny low step within the direction of developing a
unifying approach for reasoning concerning multiple software package quality attributes. This
report examines the following four software quality attributes: performance, dependability,
5
security, and safety. Each attribute has matured (or is maturing) within its own community,
each with their own vernacular and point of view. We propose a generic taxonomy for
describing each attribute and attempt to use this taxonomy to
1.3 Aims and Objectives
Aim
This thesis aims to research maintenance activities within the context of package development
method models and their relevance and usage in observe. Which maintenance activities are
applied inside completely different contexts, what's the explanation for practitioners to pick
these and the way are these maintenance activities embedded inside the package development
method in order that ends up in improvement of performance from the past activities and it'll
be simply on the market to finish user?”
Objective
My analysis question consists of three elements; all coupled along however all with their own
boundaries relating to the general scope of my thesis. They have to be diminished to specify
wherever the boundaries are to create it manageable
Identify and justify what's underneath stood under the term maintenance with relevancy
package and confirm potential classes of maintenance, i.e. completely different schemata.
Supported that, establish and justify what activities, ways and techniques belong to
maintenance, their prices and efforts still because the responsibilities certainly maintenance
activities (roles). Tools were value-added providing they follow specific models or support
central activities. The edge is ready by the very fact that I’m not probing for the one and solely
truth of what maintenance is or ought to be except for potential alternatives however
maintenance are often approached. Identify and justify through case studies the structure
context and processes within which completely different maintenance models are applied, that
activities and techniques ar used and also the reasons why those are chosen by the various
organizations.
Identify and justify the method of enhancing the performance of package and confirm
potential classes of performance. Completely different activities, ways and techniques belong
6
to performance are mentioned with probable solutions. Explain through the various case
studies followed within the organizations whereas developing package and its maintenance.
To establish, quantify, analyze, and propose solutions for handling package style conflicts
rising once building reparable applications with express and high demands on performance
and convenience. As today’s systems become more and more dependent on package, the
problems close support become more and more complicated. The risks of ignoring these
problems will doubtless undermine the soundness, improvement, and longevity of fielded
systems.
This technical note discusses these queries and presents definitions, connected problems,
future issues, and suggestions for sustaining software-intensive systems. Support done well
ends up in well-supported software-intensive systems and reduced total possession prices and
may facilitate organizations meet current and new mission space and capabilities needs.
The info contained during this technical note relies on information that the package
Engineering Institute gathered throughout work with Air Force software-intensive systems.
Whereas the knowledge is pertinent and might be applied to systems within the industrial
sector, detain mind borderline effort was created to convert “DoDspeak” into industrial sector
language.
1.4 Structure of Thesis
Figure 2 provides a summary of this thesis and also the individual chapters. This chapter
bestowed AN introduction to the present thesis, providing the motivation, aims and objectives
and also the methodology applied. And remainder of the thesis structure as
Chapter 2 describes the analysis technique used for respondent the analysis queries.
Chapter 3 presents the background needed for understanding the analysis drained this thesis.
Chapter 4 describes the various existing knowledge model maintainability metrics that were
found within the literature and were designated for this analysis.
Chapter 5 presents the results of the research; it describes however the various knowledge
model quality metrics were applied to existing knowledge models.
7
Chapter 6 presents and interpretation of the results of all the ways, the strengths and
weaknesses of the ways also are reviewed.
Chapter 7 contains the conclusion and potential future work.
Fig 2: Overview of Thesis
8