Software Engineering

Some keywords: Component-based software engineering, Agile development processes, Global software development, Estimation methods, Software for mobile computing, Software process improvement and Empirical software engineering, Software engineering education and technology transfer.

Working groups: Software Engineering



Last edited: 14.12.2004, 14:00

Software Engineering

Views

Software Engineering

Description of the group

Software engineering is about technologies (concepts, principles, methods, techniques, tools etc.) that support development and maintenance of large software systems. It is a "sister" discipline of Information Systems, and has much overlap with Computer Science.

Software is increasingly constituting the basis for modern services and products. It can be embedded and invisible as in cars and phones, or appear as distributed service applications in netbanks and medical record systems. Our ability to develop and maintain large, complex software systems of desired functionality and quality is therefore crucial. In particular, quality functions such as security, safety, reliability, and usability are important.

Great strides have been made in software engineering technologies over the last 50 years. For instance, a modern PC at a price of 1000 Euros contains over 50 million code lines of software (e.g. Microsoft Office), and is perhaps the most complex artifact ever built by humans. Time-to-market often competes with traditional quality concerns, and Ericsson has adopted the slogan "sooner, better, cheaper" - in that order. Furthermore, the change rate of software can be very high, e.g. 1% monthly change in requirements. The combined challenge of software delivery schedule, cost, size, complexity, quality, and updated functionality poses a great challenge both in overall planning and in technical work.

We are not up to this software engineering challenge. This has been documented by many informal news reports, by recommendations such as the PITAC report [PITAC99], and by e.g. studies of overruns in Norwegian public software contracts [Moløkken04]. Our appetite for more advanced software functionality is simply outpacing the available software technology.

A long-term goal in Norway is to reduce our economic reliance on raw materials and half-fabricated goods (80% of the export volume) and to modernize and improve public services. In both cases, software and software technologies become crucial. Furthermore, the Norwegian ICT sector has annual revenues close to 200 bill. NOK with 90 000 employees, and is Norway's second largest industry after petroleum. So there is both an increasing need for high-quality software and a substantial industry with a growth potential to satisfy this need, given enough competent people. Prof. Manuel Castells at the University in Berkeley even claims that there is a clear connection between investment in software and economic growth.

We have identified a set of software engineering technologies, that have high societal importance and that will need considerable improvements in the next decade:

  1. Component-based software engineering (CBSE)
  2. Agile development processes
  3. Global software development (GSD)
  4. Estimation methods
  5. Software for mobile computing
  6. Software process improvement (SPI) and empirical software engineering
  7. Software engineering education and technology transfer
Note: Topics like communication technology, information systems, security and safety are described elsewhere.

Members of the working group

Professor Reidar Conradi, Department of Computer and Information Science
Professor Tor Stålhane, Department of Computer and Information Science
Professor Letizia Jaccheri, Department of Computer and Information Science
Assoc. professor Alf Inge Wang, Department of Computer and Information Science

Position paper

1. Component-based Software Engineering, CBSE

Component-based software engineering (CBSE) is regarded as one of the most promising software technologies to reduce effort and time-to-market, and to increase quality and architectural standardization. Components are normally domain-specific and executable software modules, often as classes or libraries in a programming language. They can either be COTS (Commercial-Off-The-Shelf) or OSS (Open Source Software) components, both with a world-wide audience, or developed in-house. An advanced form of components are those refined into specialized product families [Linden02]. Platform software such as an OS or DBMS are normally not considered "components", rather commodities.

Due to the increased use and importance of external components (COTS and OSS), the whole field of requirements engineering has changed, involving frequent (re-)negotiation of requirements. Most development lifecycle models also need adjustment, with more emphasis on incremental development and more complex techniques for estimation, integration, and testing. The combination of all these processes raises a set of new challenges. A recent survey in Norwegian, Italian and German ICT industry confirms the high relevance and frequent use of COTS and OSS components to achieve faster, cheaper and more standardized software systems [Li05]. However, systematic risk management remains a problem.

Some key issues are:

2. Agile Development Processes

Agile or light-weight development methods try to cater for continuous changes and a shorter time-to-market. We can mention variants of incremental development methods (often combined with the Rational Unified Process, RUP), spiral methods, and eXtreme Programming (XP) [Beck00]. However, few of these have been systematically validated in practice and for realistic systems. While traditional software development consider changes to the requirements as a problem, the agile methods consider requirements changes as an opportunity to build a product that will help them to achieve greater customer satisfaction. The main mechanisms used to achieve this are:

Some of these mechanisms have also been embraced by other development paradigms - especially test-before-code and the focus on simple solutions. In addition, the agile community has made several claims, for instance that:

Software development companies have, however, several questions that need to be answered before they will convert to agile methods. Their problems are the academia's research challenges. Some key issues are whether agile methods will:

Aside from all these research related issues, the most important problem is: Are the customers willing to be involved as much as the agile methods require?

3. Global software development, GSD

Globalisation is a key characteristic of the 21st century industrialised world, seeing a significant reshaping of economic and business environments. Global software development (GSD) is understood as "software work undertaken at geographically separated locations across national boundaries in a coordinated fashion involving real time and asynchronous interaction" [Sahay03, p.3]. GSD is organised either as multiple teams distributed across sites, or as virtual teams with developers in multiple geographically distributed locations. There are three organizational variants:

GSD brings culturally diverse teams together. This provides new opportunities, but also poses new challenges for the software development process. As [Kruchten04, p.1] points out: "The issues at stake are not superficial matters of ways of dressing, working, speaking, in small daily behaviors, but are founded in the fundamental differences in the systems of values that govern our lives".

Some key issues are:

4. Estimation methods

A good estimation method is the sine qua non of contract-based software development. We need to reliably estimate effort (cost), schedule (time), or product quality (security, safety etc.). Otherwise the customer do not know when and how he will get his product, and the developers do not know what to charge in order to make a profit and thus survive in the long run.

This is especially important for novel system development methods and processes, such as component-based or agile development. Business areas with a long experience, a slowly evolving technology and many similar projects have succeeded in developing a solid base of methods, data and experience that has helped them to achieve a good level of estimation precision in their work. Even they, however, have problems to use new technology or how to move into areas where they have little or no experience. The main problems are that we:

Some key issues are:

5. Software for mobile computing

It is expected that in 2005 it will be more than 1.5 billion wireless subscribers worldwide. As the new mobile devices get more powerful, software development for mobile devices becomes critical. Mobile computing gives challenges to the application developer, e.g. in handling wireless networks, heterogeneity, limited screen size, limited input device, limited CPU, limited memory and battery [Satyan96]. However, mobility also gives new opportunities to develop new type of applications that are aware of the context of the current environment. To succeed in mobile computing, the system support must become an invisible part of the environment. This means that the system must be capable of communicating with all relevant computing devices and sensors around and make use of this information to help the user in a non-intrusive way. As sensor and actuator technologies is getting mature and cheaper, we can envision a future of where the whole environment is equipped with sensors and actuators to provide computer support that can enhance the daily life of people. Such systems are very complex and introduce many challenges for software engineering, and can be used to support work in medical environments, service work, offshore, education etc.

Some key issues are:

6. Software process improvement (SPI) and Empirical Software Engineering

The way we develop and maintain software is called the software process. Several ambitious software process improvement (SPI) frameworks have been proposed, such as the Capability Maturity Model (CMM) from SEI, Software Process Improvement and Capability dEtermination (SPICE) from ISO, and the Quality Improvement Paradigm (QIP) from University of Maryland. They are all inspired by TQM and ISO-9000, and aimed at large and stable organizations. The challenge is to downscale such approaches to small and medium-sized organizations, with much day-to-day turbulence and time-to-market pressure.

Close and long-term cooperation with the ICT industry is vital to succeed in SPI efforts. As a result of three successive, industrial-driven SPI projects, a pragmatic SPI handbook has been developed [Dybå04]. The handbook draws on insight from organizational sciences, e.g. with use of action research and joint workshops among developers and researchers. The handbook represents joint work by SINTEF, UiO, NTNU, the Abelia ICT organization, and a dozen small and medium sized, Norwegian ICT companies.

A future challenge is to combine SPI with more systematic empirical studies to find out what works or what does not, and under what circumstances (project contexts). This will enable us to build models of how and why a certain software technology such as UML and RUP actually performs. However, technologies and their industrial applications are in a constant flux, and there is often too little time and opportunity for systematic data collection, analysis and reflection. This raises many methodical challenges.

A whole new field of Empirical Software Engineering has sprung up over the last decade [Tichy98]. Empirical studies include repeatable and small student experiments ("in vitro"), data mining of available project data, surveys and structured interviews, and large case or field studies in industry ("in vivo"). A mix of empirical methods and techniques must be used and further developed. This requires a combination of technical, statistical, and social skills. We also need to better characterize and understand project contexts. Lastly, the empirical toolkit needs improvement, cf. the web-based SESE tool by the Simula Research Laboratory in Oslo to support distributed experiments with industrial developers [Sjøberg03].

Some key issues are:

7. Software engineering education and technology transfer

There are three key stakeholders in software engineering education and technology transfer: teachers, researchers, and industry actors. Successful software engineering education is the synergy between these stakeholders. NTNU teachers and researchers have a long practice of running software engineering projects at several levels and with several profiles. This gives us an excellent opportunity to study pedagogical approaches to software engineering education and training. By involving industrial actors in providing and running student projects, we ensure industrial relevance [Lethbridge00] [Jaccheri02].

There are many published results, methods and techniques that have not come into common usage, e.g. software inspections and estimation techniques. This is not only an educational problem. For empirical-based insight to come into use, it is important to couple revised models and techniques to the present needs of the company (organization), so-called "situated learning". By working with several ICT companies we do not only ensure relevance and validity - the companies also get engaged in planning, execution and follow-up, so that effective technology transfer can take place. This is valid in both training and teaching at the University. Indeed, the difference between on-the-job training and University education may vanish gradually.

Some key issues related to the relation between the three key stakeholders are:

References

[Beck00] Kent Beck, Extreme Programming Explained, Addison Wesley, 2000.

[Boland04] D. Boland and B. Fitzgerald: "Transitioning from a Co-Located to a Globally-Distributed Software Development Team: A Case Study and Analog Devices Inc", Proc. 6th Global Software Development Workshop, Co-located with ICSE'2004, Edinburgh, May 24, 2004.

[Dybå04] Tore Dybå, Torgeir Dingsøyr, and Nils Brede Moe: "Process Improvement in Practice - a Handbook for IT Companies", The Kluwer International Series in Software Engineering, Boston, Kluwer Academic Publishers, 2004.

[Jaccheri02] Maria Letizia Jaccheri: "A software quality and software process improvement course based on interaction with the local software software industry", in Tutorial section of Computer Applications in Engineering Education Journal, John Wiley, pp. 265-272, March 2002.

[Kruchten04] Philippe Kruchten: "Analyzing Intercultural Factors Affecting Global Software Development - A Position Paper", Proc. 6th Global Software Development Workshop, Co-located with ICSE'2004, Edinburgh, May 24, 2004, 4 p.

[Lethbridge00] C. Timothy Lethbridge: "What Knowledge is Important to a Software Professional", IEEE Computer, May 2000, pp. 44-50.

[Li05] Jingyue Li, Reidar Conradi, Odd Petter N. Slyngstad, Marco Torchiano, Maurizio Morisio, and Christian Bunse: "Preliminary Results from a State-of-Practice Survey on Risk Management in Off-The-Shelf Component-Based Development", Forthcoming at 4th International Conference on Component-Based Software Systems (ICCBSS'05), 7-11 Feb. 2005, Bilbao, Spain. 11 p.

[Linden02] Frank van der Linden: "Software Product Families in Europe: The Esaps & Café Projects", IEEE Software, 19(4):41-49, July/August 2002.

[Moløkken04] Kjetil Johan Moløkken-Østvold, Magne Jørgensen, Sinan S. Tanilkan, Hans Gallis, Anette C. Lien, and Siw Elisabeth Hove: "A Survey on Software Estimation in the Norwegian Industry", the 10th IEEE International Metrics Symposium (Metrics'04), Sept. 14-16, 2004, Chicago, IEEE-CS Press, p. 208-219.

[PITAC99] The President's Information Technology Advisory Committee: "Information Technology Research: Investing in Our Future", 24 February 1999, 94 p. http://www.hpcc.gov/pitac/report/pitac_report.pdf. There was a follow-up NSF Workshop on a Software Research Program for the 21st Century. It identified experimental research, constructive software development methods (cf. CBSE), and efficient technology transfer as important work areas - see ACM SIGSOFT Engineering Notes, May 1999.

[Sahay00] S. Sahay: "Global software alliances: the challenge of 'standardization'", Scandinavian Journal of Information Systems, Vol. 15, pp. 3-13, 2000.

[Satyan96] M. Satyanarayanan: "Fundamental Challenges in Mobile Computing", Proc. 15th Annual ACM Symposium on Principles of Distributed Computing, pp. 1-7, Philadelphia, Pennsylvania, United States, May 23-26 1996. ACM Press.

[Sjøberg03] Dag Sjøberg, Bente Anda, Erik Arisholm, Tore Dybå, Magne Jørgensen, Amela Karahasanovic, and Marek Vokác: "Challenges and Recommendations when Increasing the Realism of Controlled Software Engineering Experiments", In Reidar Conradi and Alf I. Wang (Eds.): Empirical methods and studies in software engineering, ESERNET, 2001-2002, LNCS 2765, p. 24-38, Springer-Verlag, 2003.

[Tichy98] Walter F. Tichy: "Should Computer Scientists Experiment More? 16 Reasons to Avoid Experimentation", IEEE Computer, 31(5):32-40, May 1998.

P.t. on file: http://www.idi.ntnu.no/grupper/su/infosam2020-sweng.php
Reidar Conradi, 14. Dec. 2004