Balancing Opportunities and Risks in Component-Based Software Development

The increasingly rapid change in information technology makes it essential for software development projects to continuously monitor and adapt to new sources of opportunity and risk. Software projects and organizations can increase their success rates in software development by better assessing and balancing their opportunities and risks. The authors summarize the Incremental Commitment Model (ICM), a process framework for improved project monitoring and decision making based on balancing opportunities and risks. They give an example of how the ICM framework can improve component-based development choices based on assessment of opportunities and risks. They show how different opportunistic solutions result from different stakeholder value propositions. They elaborate on the risks involved in architectural mismatches among components, present a tool called the Integration Studio (iStudio) that enables projects to assess the most common sources of architectural mismatch between components. Finally, they present representative examples of its use.     

OpenStack开源社区中商业组织的参与模式

2000年以来,开源软件取得了显著进展,展示出一种以用户创新为驱动且低成本高质量的新型软件开发方式.越来越多的商业组织参与到开源项目中,期望利用开源软件及其优势实现自身的商业目标.由于开源软件开发方式与传统的软件工程方法存在显著差异,为了加入开源社区,商业组织必须要对自身原有的软件开发方式、业务模式等做出调整.在这种情况下,一个亟待解决的问题是商业组织应当采取怎样的参与模式才能有效融入开源社区.为此,本文进行了如下三个方面的研究：1.采用雪球采样方法对OpenStack相关的文本数据进行收集,为定性分析提供数据基础;2.借鉴扎根理论,通过对所收集数据的过滤和归纳,总结出不同商业组织参与OpenStack的模式;3.在此基础上,提炼出四种更具一般性的参与模式,为商业组织参与开源项目提供经验参考与决策支持.     

Building contextual ambidexterity in a software company to improve firm-level coordination

Software organizations increasingly face contradictory strategic choices as they develop customized and packaged solutions for the market. They need to improve efficiency of development processes while at the same time adapting to emerging customer needs; they need to exploit software products in relation to existing customers while simultaneously exploring new technology and market opportunities; and, they need to consider both incremental and radical innovations. While the integration of such opposing strategies requires software organizations to become ambidextrous, there is limited actionable advice on how managers can develop such capability. Against this backdrop, we report from a two-year action research study into a small software firm, TelSoft. Based on Pettigrew's contextualist inquiry, we develop a framework that integrates existing theory on contextual ambidexterity with a generic process for improving software organizations, and we apply this framework to analyze how TelSoft improved its coordination of products, projects, and innovation efforts. As a result, we offer principles for how software managers can build ambidextrous capability to improve firm-level coordination.     

Management challenges to implementing agile processes in traditional development organizations

Discussions with traditional developers and managers concerning agile software development practices nearly always contain two somewhat contradictory ideas. They find that on small, stand-alone projects, agile practices are less burdensome and more in tune with the software industry's increasing needs for rapid development and coping with continuous change. Managers face several barriers, real and perceived, when they try to bring agile approaches into traditional organizations. They categorized the barriers either as problems only in terms of scope or scale, or as significant general issues needing resolution. From these two categories, we've identified three areas - development process conflicts, business process conflicts, and people conflicts - that we believe are the critical challenges to software managers of large organizations in bringing agile approaches to bear in their projects.     

Experience effects on the accuracy of self-assessed user competence

Self-managed learning is the normal way that users learn to work with software within organizations. To be effective, self-managed, learning requires individuals to self-assess their IT knowledge; accurate self-assessment helps them optimize the capabilities they possess and be aware of those they do not. This study demonstrated that, in general, individuals did not accurately self-assess their knowledge of the software they used. However, we also found that the accuracy of self-assessment increased with greater experience in, and better understanding of, IT domains.Organizations need to recognize the self-assessment problem to facilitate effective software learning and to gain the most from their software investments.     

A reference framework for process-oriented software development organizations

In this paper, a proposal of a generic framework for process-oriented software development organizations is presented. Additionally, the respective way of managing the process model, and the instantiation of their processes with the Rational Unified Process (RUP) disciplines, whenever they are available, or with other kind of processes is suggested. The proposals made here were consolidated with experiences from real projects and we report the main results from one of those projects.     

Project managers in global software development teams: a study of the effects on productivity and performance

Globalization is having a deep impact on today’s world economy. One of the most affected industries is the software industry. Recently, global software development (GSD) has gained a lot of attention. This new trend of producing software is influencing all software processes, including human resource management. The aim of this study is to provide an overview of the implications of GSD for software project managers by analyzing project performance from different perspectives such as the 360-degree feedback evaluation. Results show that performance of GSD projects is lower than in-house projects, but apart from that, this study reveals that there are also negative consequences for software project managers, which need to be taken into account. For instance, the experiment revealed a lack of attention to tasks by software project managers and, as a consequence of this, performance losses. The main conclusions of this research may be valuable for software development organizations.     

Evolution of the frameworks quagmire

Various combinations of national and international standards bodies, government organizations, professional societies, and other quasilegislative bodies, each vying for influence over a particular market sector, have promulgated a dizzying array of software and system process standards, recommended practices, guidelines, maturity models, and other frameworks. The resulting quagmire has quenched the ardor of many organizations seeking accreditation for one or more frameworks. Software and systems engineers question whether the qualification process will lead to quarrels over interpretation rather than quick and real progress. In 1997, the Software Productivity Consortium created a Web site to help organizations understand which frameworks were most important and how they related to each other (http://www.software.org/quagmire). As the paper shows, many new frameworks and updates to existing frameworks have appeared since then. Fortunately, most of these additions recognize the need for compatibility and attempt to define their relationship with other models     

Agile monitoring using the line of balance

There is a need to collect, measure, and present progress information in all projects, and Agile projects are no exception. In this article, the authors show how the line of balance, a relatively obscure indicator, can be used to gain insights into the progress of projects not provided by burn down charts or cumulative flow diagrams, two of the most common indicators used to track and report progress in Agile projects. The authors also propose to replace the original plan-based control point lead-time calculations with dynamic information extracted from a version control system and introduce the concept of the ideal plan to measure progress relative to both, end of iteration milestones and project completion date.     

Software architectural patterns in practice: an empirical study

Software architecture involves a series of decisions based on many factors in a wide range of software development. Architects face recurring issues in different software architecture design, and to reduce huge cost and risks, software architecture decisions can rely on a set of idiomatic patterns commonly named architectural styles or patterns. Architectural pattern determines the vocabulary of components and connectors that are used in instances of the pattern together with a set of constraints to combine the two. Little contemporary data exists to document actual practices used by software professionals when selecting and incorporating architectural patterns for their projects in industry. Therefore, a comprehensive survey of software professionals was conducted to attempt to discover these practices. This exploratory survey and its quantitative results offer opportunities for further interpretation and comparison. Data from this survey are presented in this paper and include characteristics of projects, practices, organizations, and practitioners related to the usage of architectural patterns. Some of the notable findings include that architectural patterns are widely used in software projects with the Model–View–Controller being the most common. Despite reported difficulties in incorporating architectural patterns, the majority of the software professionals revealed that patterns were the most essential for completing the projects. The most difficult pattern to implement and the most expensive to adopt was the peer-to-peer, while the easiest was the client–server.

     

Retrain your code czar

Many software organizations have two classes of technical staff: normal employees and royalty. The royalty-those kings, queens, and czars of software development-initiate central controlling project roles. They see a dire project need and act on it, though no one asked them to. Royalty believe they provide unique project and product skills for the organization. They may, but, in my experience, their controlling actions prevent the project and the team from developing products and cohesive processes. When one team member takes on the royalty role, it prevents the rest of the group from learning what she already knows. The team becomes fragmented and can't work together; the problems that created the royalty become even worse. Royalty delay projects because they interrupt the normal development loop of creating the product, testing it, fixing it, integrating it, and getting feedback. The royalty must stay in their chosen role, because the participants eventually come to believe that the project cannot make any progress without them     

PBURC: a patterns-based,unsupervised requirements clustering framework for distributed agile software development

Agile software development methodologies are increasingly adopted by organizations because they focus on the client’s needs, thus safeguarding business value for the final product. At the same time, as the economy and society move toward globalization, more organizations shift to distributed development of software projects. From this perspective, while adopting agile techniques seems beneficial, there are still a number of challenges that need to be addressed; among these notable is the effective cooperation between the stakeholders and the geographically distributed development team. In addition, data collection and validation for requirements engineering demands efficient processing techniques in order to handle the volume of data as well as to manage different inconsistencies, when the data are collected using online tools. In this paper, we present “PBURC,” a patterns-based, unsupervised requirements clustering framework, which makes use of machine-learning methods for requirements validation, being able to overcome data inconsistencies and effectively determine appropriate requirements clusters for optimal definition of software development sprints.     

Software Effort, Quality, and Cycle Time: A Study of CMM Level 5 Projects

The Capability Maturity Model (CMM) has become a popular methodology for improving software development processes with the goal of developing high-quality software within budget and planned cycle time. Prior research literature, while not exclusively focusing on CMM level 5 projects, has identified a host of factors as determinants of software development effort, quality, and cycle time. In this study, we focus exclusively on CMM level 5 projects from multiple organizations to study the impacts of highly mature processes on effort, quality, and cycle time. Using a linear regression model based on data collected from 37 CMM level 5 projects of four organizations, we find that high levels of process maturity, as indicated by CMM level 5 rating, reduce the effects of most factors that were previously believed to impact software development effort, quality, and cycle time. The only factor found to be significant in determining effort, cycle time, and quality was software size. On the average, the developed models predicted effort and cycle time around 12 percent and defects to about 49 percent of the actuals, across organizations. Overall, the results in this paper indicate that some of the biggest rewards from high levels of process maturity come from the reduction in variance of software development outcomes that were caused by factors other than software size     

What Do We Know about Developer Motivation?

Software engineers will do better work and stay with a company if they are motivated—as a result the success of software projects is likely to improve. The authors use the findings from their in-depth review of the 92 studies published in the last 25 years on software engineer motivation to give an overview of what managers need to know to improve motivation among their employees.     

Assessing the health of open source communities

Before contributing to a free or open source software project, understand the developers, leaders, and active users behind it. The computing world lauds many Free/Libre and open source software offerings for both their reliability and features. Successful projects such as the Apache httpd Web server and Linux operating system kernel have made FLOSS a viable option for many commercial organizations. While FLOSS code is easy to access, understanding the communities that build and support the software can be difficult. Despite accusations from threatened proprietary vendors, few continue to believe that open source programmers are all amateur teenaged hackers working alone in their bedrooms. But neither are they all part of robust, well-known communities like those behind Apache and Linux.     

基于CMM第五级上的软件开发成本、质量和开发周期的回归分析

软件开发中,处于CMM第五级的开发团队拥有相对较高的过程成熟,而高度成熟的过程对开发成本、质量和开发周期具有重要的影响。使用线性回归模型对4个CMM第五级的团队所开发的37个项目进行数据采集和研究后,发现此时大部分被认为影响软件开发成本、质量和开发周期的因素的作用被削弱了,而其中最重要的因素是软件规模。     

Case study: factors for early prediction of software development success

Project managers can make more effective and efficient project adjustments if they detect project high-risk elements early. We analyzed 42 software development projects in order to investigate some early risk factors and their effect on software project success. Developers in our organization found the most important factors for project success to be: (1) the presence of a committed sponsor and (2) the level of confidence that the customers and users have in the project manager and development team. However, several other software project factors, which are generally recognized as important, were not considered important by our respondents.     

A defined process for project post mortem review

Most of us pay lip service to the need for software project post mortems, but the literature offers little guidance on how to conduct them. The authors propose a tentative, standard process for conducting post mortem reviews and describe activities, roles, and artifacts of the process. The success of the post mortem-or of any learning process-demands a context that makes organizational learning possible. Management must make an honest and sincere commitment to establish this context. This commitment should take the form of a public resolution to implement risk management on subsequent projects and to make all post mortem findings input to that risk management effort. After all, lessons learned the hard way on past projects are, if nothing else, risks for future projects. Participants are empowered when they know that each issue raised during the post mortem process must be added to the risk database and evaluated methodically on each subsequent project     

Trust‐annotated ontology integration using social modelling*

Abstract: As ontologies become more prevalent for information management the need to manage the ontologies increases. Multiple organizations, within a domain, often combine to work on specific projects. When separate organizations come together to communicate, an alignment of terminology and semantics is required. Ontology creation is often privatized for these individual organizations to represent their view of the domain. This creates problems with alignment and integration, making it necessary to consider how much each ontology should influence the current decision to be made. To assist with determining influence a trust‐based approach on authors and their ontologies provides a mechanism for ranking reasoning results. A representation of authors and the individual resources they provide for the merged ontology becomes necessary. The authors are then weighted by trust and trust for the resources they provide the ontology is calculated. This is then used to assist the integration process allowing for an evolutionary trust model to calculate the level of credibility of resources. Once the integration is complete semantic agreement between ontologies allows for the revision of the authors' trust.     

Exploring the relationship between software project duration and risk exposure: A cluster analysis

Software projects often fail. Thus it is important to find ways to ensure a successful outcome. One significant area is a better understanding of the relationship between the software project duration and risk exposure, as this helps project managers with pertinent information to be effective in managing risky projects. We addressed this need by adopting a cluster analysis technique to provide managers with insight into effective planning and control of their projects. The results not only revealed that risk exposures associated with user, requirement, planning & control and team risk dimensions were affected by project duration, but also showed how to manage software risks effectively through observing trends in the risk components. Based on our findings, project managers can adopt appropriate attitudes, skills, and practices to deal with risky areas more effectively rather than just identifying those software risks with which project managers should be concerned.