Learning Effective Changes for Software Projects

The primary motivation of much of software analytics is decision making. How to make these decisions? Should one make decisions based on lessons that arise from within a particular project? Or should one generate these decisions from across multiple projects? This work is an attempt to answer these questions. Our work was motivated by a realization that much of the current generation software analytics tools focus primarily on prediction. Indeed prediction is a useful task, but it is usually followed by "planning" about what actions need to be taken. This research seeks to address the planning task by seeking methods that support actionable analytics that offer clear guidance on what to do. Specifically, we propose XTREE and BELLTREE algorithms for generating a set of actionable plans within and across projects. Each of these plans, if followed will improve the quality of the software project.Comment: 4 pages, 2 figures. This a submission for ASE 2017 Doctoral Symposiu

Shared Understanding of the User Experience : A Case Study of Collaboration Between Developers and Designers

User experience has become vital for many software development projects but the software development methods and tools are not originally intended for it. Moreover, software development is fundamentally complex and an increasingly social profession. This shift towards designing for user experience as a diverse group has brought new challenges to software development. The objective of this study is to find how developers and designers form a shared understanding of the software system UX under development. Central theme are the activities of UX work: what are the methods in use (e.g. User-Centered Design, Agile) and how do they work in practice, that is, what kind of information developers and designers share and what kind of artifacts do they produce in collaboration. This study answers two research questions: (RQ1) How do developers and designers form a shared understanding of the software system UX under development; and (RQ2) What are the artifacts utilized in their collaboration. To answer the research questions, a single case study research was conducted by interviewing the employees of a Finnish startup company. The company develops enterprise resource planning software (ERP) for rental businesses. The results show that shared understanding of the UX is achieved with UX activities throughout the system’s lifecycle where the user participation is required from the beginning of new software development. Furthermore, the artifacts in combination with developers’ participation in some of the UX activities will convey the design intent to the implemented software

Categorization of Anti-Patterns in Software Project Management

In the last decades, software systems have become an intrinsic element in our daily lives. Software exists in our computers, in our cars, and even in our refrigerators. Today’s world has become heavily dependent on software and yet, we still struggle to deliver quality software products, on-time and within budget. When searching for the causes of such alarming scenario, we find concurrent voices pointing to the role of the project manager. But what is project management and what makes it so challenging? Part of the answer to this question requires a deeper analysis of why software project managers have been largely ineffective. Answering this question might assist current and future software project managers in avoiding, or at least effectively mitigating, problematic scenarios that, if unresolved, will eventually lead to additional failures. This is where anti-patterns come into play and where they can be a useful tool in identifying and addressing software project management failure. Unfortunately, anti-patterns are still a fairly recent concept, and thus, available information is still scarce and loosely organized. This thesis will attempt to help remedy this scenario. The objective of this work is to help organize existing, documented software project management anti-patterns by answering our two research questions: · What are the different anti-patterns in software project management? · How can these anti-patterns be categorized

Learning and Forgetting Curves in Software Development: Does Type of Knowledge Matter?

What type of knowledge, among domain, technology, and methodology knowledge, is most influential to the performance of software development? We answer to this question by empirically investigating the learning and forgetting curves in software development using an extensive archival data set of software development projects in an IT service company. We find that prior experiences with the same methodology or technology have a stronger impact on software project performance than those in the same application domain. Furthermore, our results show that methodology knowledge is more easily forgotten than domain or technology knowledge. Our findings provide managerial implications not only to the development of knowledge and skills, but also to other organizational issues in software development such as project team staffing and career development

Steel Model Approval: Can BIM provide a drawing-free approval process?

Despite widespread use of Building Information Modelling (BIM) software used within their industry, the approval of steelwork contractor’s design information is largely based on the approval of 2d-drawings. These workflows can be modernised to take advantage of current technology and provide productivity gains, but barriers to change exist. This research is an attempt to answer the research question of if a model-based approval process, which removes the need for drawings, is achievable. To answer this question, a mixed methodology was used. A literature review was performed to understand how the approval process works, what information is required and what BIM technologies and processes are available. An interoperability test was performed on a typical steelwork BIM model to evaluate if current neutral data exchange exports could capture the required approval information. Thirdly, a quantitative research study was performed, questioning structural engineers operating within the Irish construction industry on what their opinions where on this issue and to understand their concerns around using BIM. The findings were that structural engineers were sceptical on the issue and had strong concerns around BIM contractual issues and other BIM participants. The neutral exchange exports from the steel detailing software “Tekla Structures” were found to be generally good but lacking in key areas. The findings of the literature review, interoperability test and survey results were triangulated to derive a set of requirements to enable a BIM model-based approval process to be acceptable to a significant cohort of Irish AEC sector

Influential factors of aligning Spotify squads in mission-critical and offshore projects – a longitudinal embedded case study

Changing the development process of an organization is one of the toughest and riskiest decisions. This is particularly true if the known experiences and practices of the new considered ways of working are relative and subject to contextual assumptions. Spotify engineering culture is deemed as a new agile software development method which increasingly attracts large-scale organizations. The method relies on several small cross-functional self-organized teams (i.e., squads). The squad autonomy is a key driver in Spotify method, where a squad decides what to do and how to do it. To enable effective squad autonomy, each squad shall be aligned with a mission, strategy, short-term goals and other squads. Since a little known about Spotify method, there is a need to answer the question of: How can organizations work out and maintain the alignment to enable loosely coupled and tightly aligned squads? In this paper, we identify factors to support the alignment that is actually performed in practice but have never been discussed before in terms of Spotify method. We also present Spotify Tailoring by highlighting the modified and newly introduced processes to the method. Our work is based on a longitudinal embedded case study which was conducted in a real-world large-scale offshore software intensive organization that maintains mission-critical systems. According to the confidentiality agreement by the organization in question, we are not allowed to reveal a detailed description of the features of the explored project

Software source code escrow agreement and legal obstacles of its execution

Software source code escrow agreement is a relatively new occurrence, emerged together with the rise of software industry in 1970’s in the U.S. Taking into account the fact that business relationships between the software licensor and the licensee are mostly permanent, i.e. significant part is not only the license agreement, but also maintenance and support service duties assumed by the licensor, it is important that business continuity of the licensee is ensured. Software source code escrow agreement aims to provide this assurance by promise, that if the licensor ceases to exist (becomes insolvent), then the source code – building instruction of the software, will be turned over to the licensee and provide licensee with the option to maintain the software himself. Thesis is dedicated to enquiry what obstacles impede execution of such contract and the answer lies in the consideration why the software escrow agreement is concluded in the first place – bankruptcy. That is to say, mandatory bankruptcy laws preclude any actions following the commencement of bankruptcy proceedings if they concern property of bankruptcy estate

Software source code escrow agreement and legal obstacles of its execution

Software source code escrow agreement is a relatively new occurrence, emerged together with the rise of software industry in 1970’s in the U.S. Taking into account the fact that business relationships between the software licensor and the licensee are mostly permanent, i.e. significant part is not only the license agreement, but also maintenance and support service duties assumed by the licensor, it is important that business continuity of the licensee is ensured. Software source code escrow agreement aims to provide this assurance by promise, that if the licensor ceases to exist (becomes insolvent), then the source code – building instruction of the software, will be turned over to the licensee and provide licensee with the option to maintain the software himself. Thesis is dedicated to enquiry what obstacles impede execution of such contract and the answer lies in the consideration why the software escrow agreement is concluded in the first place – bankruptcy. That is to say, mandatory bankruptcy laws preclude any actions following the commencement of bankruptcy proceedings if they concern property of bankruptcy estate

Contract Law in Context: The Case of Software Contracts

The membership of The American Law Institute unanimously approved the “Principles of the Law of Software Contracts” in May of 2009. In this essay for a symposium in the Wake Forest Law Review, I draw on my experience as Reporter on the ALI project to add my perspective on an interesting general question: Is specialization of contract law wise and, if so, in what contexts? I certainly cannot definitively answer the question of whether in the abstract society is better off with general or specialized law, but my experience in drafting the software rules, along with Associate Reporter, Maureen O\u27Rourke, sheds some light