Self-endorsed Cybersecurity Capability Improvement for SMEs

Low cybersecurity awareness and the lack of good practices have led to a growing number of cyber-attacks and incidents in small and medium-sized enterprises (SMEs). This study introduces CYSEC, a new lightweight Do-It-Yourself (DIY) approach to communicate cybersecurity awareness training to a large number of SMEs and encourage them to improve their capability continuously. CYSEC is a method and tool that implements the Self-Determination Theory (SDT) to motivate SME end-users to sustainable self-endorsed forms of security behavior and guide them to carry out the security improvement on their own. The paper describes the theoretical framework for modeling self-determination and explains how the adoption of cybersecurity recommendations can be internalized step-by-step by an SME by following an iterative process in CYSEC. Finally, significant lessons learned about the use of CYSEC and its intervention in pursuit of cybersecurity adoption in the pilot SMEs are presented

18th International Working Conference on Requirements Engineering: Foundation for Software Quality. Proceedings of the Workshops RE4SuSy, REEW, CreaRE, RePriCo, IWSPM and the Conference Related Empirical Study, Empirical Fair and Doctoral Symposium

This ICB Research Report constitutes the proceedings of the following events which were held during the Requirements Engineering: Foundation for Software Quality (REFSQ) conference 2012 in Essen, Germany. Engineering for Sustainable Systems (RE4SuSy), Requirements Engineering Efficiency Workshop REEW 2012), Creativity in Requirements Engineering (CreaRE 2012), Requirements Prioritization for customer oriented Software Development (RePriCo), International Workshop on Software Product Management (IWSPM), Alive Empirical Study, Online Questionnaires, Empirical Research Fair, Doctoral Symposium

Pediatric lung transplantation: The years 1985 to 1992 and the clinical trial of FK 506

The application of lung transplantation to the pediatric population was a natural extension of the success realized in our adult transplantation program, which began in 1982. Twenty pediatric patients (age range 3 to 18 years) have had heart-lung (n = 11), double lung (n = 8), and single lung (n = 1) transplantation procedures. The causes of end-stage lung disease were primary pulmonary hypertension (n = 7), congenital heart disease (n = 5), cystic fibrosis (n = 4), pulmonary arteriovenous malformation (n = 2), graft- versus-host disease (n = 1), and desquamative interstitial pneumonitis (n = 1). Four (20%) patients had thoracic surgical procedures before the transplantation operation. The survival was 80% at a mean follow-up of 2 years. Immunosuppressive drugs included cyclosporine (n = 9) or FK 506 (n = 11) based therapy with azathioprine and steroids. Children were followed up by means of spirometry, transbronchial biopsy, and primed lymphocyte testing of bronchoalveolar lavage fluid. The mean number of treated episodes of rejection was 1.4 at 30 days, 0.5 at 30 to 90 days, and 1.4 at more than 90 days, and the first treated rejection episode occurred on average 28 days after the operation. Obliterative bronchiolitis developed in four (25%) of 16 patients surviving more than 100 days. Results of pulmonary function tests have remained good in almost all recipients. The greatest infectious risk was that of cytomegalovirus: one death and one case of pneumonia. Posttransplantation lymphoproliferative disease was diagnosed in two (12.5%) patients; both recovered. The most common complications were hypertension (25%) and postoperative bleeding (15%). Early results indicate that lung transplantation is a most promising therapy for children with severe vascular and parenchymal lung disease

Requirements Engineering for Digital Health

Healthcare and well-being have captured the attention of established software companies, start-ups, and investors. Software is starting to play a central role for addressing the problems of the aging society and the escalating cost of healthcare services. Enablers of such digital health are a growing number of sensors for sensing the human body and communication infrastructure for remote meetings, data sharing, and messaging. The challenge that lies in front of us is how to effectively make use of these capabilities, for example to empower patients and to free the scarce resources of medical personnel.Requirements engineering is the process by which the capabilities of a software product are aligned with stakeholder needs and a shared understanding between the stakeholders and development team established. This book provides guide for what to look for and do when inquiring and specifying software that targets healthcare and well-being, helping readers avoid the pitfalls of the highly regulated and sensible healthcare domain are and how they can be overcome.This book brings together the knowledge of 22 researchers, engineers, lawyers, and CEOs that have experience in the development of digital health solutions. It represents a unique line-up of best practices and recommendations of how to engineer requirements for digital health. In particular the book presents:· The area of digital health, e-health, and m-health· Best practice for requirements engineering based on evidence from a large number of projects· Practical step-by-step guidelines, examples, and lessons-learned for working with laws, regulations, ethical issues, interoperability, user experience, security, and privacy· How to put these many concerns together for engineering the requirements of a digital health solution and for scaling a digital health productFor anybody who intends to develop software for digital health, this book is an introduction and reference with a wealth of actionable insights. For students interested in understanding how to apply software to healthcare, the text introduces key topics and guides further studies with references to important literature

An Analysis of Change Scenarios of an IT Organization for Flexibility Building

Flexibility is important for software organizations to cope with changes demanded in the business environment. So far, flexibility has been extensively studied from a software product and software development process point of view. However, there is little work on how to build flexibility at the level of the whole software organization. Thus, there is no clear understanding of how to effectively improve the ability of an organization to respond to changes in a timely fashion and with little effort. This paper presents the results of a grounded theory study on how flexibility is built and improved in an IT organization and provides a holistic and explanatory view of how this is achieved. Implications for research and practices are also provided

The effect of requests for user feedback on Quality of Experience

Companies are interested in knowing how users experience and perceive their products. Quality of Experience (QoE) is a measurement that is used to assess the degree of delight or annoyance in experiencing a software product. To assess QoE, we have used a feedback tool integrated into a software product to ask users about their QoE ratings and to obtain information about their rationales for good or bad QoEs. It is known that requests for feedback may disturb users; however, little is known about the subjective reasoning behind this disturbance or about whether this disturbance negatively affects the QoE of the software product for which the feedback is sought. In this paper, we present a mixed qualitative-quantitative study with 35 subjects that explore the relationship between feedback requests and QoE. The subjects experienced a requirement-modeling mobile product, which was integrated with a feedback tool. During and at the end of the experience, we collected the users’ perceptions of the product and the feedback requests. Based on the users’ rational for being disturbed by the feedback requests, such as “early feedback,” “interruptive requests,” “frequent requests,” and “apparently inappropriate content,” we modeled feedback requests. The model defines feedback requests using a set of five-tuple variables: “task,” “timing” of the task for issuing the feedback requests, user’s “expertise-phase” with the product, the “frequency” of feedback requests about the task, and the “content” of the feedback request. Configuration of these parameters might drive the participants’ perceived disturbances. We also found that the disturbances generated by triggering user feedback requests have negligible impacts on the QoE of software products. These results imply that software product vendors may trust users’ feedback even when the feedback requests disturb the users

Workshop videos for requirements communication.

Shared understanding of requirements between stakeholders and the development team is a critical success factor for requirements engineering. Workshops are an effective means for achieving such shared understanding. Stakeholders and team representatives can meet and discuss what a planned software system should be and how it should support achieving stakeholder goals. However, some important intended recipients of the requirements are often not present in such workshops: the developers. Thus, they cannot benefit from the in-depth understanding of the requirements and of the rationales for these requirements that develops during the workshops. The simple handover of a requirements specification hardly compensates the rich requirements understanding that is needed for the development of an acceptable system. To compensate the lack of presence in a requirements workshop, we propose to record that requirements workshop on video. If workshop participants agree to be recorded, a video is relatively simple to create and can capture much more aspects about requirements and rationales than a specification document. This paper presents the workshop video technique and a phenomenological evaluation of its use for requirements communication from the perspective of software developers. The results show how the technique was appreciated by observers of the video, present positive and negative feedbacks from the observers, and lead to recommendations for implementing the technique in practice