ISSUES, CHALLENGES AND OPPORTUNITIES FOR RESEARCH IN

SOFTWARE ENGINEERING
Manish K Anand
International Institute of Information Technology,
Hyderabad, India
manish@students.iiit.net

Vasudeva Varma
Assistant Professor, International Institute of Information
Technology, Hyderabad, India
vv@iiit.net

ABSTRACT
The impact and importance of software has come a long
way. And yet, a new generation of software developers
must meet many of the same challenges that faced earlier
generations. This paper aims to identify some of the most
fundamental issues, challenges and opportunities for
research in Software Engineering. The paper starts by
examining the past, current, and future states of software
engineering. The paper then examines the critical
technical issues in software engineering including
complexity, structure, and evolution of software systems;
economics of software engineering, and measurement of
software engineering products and processes, as well as
the critical people and organizational issues including
learning, motivation and performance improvement.
This result can serve as a repository of valuable
information for the people who are aspiring to do
research in this discipline. This will be valuable aid for
many future researcher and academicians of software
engineering.
KEY WORDS
Software complexity, economics, measurement, people-
related issues, organization issues, process improvement
I. 1 INTRODUCTION
Though a substantial body of knowledge exists in
Software Engineering, a large number of issues are still
open or in need of further research. One of the most
important issues confronting software engineering
research is the identification of fundamental issues,
challenges and opportunities for research in the discipline.
These must be identified and better understood if we are
to significantly improve our practice of software
engineering.
At the dawn of the new millennium, software managers
face a particularly difficult set of challenges. More than
ever before, organizations depend upon computer
software for their competitive survival. Large, complex,
and inter-networked software systems play a critical role
in many aspects of organizations value chains. Users
need software that can meet stringent requirements, can
be produced quickly and productively, and can be easily
maintained to keep pace with an ever-increasing demand
for functionality, quality, and cost-effectiveness. The rise
of the World Wide Web and electronic commerce have
intensified the challenges of software development by
dramatically shortening product development cycles and
elevating time to market as a critical dimension of
software development performance.
Managers and decision makers envision software systems
developed with high quality, within budget, and without
delays. Despite pressures for increased productivity,
quality and timeliness, and the introduction of major
software process innovations, many software projects
continue to experience significant schedule delays, cost
overruns, and quality problems.
Why is it so difficult to develop and maintain software
systems? What are the major challenges and
opportunities for research on software engineering? The
paper explores the fundamental issues associated with
developing software and with managing software
development.
I.2 CONTRIBUTION OF THE PAPER
The paper has addressed one of the most important issues
confronting software engineering research- identification
of fundamental issues, challenges and opportunities for
research in the discipline. The results will help individuals
and organizations to better understand the challenges
posed by this discipline.
This result can serve as a repository of valuable
information for the people who are aspiring to do research
in this discipline. The results will also provide guideline
for the students to know which area to concentrate for
making huge difference to this discipline. This is for the
first time that such an intensive and exhaustive analysis
has been done in this respect. This will be valuable aid for
many future researcher and academicians of software
engineering.
II. METHODOLOGY
1. Six Broad Categories Identified
First of all, the broad categories affecting software
engineering were identified. Six broad categories were
identified to examine the critical technical as well as the
critical people and organizational issues.
1. Software Engineering: Past, Present and Future
2. The Complexity, Structure, and Evolution of
Software Systems
3. The Economics of Software Engineering
4. The Measurement of Software Engineering
Products and Processes
5. Learning and Improvement in Software
Engineering: Individual and Organizational
Perspectives
6. People-Related Issues in Software Engineering
2. Papers and Chapters Identified
In order to be acquainted with these six broad areas and
concern related to them, various papers and chapters of
the books were identified to provide potential research
ideas and concerns. The best papers published in these
categories were studied and the research issues,
challenges and opportunities in these respective categories
identified.
3. Reading and Answering Key Questions
Now, the task was to read those papers category wise and
to answer key questions. The questions were also
identified to make sure that the potential issues;
challenges and research aspects mentioned in the paper
are understood and mined.
4. Guidelines for Reviewing Papers
When reviewing a research paper, each of the following
questions was addressed:
i. What is the research question? What is the problem
in the real world? Who cares? Why is it important
from a practical and theoretical perspective?
ii. What work have others done on this question? What
aspects of the question have been addressed by prior
work, what aspects have not been addressed?
iii. What theory or theories do the authors to understand
their research question use? What are the strengths
and weaknesses of the authors theoretical
development?
iv. What methodological approach do the authors use?
What are the strengths and weaknesses of the
authors method?
v. What are the results? Why are they important?
vi. How does the authors work contribute to the
research on software engineering?
vii. What suggestions would you provide to the authors
for improving their work?
viii. What are the possibilities for future research based
upon the authors work?
5. Identification of Research Questions
After completing each section papers some potential
concerns and research questions were identified and
answered.
Rather than using a survey method for identifying such
opportunities, the project studies the large pool of
knowledge- spread across different published papers,
books and journals- available in the discipline of Software
Engineering to identify those opportunities.
1. SOFTWARE ENGINEERING: PAST,
PRESENT AND FUTURE
1.1 Problems in the Past
In the past software development faced the problems of
planning, organizing, staffing, coordinating, budgeting
and directing the software development activities. The
systems were batch processing and so the programmer has
to wait for a long time for the program to compile and
execute. Also, most of the projects used to run over
budget and behind schedule. Most of the times, the
problem requirements were not properly understood.
There was a lack of proper design and analysis tools
available for project evaluation at every stage. The major
problems were in the spheres of error detection, defect
management, data abstraction, etc
Most of the big past gains in software productivity have
come from handling accidental difficulties (severe
hardware constraints, awkward programming languages,
lack of machine time) [1].
1.2 Critical Problems Today
An engineering approach to the development of computer
software is now a conventional wisdom. Although the
debate continues on the right paradigm, the degree of
automation, and the most effective methods, the
underlying principles of software engineering are now
accepted throughout industry. Even though most of us
appreciate the need for an engineering discipline for
software, we struggle against the inertia of past practice
and face new application domains that appear ready to
repeat mistakes of the past. Now, there is an inability to
predict service behavior.
1.3 Critical Issues in the Future
In the future, developing large-scale systems will still be a
problem. Systems development will become a process
within which needs are formulated and then potential
solutions are then selected from a large solution space.
The legacy problem is likely to get worse when software
consists of diverse components obtained from many
different sources. Continual product churn and planned
obsolescence may lead to a lack of confidence in the
software industry- and a resulting lack of investment by
potential users. Software should meet necessary and
sufficient requirements, should be personalized, self
adapting, fine grained, should operate transparently. End
users should develop it, will be component based.
1.4 Difficulty in Developing Software
The demand for functionality, quality, flexibility and cost
effectiveness keep on increasing with time and hence
these factors have made it difficult to develop software.
Also, in spite of the fact that the software development
life cycle has been identified; there is also a need of
personnel and team software planning. A lack of
coordination between the team members may also result
in a failure of the product either in meeting the
specifications or in the market. Training, maintaining
conceptual integrity and communication paths are major
overheads associated in overcoming these difficulties in
developing software.
1.5 Improving Software Development
To improve the software development we need to address
essential parts like the one mentioned above (complexity,
conformity, changeability, and invisibility) at the same
time accidental problems like syntactic errors and
semantic error are to be addressed so as to develop
software effectively in time [1].
The users must be categorized on many different axes
including: Economic grouping (such as low- and high-
spending); Type (such as individual, family, and
international); Use type (such as military, entertainment,
social, and commercial); Use Level (such as frequent and
infrequent and minimal and full functionality); and Ability
(such as level of expertise and expertise and physical
limitations) [2].
1.6 Improvement in Ability to Create
Software
Our ability to create software improved satisfactorily
because of applying principles like iterative development
of software getting a prototype in each iteration with the
final product in the last iteration, UML is being used to
visualize software process. Anyhow still a lot has to be
developed so as to ensure safe production of software.
1.7 Issues, Challenges and Opportunities
In the future there would be more number of people
working on software development, as the dependence of
society on software would maintain upswing. Experience
indicates that, as the number of people on the software
team increases, the overall productivity of the group may
suffer. One way around this problem is to create a number
of software engineering teams, thereby
compartmentalizing people into individual working
groups.
However as the number of teams grow, communication
between them becomes very difficult and time consuming
and inefficient.
i. In the future there will be a shift in control of service
development from software centers to customer and
user sites.
ii. Also, there will be a change in working practices
within development and customer sites involving
greater globalization of development teams.
iii. There will be a change from one view of quality to
many different views, each taking a different
approach to evaluation.
iv. There will be a change from an inability to predict
service behavior to managing complexity.
There is a need for a long-term software development
research agenda, which will help, meet the societys
future needs for software that is reliable, adaptable,
available and reasonably priced [2].
2. THE COMPLEXITY, STRUCTURE,
AND EVOLUTION OF SOFTWARE
SYSTEMS
2.1 Definition of Software Complexity
Software complexity is defined in IEEE Standard 729-
1983 as: "The degree of complication of a system or
system component, determined by such factors as the
number and intricacy of interfaces, the number and
intricacy of conditional branches, the degree of nesting,
the types of data structures, and other system
characteristics." Software complexity is a link between
development practices and software maintenance
performance. High software costs and huge time spent in
testing and maintenance of the software makes the
software complex and makes it difficult to maintain and
modify the software.
Software complexity is aimed to objectively associate a
number with a program, based on the degree of presence
or absence of certain characteristics of software. It is
assumed that software complexity is related with such
features of software like number of errors left in the
software, effort to design, test or maintain a software
product, development time, maintenance cost, etc.
2.2 Importance of Software Complexity
Knowing the complexity of a specific software product or
its module enables one to:
i. Predict the cost of testing, maintenance, etc., number
of errors left in the software, size of the final
program;
ii. Assess the development time, effort, cost, etc;
iii. Identify critical modules or parts of the software;
iv. Compare programs, modules, programmers, etc.
according to software complexity.
2.3 Management of Software Complexity
Modularizing the system is the most effective way of
managing the complexity of the software. Besides, Flow
graphs and structure graphs can be used to manage
software complexity. Both in the design phase and the
implementation phase, modularization has to be stressed.
A module should not consist of one or more subroutines
but instead allow subroutines and programs to be
assembled collections of code from various modules [3].
2.4 Trade-Offs of Software Complexity
Management of software complexity is associated with
the following trade-offs:
i. Rising Cost Of Software complexity
ii. Increased manpower in the software field due to
increased software complexity
iii. Instability creeps out in the system due to increased
complexity
iv. Increase in development time, maintenance, high cost
2.5 Engineering of Software Systems
It is now well known that software system should be
engineered for software development is not a self-
development process. Software development depends
upon various features such as Volatility, Software
Structure, Complexity and Enhancement. Engineering the
systems will provide us with an estimate of the costs and
development time and helps in planning.
2.6 Issues, Challenges and Opportunities
Software complexity is one branch of software metrics
that is focused on direct measurement of software
attributes, as opposed to indirect software measures such
as project milestone status and reported system failures
[4]. Complexity measures can be used to predict critical
information about reliability and maintainability of
software systems from automatic analysis of the source
code. Complexity measures also provide continuous
feedback during a software project to help control the
development process. During testing and maintenance,
they provide detailed information about software modules
to help pinpoint areas of potential instability.
It is suggested that the researchers must find ways to
control the effects of non-program factors, perhaps by
restricting their focus to a well-defined programming
environment. Further, both the designers and users of
complexity measures must be aware of the inherent
limitations of such tools [5].
3. THE ECONOMICS OF SOFTWARE
ENGINEERING
3.1 Software Production-Expensive
It is often expensive to produce software because of the
following factors:
i. Highly skilled labor is required
ii. Highly developed technology is needed
iii. High maintenance cost
iv. High debugging cost
3.2 Ways to Reduce Software Cost
Software cost can be reduced by development and use of
models for cost estimation. Also it can be reduced by
estimating the cost and benefits of investments in
reducing controllable complexity and in promoting initial
software quality. Software must be reused when possible.
Software can be customized so that they can serve the
needs of all people within the group. In doing so, support
and maintenance costs can be reduced, and users can be
benefited from having ready access to others who are
using the same software.
3.3 Is Software Quality Free?
Software Quality is not free. If it were then no developer
will be interested in developing this at all. Software
quality should be taken utmost care otherwise low quality
software will lead effectiveness of software in every
aspect to go low [6].
3.4 Costs of Software Quality
It is generally accepted that the costs of poor quality and
poor quality management are much easier to identify and
quantify than some of the benefits, particularly as quality
management system implementation and software
development methods tend to evolve within suppliers'
organizations and customers rarely have appropriate
benchmarks for comparison.
3.5 Benefits of Software Quality
The benefits of using a quality management system lie in
the opportunities it provides for continual improvement,
which result in improved product quality and
repeatability, increased process efficiencies, a reduction in
failure costs, increased employee satisfaction and lower
staff turnover [7]. Evaluation of benefits and cost should
be done on basis of: Prevention cost, Appraisal cost,
internal failure cost, External failure cost and Total cost of
quality [8].
3.6 Costs of Software Failure
Costs of correcting defects, both before and after delivery,
Cost of overruns against time and budget. Unnecessarily
high maintenance costs, indirect costs associated with a
frustrated workforce, Indirect costs that users incur due to
poor quality software (such as loss of business due to poor
reputation).
Surveys conducted in the late '80s indicated that, for
companies without a quality management system, the
failure costs could be in the region of 20% of turnover.
These same surveys also suggested that, with the
repeatability and consistency that resulted from having a
well-tuned quality management system, up to 50% of
these costs could be saved [9].
3.7 Importance of Understanding Economics
of Software Engineering
It is important to understand the economics of software
engineering so that software cost can be reduced. The
understanding of this will lead to time management,
increased efficiency and low maintenance cost.
3.8 Issues, Challenges and Opportunities
Software engineering focuses on the production of
software, which is by its very nature a relatively
intangible good. Objectifying and measuring its many
dimensions are often challenging to researchers. Even in
situations where we have relatively good software related
artifacts to examine, there may be little evidence to
examine concerning the process by which they were
constructed.
Researchers should be clear about the fundamental ideas
within any new technology- technology innovators need
to be explicit about why the new technology is believed to
work and evaluation research should be pegged to these
fundamental ideas, rather than the surface nomenclature.
How can organizations that wish to adopt new
technologies best structure themselves to provide an
environment for individuals with scarce skills that will
always be in high demand? What lessons can be drawn
from the economics contracting literature that would aid
these organizations.
4. THE MEASUREMENT OF SOFTWARE
ENGINEERING PRODUCTS AND
PROCESSES
4.1 Importance of Measurement
It is important to measure in software engineering because
if we dont measure, judgment can be based only on
subjective evaluation. With measurements, trends (either
good or bad) can be spotted, better and estimates can be
made and true improvement can be accomplished over
time.
4.2 Aspects/Dimensions to be measured
Software engineering encompasses two major functions
of planning and control, both of which require the
capability to accurately and reliably measure the software
being developed. The various aspects or dimensions of
s/w engineering, which required to be measured, include
estimation of appropriate budgets and schedules. These
come under planning. Control of software includes
measuring progress on the project and performing after
the fact evaluation of the project e.g. measure the
effectiveness of the tools and techniques employed on the
project to improve productivity.
4.3 Definitions and Evaluation of Software
Engineering Measures
A software engineer collects measures and develops
metrics so that indicators will be obtained. An indicator is
a metric or combination of metrics that provide insight
into the software process, a software project or the
product it. An indicator provides insight that enables the
project manager or software engineers to adjust the
process, the project or the process to make the things
better [10].
4.4 How to Know a Good Software Measure
We know that a software measure is good if:
i. There is correct estimation of budgets and schedules
ii. Good control over progress of software development.
iii. Accurate measures of the complexity-adjusted size of
the deliverables of a software project early in the
lifecycle. This will permit the estimation of the
relationships between the deliverables and the cost
and time required to produce the software.
4.5 Issues, Challenges and Opportunities
There are many challenges and opportunities in research
on measurement in Software engineering as the formal
framework for these measures have yet to be defined
clearly. With a formal framework comes the challenge for
framing the properties for these metrics? Also issues
related to the suitability of such metrics and their use in
various situations would have to be looked into.
Some of the current issues in research in software
measurement are as follows: [10]
i. Too much focus on software as a vehicle, not as the
focus itself
ii. Lack of commitment to careful concept evaluation
iii. Too little empirical validation/ evaluation
iv. Ineffective technology insertion into real world
v. Less attention towards collection of automated data
for FP analysis
5. LEARNING AND IMPROVEMENT IN
SOFTWARE ENGINEERING:
INDIVIDUAL AND ORGANIZATIONAL
PERSPECTIVES
5.1 Difficulty for Individuals in Learning
It is often difficult for individuals to learn in software
engineering. Lack of understanding of ones cognitive
processes during development of software can be major
source of difficulty for an individual to learn in software
engineering. Knowing any process well is certainly
beneficial from the point of view of optimization. The
present research views the programming process similar
to the process of search. At individual level, performing
more systematic searches in all the three domains will
certainly be very helpful [11].
Other reasons could be either of these: high complexity of
technologies, software process innovations, knowledge
barrier, not having prior related knowledge, complexity of
software matrices, and volatility of software system or
difficult software structure analysis [12].
5.2 Improving Individual Ability to Learn
Software engineers can increase their ability to learn,
improve and innovate through:
i. Awareness: Software engineers can be more aware
of the surroundings and the knowledge of related
complex technologies should be updated from time to
time.
ii. Interest: Software engineers should have keen
interest in the complex technologies and Software
Process Innovations that are going to be in the
organization. He should actively ask questions and be
a one of the active members of the learning group.
iii. Evaluations/ Trials: Organizations should arrange
various workshops and seminars to make user
comfortable with the
iv. Commitment: User should be very much committed
to learn the technologies and SPI.
5.3 Difficulty for Organization in Learning
When complex organizational technologies are first
introduced, the distance of learning is likely to be
considerable for most organizations. In the case of
software process innovations there are various factors
affecting the organizational to learn in the software
engineering. Successful assimilation requires learning on
a number of fronts such as:
i. Including grasping the abstract principles on which
the technology is based; understanding the nature of
the benefits attributable to the technology;
ii. Grasping specific technical features of different
commercially available instances of the technology;
iii. Discerning the kinds of problems to which the
technology is best applied;
iv. Acquiring individual skills and knowledge needed
produce a sound technical product on particular
development projects;
v. Designing appropriate organizational changes in
terms of the team structure, hiring, training, and
incentives.
It is hard to overstate how difficult and expensive this
learning process can be.
5.4 Improving Organizational Ability to
Learn
Software engineering provides detailed step-by-step paths
that if followed by the organizations help them in
increasing their ability to learn improve and innovate.
Organizations with a higher propensity to innovate with
complex technologies will be those for which
organizational learning is relatively less burdensome,
because: (1) they can better amortize the costs of learning,
(2) they can acquire any given amount of new knowledge
with less effort, or (3) they have less to learn overall.
Ease of organizational learning follows from ease of
individual learning, because while it has been argued that
individual learning is not always sufficient for
organizational learning, it is certainly necessary.
It is therefore proposed that organizations with greater
learning-related scale, related knowledge, and diversity
are more likely to initiate and sustain the assimilation of
complex technologies.
5.5 Issues, Challenges and Opportunities
There are many issues, challenges, and opportunities in
research on individual and organizational learning in
software engineering. Organization and individual should
learn collectively so as to really implement the
innovations and complex technologies in the organization.
User should have knowledge of related technologies and
company should slowly and slowly bridge the gap ok
knowledge barrier. The main implication of this
research for end-user organizations is that they would be
well advised to view SPI assimilation as a multi-year
process of organizational learning, and to carefully assess
the extent to which they fit the profile of an early and
sustained assimilator.
6. PEOPLE-RELATED ISSUES IN
SOFTWARE ENGINEERING
6.1 Reasons for Extreme Variances in
Individual Performance
The capabilities of individuals strongly influence the
software engineering process as a whole. Capabilities
include experience, intelligence, and familiarity with the
application domain, ability to communicate with others,
ability to envision the problem spatially, and ability to
verbally describe that spatial understanding [13].
6.2 Ways to Improve Individual Software
Engineers
The performance of individual software engineers can be
improved by giving proper guidelines, teaching soft skills,
bettering them in personal software process and team
software process which are used for disciplined software
development processes at both individual and team levels.
6.3 Difficulty in Creating Software Using
Project Teams
Often it is difficult to create software using project teams.
Creating a winning software team requires more than
balancing commitments and resources. Most teams that
sustain a winning tradition over many years and many
changes in players do so because they excel at attracting,
developing, organizing, motivating, and retaining talent.
Some of the other prominent reasons are- poor interaction
between members, loss of identity, not knowing what each
member is there for, pathological urges to meet up, time-
zone trouble, Cultural factors and technology
incompatibility.
6.4 Solution to these Problems
For all these problems there are two categories of
solution. One is to deploy the "hard" technologies of
communication, from e-mail to videoconferencing. The
other solution is deploying "soft" technologies, from a
"meeting-the-team" start-up workshop to kick-off bonding
and circulating a directory of team members and their
skills to immersion courses in language training or
translating documentation. And finally, "the project leader
should know when people's birthdays are and celebrate
them, even if only virtually.
6.5 Critical Performance Issues
The critical performance issues that are salient for
software project are schedule, budget, meeting the users
requirements, efficiency of developers work, identifying
buggy code, coding standards and testing guidelines.
6.6 Glut of Software Professionals
There are positive as well as negative impacts as a result
of glut in software professionals. It is a demoralizing sight
for professionals that they are just one among millions.
Many may leave the software industry. But on the other
side, Competition increases which can possibly let to the
working hard of each individual to survive & to prove
their worth and it can be motivating as well, which leads
to increased performance.
6.7 Issues, Challenges and Opportunities
Some of the common people related mistakes that could
be studied are undermined motivation, weak personnel,
uncontrolled problem employees, heroics, adding people
to a late project, noisy and crowded offices, friction
between developers and customers, unrealistic
expectations, lack of effective project sponsorship, lack of
stakeholder buy-in, lack of user input, politics placed over
substance, and many more. It could be taken as a
challenge to build an ideal Software Engineering Process
Group based on the studies by researchers who have this
opportunity at hand in this regard to pursue research in
this area and come up with some methodologies that
would eventually be able to address many people related
issues of software engineering. An SEPG is a group of
internal consultants established to help their colleague
software engineers and managers improve. A good SEPG
is a solution to many common people related problems in
software engineering.
III. CONCLUSION
All software construction involves essential tasks, the
fashioning of complex conceptual structures that compose
the abstract software entity, and accidental tasks, the
representation of these abstract entities in programming
languages and the mapping of these onto machine
languages with in space and speed constraints.
High-level languages, Time-sharing, Unified
Programming Environments, Object-oriented
programming, Artificial intelligence, Expert systems,
Workstations, Environments and tools are some of the
breakthroughs that solved the accidental difficulties [1].
Some of the challenges for Software Engineering in the
future will be Legacy (proper maintenance of the software
in cost effective manner), Heterogeneity (to build
dependable software which is flexible to cope with
heterogeneity of distributed systems on network) and
Delivery (to deliver the large and complex with in time
with out compromising on quality)
The radical view of the future of software seeks to bridge
the gap between technology and society. Also, software
will be component based and thus components will be
customizable and flexible. Enormous potential will be
there for visualization and virtual reality technology,
which will provide powerful assistance [2].
Empirical studies to improve problem understanding; user
interaction and usability; self-fixing and self-adapting
software; reflective software; multi skilled geographically
distributed development and interdependence among
design, business and evaluation are some of the
possibilities for future research [2].
Raymond describes that it is great to get ideas from
users... i.e., he mean that it is good to have original own
ideas. However, it is equally as good or even better to
recognize good ones your users come with. If you like an
idea you came up with or were suggested to you - make
sure you implement it in a future release. " Perfection (in
design) is achieved not when there is nothing more to add,
but rather when there is nothing more to take away " [14].
Software seems to be flexible and malleable but this is not
true. In reality, the limits exist and are related to the
limitations in human abilities. In reality, the limits exist
but are simply less obvious and more related to
limitations in human abilities than limitations in the
physical world [15].
Large-scale software systems have been commonplace
today and hence there is a need to decouple systems into
modules with minimal interaction between them.
Modularity results in managerial, flexible and
comprehensible systems. While the need for
modularization has been accepted, little has been done to
actually design the criteria for decoupling a system into
modules [3].
Software complexity poses a big challenge in the design
of software systems. Development of programming
methodologies, design methodologies, requirements
engineering and development of description are issues in
the research on software complexity. The major challenge
is to reduce the complexity to its minimum level and still
not miss out with any of the requirements of the software.
The software complexity is a very opportunistic and open
domain of research. This is because even a small
reduction in software complexity through some way can
bring about a lot of change in the software arena [9].
The importance of the structure, volatility and complexity
comes in the maintenance stage since most of the costs
associated with the design, development, implementation,
and operation of computer-based applications occur in
software maintenance. Software maintenance is the
modification of a software product after delivery to
correct faults, to improve performance or other attributes,
and to enhance the product by adapting it to a modified
environment. It was highlighted that both the dynamic
nature of software and the significant cost incurred to
adapt, enhance, and upgrade it. As the costs of software
maintenance soar, improved techniques for controlling
and reducing maintenance effort become imperative. [4].

The number and complexity of applications for software
have grown very rapidly, fueled, in large measure, by the
dramatic improvements in hardware technology. As
hardware decreases in size and increases in performance
per dollar, more applications can be justified. This then
creates demand for software. This tremendous demand for
software has fueled the fortunes of many software
developers and their organizations. Also it provides
significant challenges to researchers as they attempt to
assess progress in the delivery of software [16].
The problems in the software development world are
uncontrollable costs, missed schedules, and unpredictable
quality. To remain competitive, software firms must
deliver high quality products on time and within budget.
There is confusion about the business value of quality
control measures. People, even though want quality
software are not will to put in more quality control
measures because of the increase in software life cycles
[7].
Software can be customized so that they can serve the
needs of all people within the group. In doing so, support
& maintenance costs can be reduced, and users can be
benefited from having ready access to others who are
using the same software [6].
There are many challenges and opportunities in research
on measurement in Software engineering as the formal
framework for the measurement of various parameters of
software project have yet to be defined clearly. With a
formal framework comes the challenge for framing the
properties for these metrics? Also issues related to the
suitability of such metrics and their use in various
situations would have to be looked into [12].
Some of the common people related mistakes that could
be studied are undermined motivation, weak personnel,
uncontrolled problem employees, heroics, adding people
to a late project, noisy and crowded offices, friction
between developers and customers, unrealistic
expectations, lack of effective project sponsorship, lack of
stakeholder buy-in, lack of user input, politics placed over
substance, and many more [17].
Other disciplines have explored the research problems
that software engineering researchers deem to be unique.
As the software engineering field matures, so will the
research methods. Software engineers will turn to the
social scientist and organization behaviorist to borrow
research methods that are relevant to their empirical
research studies.
The impact and importance of software has come a long
way. And yet, a new generation of software developers
must meet many of the same challenges that faced earlier
generations. Let us hope that the people who meet the
challenge-software-engineers-will have the wisdom to
develop systems that improve the human condition.
IV. REFERENCES
[1] Brooks, F. P. The mythical man month: essays on
software engineering, Chapters 16-17,
Anniversary Edition, Prentice-Hall, 1995,
pp.179-226
[2] Brereton, P. et al. "The future of software,"
Communications of the ACM, December 1999,
42(12), pp. 78-84.
[3] Parnas, D.L., On the criteria to be used in
decomposing systems into modules,
Communications of the ACM, 15(12), December
1972, pp. 1053-8.
[4] Banker, R. and S. Slaughter, The moderating
effects of structure on volatility and complexity
in software enhancement, Information Systems
Research, September 2000.
[5] Kemerer, C. and S. Slaughter, An empirical
approach to studying software evolution, IEEE
Transactions on Software Engineering, 25(4),
July/August 1999, pp. 493-509.
[6] Banker, R. Davis, G. and S. Slaughter, Software
development practices, software complexity and
software maintenance performance: A field
study, Management Science, 44(4), April 1998,
pp. 433-450.
[7] Slaughter, S., Harter, D., and M. Krishnan,
Evaluating the cost of software quality,
Communications of the ACM, 41(8), August
1998, pp. 67-73.
[8] Kemerer, C. "Progress, obstacles and
opportunities in software engineering
economics," Communications of the ACM,
August 1998, 41(8), pp. 63-66.
[9] Harter, D., Krishnan, M. and S. Slaughter,
Effect of process maturity on quality, cycle
time, and effort in software product
development, Management Science, 46(4), April
2000, pp. 451-466.
[10] Kemerer, C. Reliability of function points
measurement: A field experiment,
Communications of the ACM, 36(2), February
1993, pp. 85-97
[11] Kim, J. & Lerch, J. "Why is programming
(sometimes) so difficult? Programming as
scientific discovery in multiple problem spaces,"
Information Systems Research, 8(1), 1997, pp.
25-50.
[12] Fichman, R. and C. Kemerer, The assimilation
of software process innovations: An
organizational learning perspective,
Management Science, 43(10), October 1997, pp.
1345-1363.
[13] Brooks, F. P. The mythical man month: essays on
software engineering, Chapters 1-3, Anniversary
Edition, Prentice-Hall, 1995, pp. 3-40.
[14] Raymond, E., "The cathedral and the bazaar,"
http://www.tuxedo.org/~esr/writings/cathedral-
bazaar/cathedral-bazaar/

[15] Leveson, N. "Software engineering: stretching
the limits of complexity," Communications of the
ACM, February 1997, 40(2), pp. 129-131.
[16] Weyuker, E., Evaluating software complexity
measures, IEEE Transactions on Software
Engineering, 14(9), September 1988, pp. 1357-
1366.
[17] Kraut, R. and L. Streeter, Coordination in
software development, Communications of the
ACM, March 1995, 38(3), pp. 69ff.
This document was created with Win2PDF available at http://www.daneprairie.com.
The unregistered version of Win2PDF is for evaluation or non-commercial use only.