Aligning an ISO/EIC 42010 System Architecture Model and Agile Practice

The ISO/EIC 42010 system architecture description standard evolved over a number of years with substantial practitioner inputs. It presents a high level, top-down view of requirements that may be interpreted as needed for different applications. Agile system development methods have proved effective in practice, but represent a bottom up view drawing on user stories. The question considered in this paper is how they might be harmonised. Experience from using these tools over several years in practical masters degree student projects has been used to explore this question. We suggest a logical compatibility lies in their core themes: stakeholder needs (who) frame architecture descriptions (what) and the associated rationale (why). A particular interpretation of ISO/EIC 42010 and a model outlining the evolution of architecture in an agile environment are presented. Several suggestions for future research are made

Communication Patterns and Strategies in Software Development Communities of Practice

Some of the greatest challenges in the relatively new field of software development lie in the decidedly old technology of communication between humans. Software projects require sophisticated and varied communication skills because software developers work in a world of incomplete, imperfect information where teams evolve rapidly in response to evolving requirements and changing collaborators. While prescriptive models for software process such as Agile suggest ways of doing, in reality these codified practices must adapt to the complexities of a real workplace. Patterns, rather than rules of behavior within software process are more suitable to the varied and mutable nature of software development. Software development communities are also learning communities, attempting to sustain themselves through internal ambiguity and external changes. We study different types of software development communities to fulfill our goal of understanding how these communities implement and evolve different communication strategies to sustain themselves through change. We observe student software development projects, open source software development, and a professional, rigorously Agile software development community. We employ Wenger\u27s concept of Community of Practice to frame our understanding, especially focusing on the notions of identity, participation, reification, negotiation of meaning and trajectory of the participants of the software development communities. From these different sources, we identify the emergent themes of mentoring and knowledge management as critical for sustainable communities. Through our long running, immersive, participant observer, ethnographic study of the Agile software development community, we contribute both a quantitative and qualitative analysis of the their communication practices and depict the evolving nature of their onboarding and mentoring strategies. We share our experience of implementing such an immersive industry ethnographic study. We employ a pattern language approach to capturing, analyzing and representing our results, thereby contributing and relating to the larger bodies of work in Scrum and Organizational Patterns. This work also informs our concurrent efforts to enhance our undergraduate computer science and software engineering curriculum, exposing students to the communication challenges of real software development and help them to develop skills to meet these challenges through practice in inquiry, critique and reflection

Enterprise Architecture Specification Case Study

A graduate course in enterprise architecture had a team project component in which a real-world business case, provided by an industry sponsor, formed the basis of the project charter and the architecture statement of work. The paper aims to share the team project experience on developing the architecture specifications based on the business case of an accountable health care organization. Students collaborated as a team in various roles to develop the architecture specifications for a new business initiative of the sponsoring organization, XYZ ACO. The teaching case describes the case study approach and the architecture approach adopted for the architecture process, and is accompanied by Teaching Case Notes which provide a selection of the models developed by members of the project team towards the architecture specifications. The course started with coverage of enterprise architecture theory, best practices and standards, and the team project gave students the opportunity to apply their theoretical knowledge and “learn by doing”. Students were challenged to interpret the business case, the project charter and project requirements, and each team member was allocated an architecture viewpoint and a role to play. The Teaching Case presents a summary of the team project and the lessons learned in performing the project

Do Pair Programming Approaches Transcend Coding? Measuring Agile Attitudes in Diverse Information Systems Courses

Agile methods and approaches such as eXtreme programming (XP) have become the norm for successful organizations not only in the software industry but also for businesses seeking to improve internal software processes. Pair programming in some form is touted as a major functionality and productivity improvement. However, numerous studies show that simply placing two programmers side by side in front of a single computer screen is not enough. We must look at other factors such as programmer expertise, project preparation, and perceived solution quality to understand pair programming’s promises and pitfalls. In our study, we apply tailored programming challenges to a multifaceted group of first-year through senior Information Systems (IS) and non-IS majors to analyze how participant attitudes and perceived benefits of pair programming change from pre- to post-study, as well as determine whether the quality and functionality of the solutions differ across education levels and disciplines. Our findings show a strong interaction effect of gender and major composition (CIS vs. non-CIS majors) in all four dimensions of the ATMI attitude scale. Findings also suggest that experience in problem solving and solution formation are more important than prior specific domain knowledge. Finally, participants’ perceived ability, sense of accomplishment, and completion of the assigned work, regardless of background or demographic, determined their performance outcome on the pair-programming tasks, which suggests that not all forms of attitude and perceived benefits contribute to the performance outcome

Happy software developers solve problems better: psychological measurements in empirical software engineering

For more than 30 years, it has been claimed that a way to improve software developers' productivity and software quality is to focus on people and to provide incentives to make developers satisfied and happy. This claim has rarely been verified in software engineering research, which faces an additional challenge in comparison to more traditional engineering fields: software development is an intellectual activity and is dominated by often-neglected human aspects. Among the skills required for software development, developers must possess high analytical problem-solving skills and creativity for the software construction process. According to psychology research, affects-emotions and moods-deeply influence the cognitive processing abilities and performance of workers, including creativity and analytical problem solving. Nonetheless, little research has investigated the correlation between the affective states, creativity, and analytical problem-solving performance of programmers. This article echoes the call to employ psychological measurements in software engineering research. We report a study with 42 participants to investigate the relationship between the affective states, creativity, and analytical problem-solving skills of software developers. The results offer support for the claim that happy developers are indeed better problem solvers in terms of their analytical abilities. The following contributions are made by this study: (1) providing a better understanding of the impact of affective states on the creativity and analytical problem-solving capacities of developers, (2) introducing and validating psychological measurements, theories, and concepts of affective states, creativity, and analytical-problem-solving skills in empirical software engineering, and (3) raising the need for studying the human factors of software engineering by employing a multidisciplinary viewpoint.Comment: 33 pages, 11 figures, published at Peer

Involving External Stakeholders in Project Courses

Problem: The involvement of external stakeholders in capstone projects and project courses is desirable due to its potential positive effects on the students. Capstone projects particularly profit from the inclusion of an industrial partner to make the project relevant and help students acquire professional skills. In addition, an increasing push towards education that is aligned with industry and incorporates industrial partners can be observed. However, the involvement of external stakeholders in teaching moments can create friction and could, in the worst case, lead to frustration of all involved parties. Contribution: We developed a model that allows analysing the involvement of external stakeholders in university courses both in a retrospective fashion, to gain insights from past course instances, and in a constructive fashion, to plan the involvement of external stakeholders. Key Concepts: The conceptual model and the accompanying guideline guide the teachers in their analysis of stakeholder involvement. The model is comprised of several activities (define, execute, and evaluate the collaboration). The guideline provides questions that the teachers should answer for each of these activities. In the constructive use, the model allows teachers to define an action plan based on an analysis of potential stakeholders and the pedagogical objectives. In the retrospective use, the model allows teachers to identify issues that appeared during the project and their underlying causes. Drawing from ideas of the reflective practitioner, the model contains an emphasis on reflection and interpretation of the observations made by the teacher and other groups involved in the courses. Key Lessons: Applying the model retrospectively to a total of eight courses shows that it is possible to reveal hitherto implicit risks and assumptions and to gain a better insight into the interaction...Comment: Abstract shortened since arxiv.org limits length of abstracts. See paper/pdf for full abstract. Paper is forthcoming, accepted August 2017. Arxiv version 2 corrects misspelled author nam

The 24-Hour Knowledge Factory Paradigm: The Evolving Model for Offshoring based on Strategic, Economic, Legal, Health, Technical, and Other Considerations

The 24-Hour Knowledge Factory paradigm involves 3 (or more) collaborating centers, each located in a different continent. Individuals at each center work from 9 am to 5 pm in that country, and then pass the work-in-progress to the next collaborating center to enable round-theclock performance in a manner somewhat akin to the deployment of three shifts in the manufacturing sector. The 24-Hour Knowledge Factory is relevant for structured and semi-structured applications in many knowledge-based industries including accounting, legal, design, and development. There is a growing array of examples from healthcare and other domains where off-site professionals have been able to provide better results than on-site professionals, thereby validating that many tasks can be more effectively performed using the 24-Hour Knowledge Factory approach. The gradual adoption of this paradigm is motivated by several considerations. In 2007, the World Health Organization concluded that working at night is a probable cause of breast cancer in women and prostate cancer in men. Attempts by US state governments and even the federal government to discourage outsourcing are unlikely to succeed for multiple reasons, and the notion of “hybrid outsourcing” will gain momentum over time. Plus there are the advantages of developing products and services in a shorter timeframe; furthermore, these products and services can command broader appeal in the global marketplace. A detailed study was conducted at IBM to compare the performance of a co-located team and a distributed team, and the performance of the latter team exceeded initial expectations. The key results from this study will be discussed in this session