Evaluating groupware support for software engineering students

Software engineering tasks, during both development and maintenance, typically involve teamwork using computers. Team members rarely work on isolated computers. An underlying assumption of our research is that software engineering teams will work more effectively if adequately supported by network-based groupware technology. Experience of working with groupware and evaluating groupware systems will also give software engineering students a direct appreciation of the requirements of engineering such systems. This research is investigating the provision of such network-based support for software engineering students and the impact these tools have on their groupwork. We will first describe our experiences gained through the introduction of an asynchronous virtual environment ­ SEGWorld to support groupwork during the Software Engineering Group (SEG) project undertaken by all second year undergraduates within the Department of Computer Science. Secondly we will describe our Computer Supported Cooperative Work (CSCW) module which has been introduced into the students' final year of study as a direct result of our experience with SEG, and in particular its role within Software Engineering. Within this CSCW module the students have had the opportunity to evaluate various groupware tools. This has enabled them to take a retrospective view of their experience of SEGWorld and its underlying system, BSCW, one year on. We report our findings for SEG in the form of a discussion of the hypotheses we formulated on how the SEGs would use SEGWorld, and present an initial qualitative assessment of student feedback from the CSCW module

The conundrum of categorising requirements: managing requirements for learning on the move

This paper reports on the experience of eliciting and managing requirements on a large European-based multinational project, whose purpose is to create a system to support learning using mobile technology. The project used the socio-cognitive engineering methodology for human-centered design and the Volere shell and template to document requirements. We provide details about the project below, describe the Volere tools, and explain how and why we used a flexible categorization scheme to manage the requirements. Finally, we discuss three lessons learned: (1) provide a flexible mechanism for organizing requirements, (2) plan ahead for the RE process, and (3) do not forget 'the waiting room

Towards a method for rigorous development of generic requirements patterns

We present work in progress on a method for the engineering, validation and verification of generic requirements using domain engineering and formal methods. The need to develop a generic requirement set for subsequent system instantiation is complicated by the addition of the high levels of verification demanded by safety-critical domains such as avionics. Our chosen application domain is the failure detection and management function for engine control systems: here generic requirements drive a software product line of target systems. A pilot formal specification and design exercise is undertaken on a small (twosensor) system element. This exercise has a number of aims: to support the domain analysis, to gain a view of appropriate design abstractions, for a B novice to gain experience in the B method and tools, and to evaluate the usability and utility of that method.We also present a prototype method for the production and verification of a generic requirement set in our UML-based formal notation, UML-B, and tooling developed in support. The formal verification both of the structural generic requirement set, and of a particular application, is achieved via translation to the formal specification language, B, using our U2B and ProB tools

SysML for embedded automotive systems: SysCARS methodology

International audienceThis paper gives an overview of the years of Valeo experience in deploying a Model Based System Engineering (MBSE) approach for mechatronic automotive embedded systems and products. The different stages are described initial studies, language and tool benchmarking up to the last returns of experience on industrial projects. Particular emphasis is put on describing the SysCARS methodology which gives, not only a precise mapping of System Engineering work items to SysML artefacts, but also the sequence of modeling activities to be performed. It is shown how the SySCARS methodology has been implemented as a SysML profile, based on a powerful "workflow driven" mechanism, which helps the user during the modeling process. Finally it is presented how interoperability is ensured with the tools already in place for requirements management and control design

Requirements engineering in software product line engineering

The final publication is available at Springer via http://dx.doi.org/10.1007/s00766-013-0189-0Many attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.Insfrán Pelozo, CE.; Chastek, G.; Donohoe, P.; Sampaio Do Prado Leite, JC. (2014). Requirements engineering in software product line engineering. Requirements Engineering. 19(4):331-332. doi:10.1007/s00766-013-0189-0S331332194Clements P, Northrop LM (2001) Software product lines: practices and patterns. Addison-Wesley, BostonDerakhshanmanesh M, Fox J, Ebert J (2012) Adopting feature-centric reuse of requirements assets: an industrial experience report. First international workshop on requirements engineering practices on software product line engineering, Salvador, BrazilKuloor C, Eberlein A (2002) Requirements engineering for software product lines, proceedings of the 15th international conference on software and systems engineering and their applications (ICSSEA’02), Paris, FranceNorthrop LM, Clements P (2013) A framework for software product line practice. Software engineering institute. http://www.sei.cmu.edu/productlines/tools/framework/index.cfm . Accessed 22 July 2013Yu Y, Lapouchnian A, Liaskos S, Mylopoulos J, Leite JCSP (2008) From Goals to High-Variability Software Design. Foundations of Intelligent Systems, 17th International Symposium Proceedings. ISMIS 2008. Springer Lecture Notes in Computer Science, 4994: 1–1

Software development and continual change: A programmers attitude problem.

Software fonns around a requirement. Defining this requirement is often regarded as the hardest part of software engineering. The requirement however has an additional complexity as, once defined, it will change with time. This change of requirement can come either from the user, or from the rapid advances in 'computer' technology. How then can software succeed to continue to remain 'current' both in tenns of requirements and technology in this forever changing environment? This thesis examines the issues surrounding 'change' as applied to software and software engineering. Changing requirements are often deemed a 'curse' placed upon software engineers. It has been suggested, however, that the problems associated with change exist only in the attitude of software engineers. This is perhaps understandable considering the training methods and tools available to supposedly 'help' them. The evidence shows that quality of management and experience of personnel involved in development contribute more significantly to the success of a development project than any technical aspect. This unfortunately means that the process is highly susceptible to staff turnover which, if uncontrolled, can lead to pending disaster for the users. This suggests a 'better' system would be developed if 'experience' was maintained at a process level, rather that at an individual level. Conventional methods of software engineering are based upon a defined set of requirements which are detennined at the beginning of the software process. This thesis presents an alternative paradigm which requires only a minimal set of requirements at the outset and actively encourages changes and additional requirements, even with a mature software product. The basis of this alternative approach is the fonn of the 'requirements specification' and the capturing and re-use of the 'experience' maintained by the software process itself

The engineering of generic requirements for failure management

We consider the failure detection and management function for engine control systems as an application domain where product line engineering is indicated. The need to develop a generic requirement set - for subsequent system instantiation - is complicated by the addition of the high levels of verification demanded by this safety-critical domain, subject to avionics industry standards. We present our case study experience in this area as a candidate methodology for the engineering, validation and verification of generic requirements using domain engineering and Formal Methods techniques and tools. For a defined class of systems, the case study produces a generic requirement set in UML and an example instantiation in tabular form. Domain analysis and engineering produce a model which is integrated with the formal specification/ verification method B by the use of our UML-B profile. The formal verification both of the generic requirement set, and of a simple system instance, is demonstrated using our U2B and ProB tools. This work is a demonstrator for a tool-supported method which will be an output of EU project RODIN. The method, based in the dominant UML standard, will exploit formal verification technology largely as a "black box" for this novel combination of product line, failure management and safety-critical engineering

Transportability, distributability and rehosting experience with a kernel operating system interface set

For the past two years, PRC has been transporting and installing a software engineering environment framework, the Automated Product control Environment (APCE), at a number of PRC and government sites on a variety of different hardware. The APCE was designed using a layered architecture which is based on a standardized set of interfaces to host system services. This interface set called the APCE Interface Set (AIS), was designed to support many of the same goals as the Common Ada Programming Support Environment (APSE) Interface Set (CAIS). The APCE was developed to provide support for the full software lifecycle. Specific requirements of the APCE design included: automation of labor intensive administrative and logistical tasks: freedom for project team members to use existing tools: maximum transportability for APCE programs, interoperability of APCE database data, and distributability of both processes and data: and maximum performance on a wide variety of operating systems. A brief description is given of the APCE and AIS, a comparison of the AIS and CAIS both in terms of functionality and of philosophy and approach and a presentation of PRC's experience in rehosting AIS and transporting APCE programs and project data. Conclusions are drawn from this experience with respect to both the CAIS efforts and Space Station plans

Product Lifecycle Management and the Quest for Sustainable Space Exploration Solutions

Product Lifecycle Management (PLM) is an outcome of lean thinking to eliminate waste and increase productivity. PLM is inextricably tied to the systems engineering business philosophy, coupled with a methodology by which personnel, processes and practices, and information technology combine to form an architecture platform for product design, development, manufacturing, operations, and decommissioning. In this model, which is being implemented by the Engineering Directorate at the National Aeronautics and Space Administration's (NASA's) Marshall Space Flight Center, total lifecycle costs are important variables for critical decisionmaking. With the ultimate goal to deliver quality products that meet or exceed requirements on time and within budget, PLM is a powerful tool to shape everything from engineering trade studies and testing goals, to integrated vehicle operations and retirement scenarios. This paper will demonstrate how the Engineering Directorate is implementing PLM as part of an overall strategy to deliver safe, reliable, and affordable space exploration solutions. It has been 30 years since the United States fielded the Space Shuttle. The next generation space transportation system requires a paradigm shift such that digital tools and knowledge management, which are central elements of PLM, are used consistently to maximum effect. The outcome is a better use of scarce resources, along with more focus on stakeholder and customer requirements, as a new portfolio of enabling tools becomes second nature to the workforce. This paper will use the design and manufacturing processes, which have transitioned to digital-based activities, to show how PLM supports the comprehensive systems engineering and integration function. It also will go through a launch countdown scenario where an anomaly is detected to show how the virtual vehicle created from paperless processes will help solve technical challenges and improve the likelihood of launching on schedule, with less hands-on labor needed for processing and troubleshooting. Sustainable space exploration solutions demand that all lifecycle phases be optimized. Adopting PLM, which has been used by the automotive industry for many years, for aerospace applications provides a foundation for strong, disciplined systems engineering and accountable return on investment by making lifecycle considerations variables in an iterative decision-making process. This paper combines the perspectives of the founding father of PLM, along with the experience of Engineering leaders who are implementing these processes and practices real-time. As the nation moves from an industrial-based society to one where information is a valued commodity, future NASA programs and projects will benefit from the experience being gained today for the exploration missions of tomorrow

Practical experiences in concurrent, collaborative ontology building using Collaborative Protégé

Creation of an ontology according to some common plan is best accomplished collaboratively. This is sometimes contradicted by the distribution of the ontology’s developers. An obvious solution therefore is to build collaboration into ontology development tools. Such support necessarily includes both the technical means to perform editing operations upon an ontology, but also support for the communication that makes collaboration such a vital part of much ontology development. To investigate the distributed, collaborative ontology engineering process and the corresponding capabilities of the Collaborative Protege 3 (CP) tool, members of the OntoGenesis network came together and enriched the Ontology of Biomedical Investigations (OBI) with new content. The communications and interactions of the participants with each other, directly or through the tool, were tracked and analyzed. Our initial analysis of the degree to which this new tool fulfills the practical requirements of collaborative ontology engineering suggests the approach is promising. We present some observations and recommendations for CP based upon this experience