A Model for Capturing and Managing Software Engineering Knowledge and Experience

During software development projects there is always a particular working "product" that is generated but rarely managed: the knowledge and experience that team members acquire. This knowledge and experience, if conveniently managed, can be reused in future software projects and be the basis for process improvement initiatives. In this paper we present a model for managing the knowledge and experience team members acquire during software development projects in a non-disruptive way, by integrating its management into daily project activities. The purpose of the model is to identify and capture this knowledge and experience in order to derive lessons learned and proposals for best practices that enable an organization to preserve them for future use, and support software process improvement activities. The main contribution of the model is that it enables an organization to consider knowledge and experience management activities as an integral part of its software projects, instead of being considered, as it was until now, as a follow-up activity that is (infrequently) carried out after the end of the projects

Rationale Management Challenges in Requirements Engineering

Rationale and rationale management have been playing an increasingly prominent role in software system development mainly due to the knowledge demand during system evaluation, maintenance, and evolution, especially for large and complex systems. The rationale management for requirements engineering, as a commencing and critical phase in software development life cycle, is still under-exploited. In this paper, we first survey briefly the state-of-the-art on rationale employment and applications in requirements engineering. Secondly, we identify the challenges in integrating rationale management in requirements engineering activities in order to promote further investigations and define a research agenda on rationale management in requirements engineering.

Re-using knowledge : why, what and where

Previously the 're-use' focus has centred on specific and/or standard parts, more recently however, [standard components] are being developed...to enable both the re-use of the part and the experience associated with that part'. This notion is further extended by Finger who states that 'designers may re-use a prior design in it's entirety,...may re-use an existing shape for a different function, or may re-use a feature from another design'. Reinforcing this notion we currently consider re-use to reflect the utilisation of any knowledge gained from a design activity and not just past designs of artefacts. Our research concerns the improvement of formal 're-use' support and as such we have identified a need to gain a better understanding of how design knowledge can be utilised to support 're-use'. Thus, we discuss the requirements of successful 're-use' and attempt to ascertain within this skeleton: what knowledge can be re-used; how to maximise its' applicability; and where and when it can be utilised in new design

Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

A3 thinking approach to support knowledge-driven design

Problem solving is a crucial skill in product development. Any lack of effective decision making at an early design stage will affect productivity and increase costs and the lead time for the other stages of the product development life cycle. This could be improved by the use of a simple and informative approach which allows the designers and engineers to make decisions in product design by providing useful knowledge. This paper presents a novel A3 thinking approach to problem solving in product design, and provides a new A3 template which is structured from a combination of customised elements (e.g. the 8 Disciplines approach) and reflection practice. This approach was validated using a case study in the Electromagnetic Compatibility (EMC) design issue for an automotive electrical sub-assembly product. The main advantage of the developed approach is to create and capture the useful knowledge in a simple manner. Moreover, the approach provides a reflection section allowing the designers to turn their experience of design problem solving into proper learning and to represent their understanding of the design solution. These will be systematically structured (e.g. as a design checklist) to be circulated and shared as a reference for future design projects. Thus, the recurrence of similar design problems will be prevented and will aid the designers in adopting the expected EMC test results