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:
- Component-based software engineering (CBSE)
- Agile development processes
- Global software development (GSD)
- Estimation methods
- Software for mobile computing
- Software process improvement (SPI) and empirical software engineering
- Software engineering education and technology transfer
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
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:
- What is an appropriate overall process (lifecycle model) for a given CBSE project?
- How can we estimate and manage project risk at all levels?
- What is the relation between requirements, architectural choices, quality assurance, and risk management on all levels?
- What are the criteria to (re-)negotiate requirements when available components does not fully match?
- How to select components of needed functionality and quality?
- How to estimate effort for component selection and integration?
- How to assess quality and stability of available components?
- What is the relation between software architecture and product families (e.g. what comes first?), and should a program family be engineered reactively or proactively?
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:
- Customer participation. The customer is the final arbiter when it comes to questions related to functionality and quality issues.
- Work incrementally and in short time boxes.
- Write the tests before writing the code.
- "Keep it simple, stupid" - as simple as possible but not simpler, also known as the KISS principle.
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:
- Pair programming will remove the need for code inspections.
- The test-before code will enable us to do refactoring throughout development without serious risk to product or project.
- The KISS principle plus the test-before-code principle remove the need to develop and maintain large amounts of documentation this cutting the development effort by up to 50%.
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:
- Enable us to make acceptable development contracts concerning effort and schedule?
- Work for projects that develop software that is safety-critical or business-critical?
- Remove the need for Verification & Validation methods, such as inspections and code reviews?
- Accommodate development based on external software components (COTS, OSS) or internal software reuse?
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:
- Intra-organizational virtual teams: Normal business activities in large organizations are increasingly undertaken in geographically distributed teams. Cf. software development in multi-national organizations like Ericsson, Sun, and IBM.
- Subcontracting: Businesses choose to outsource a substantial part of their activities to external subcontractors, often in low-cost countries like India or China [Boland04]. Relatively long-term, inter-organisational software alliances are therefore established between the outsourcing and the outsourced organisation.
- Ad-hoc development efforts (open source software, OSS): A large number of software products, such as Emacs, Linux and Mozilla, are developed in OSS projects. These are ad-hoc and non-paid development projects, where developers from all over the world jointly and idealistically develop high-quality software in a loosely coordinated effort.
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:
- How to develop and adapt software processes and methods that work in a global setting?
- How to manage communication and coordination across geographical distances?
- What are the cultural factors involved in GSD?
- What is expected effort and schedule profile of such projects, e.g. how to account for extra overheads?
- For what kind of projects or project phases will such a development be most well-suited?
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:
- Make a large amount of assumption at the start of the estimation process. These assumptions are neither documented nor discussed.
- Do development (creative design), not production (predictible manufacture). Thus, it is difficult to build a reservoir of detailed experience. In addition, development is a creative process relying heavily on human ingenuity - a process that is difficult to formalise and estimate.
- Almost always attack new problems. This adds to the problem stated in the previous bullet - the problem of building a solid experience base.
- Have to accommodate a continuous stream of changes throughout the development process. Their impact has to be assessed in order to make the effort and consequences clear to all parties involved.
Some key issues are:
- Given the problems identified above, how can we build a useful body of experience that can be used for effort and schedule estimation and risk identification in software development projects?
- How can we use our experience to identify, understand and manage risks in software effort estimation?
- How can we reliably estimate relevant aspects of software projects that uses novel technologies (CBSE, use cases, agile or incremental processes, GSD etc.)?
- How can we obtain a measure of the level of uncertainty and arbitrate different properties and risks against each other?
- For what kind of systems/projects are a certain estimation method best suited?
- In short: How can we combine our knowledge, experiences and statistical
models into a coherent body of methods that can be used to:
* Obtain better estimation methods for effort and schedule.
* Control the project in a proactive way.
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:
- Given the problems above, what architecture can be used to realize context-aware systems that are reliable, trustworthy and scalable?
- How can we create middleware that is able to integrate a very heterogeneous environment of various computing devices, sensors and actuators?
- How can we make scalable systems that can cope with interaction between many mobile devices, servers, sensors and actuators?
- How can we ensure that a system using actuator is safe for the surrounding environment?
- What architectures and models can be used to create a flexible context-aware workflow system?
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:
- What (subset of adjusted) SPI methods works best for small and medium sized companies?
- How to apply action research and grounded theory in industrial software studies?
- What data mining methods apply for software engineering data?
- How to describe and account for different contexts?
- How to perform realistic experiments in industry, cf. work by the Simula Research Laboratory?
- How to design and apply light-weight experience bases, e.g. coupled to web-based process guides?
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:
- Which are the guiding principles (e.g., abstraction, formal methods, logic etc.) that should support a software engineering master program?
- Which are the pedagogical styles (lecturing, project based, open problems, closed problems etc.) and in which way should they be combined?
- Should a curriculum be constructed top-down (e.g., starting from principles), or bottom-up (e.g., starting from industry needs)?
- Provided that some education is project based, which kind of empirical investigation can be run in the context of student projects?
- How and to which extent should the empirical research goals and hypotheses of the researchers influence the pedagogical style and the nature of student projects (ethical issues)?
- When and why should researchers and teachers be influenced by industry, and when and why should industry be influenced by researchers and teachers?
[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