Issues, Challenges and Opportunities for Research in Software Engineering by Manish K Anand, Vasudeva Varma
in Accepted for presentation at IASTED International Conference on Software Engineering and Applications (SEA 2004), November 09-1, 2004, MIT Cambridge, USA.
Report No: IIIT/TR/2008/60
Centre for Software Engineering Research Lab International Institute of Information Technology Hyderabad - 500 032, INDIA June 2008
ISSUES, CHALLENGES AND OPPORTUNITIES FOR RESEARCH IN SOFTWARE ENGINEERING Manish K Anand International Institute of Information Technology, Hyderabad, India
[email protected]
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, peoplerelated issues, organization issues, process improvement
Vasudeva Varma Assistant Professor, International Institute of Information Technology, Hyderabad, India
[email protected]
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 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
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
v. vi.
1. Six Broad Categories Identified
vii.
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
viii.
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.
ii.
iii.
iv.
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? 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? What theory or theories do the authors to understand their research question use? What are the strengths and weaknesses of the authors’ theoretical development? What methodological approach do the authors use? What are the strengths and weaknesses of the authors’ method?
What are the results? Why are they important? How does the authors’ work contribute to the research on software engineering? What suggestions would you provide to the authors for improving their work? 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
1.7 Issues, Challenges and Opportunities
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.
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.
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.
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 society’s future needs for software that is reliable, adaptable, available and reasonably priced [2].
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].
2. THE COMPLEXITY, STRUCTURE, AND EVOLUTION OF SOFTWARE SYSTEMS
The users must be categorized on many different axes including: Economic grouping (such as low- and highspending); 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].
Software complexity is defined in IEEE Standard 7291983 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.
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.
2.1 Definition of Software Complexity
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 selfdevelopment 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.
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 don’t 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.
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.
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 i. ii. iii.
We know that a software measure is “good” if: There is correct estimation of budgets and schedules Good control over progress of software development. 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 one’s 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.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, timezone 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 6. PEOPLE-RELATED ISSUES SOFTWARE ENGINEERING
IN
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.
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/cathedralbazaar/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. 13571366. [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.
