1、管理信息系统课程论文全英文版Risk Management for Collaborative Software Development (管理信息系统课程作业 蒋艳辉 学号：2006310050 )Abstract: Collaborative software development involving multiple organizational units, often spanning national, language, and cultural boundaries, raises new challenges and risks that can derail softwa
2、re development projects even when traditional risk factors are being controlled. This article presents a framework that can be used to manage collaborative software development projects, based on an extended set of risk management principles. Three risk factors - trust, culture, and collaborative co
3、mmunication - are discussed in depth.Key words: Collaborative software development, risk management, collaborative communication INTRODUCTIONCollaborative software development (CSD) entails multiple teams, working for multiple organizational units within the same or different companies, and no clear
4、 central authority. Software development in such an environment often crosses national, linguistic, and cultural boundaries and requires changes in the nature of risk management.Risk management is a routine practice of software development and project management. It deals with anticipating, preventi
5、ng, and mitigating problems arising in the software product, project, or process, including difficulties in personnel, communication, and coordination. Traditional risk management has been effective in addressing the needs of a single organization and its relationships with its clients and subcontra
6、ctors. However, the current globalization of markets, business relationships, and technology has given rise to less centralized, collaborative efforts and partnerships for multi-organizational software development. These partnerships require the modification of internal organizational practices, par
7、ticularly for collaborative communication, and significant enhancements to an organizations risk monitoring, mitigation, and management (RMMM) activities.In response to these challenges, this article codifies the differences between CSD and single-organization development, describes an extended set
8、of principles for CSD risk management, and outlines a new, layered risk management framework for CSD. The article also describes three critical risk factors for CSD that emerged from the authors field research: trust, culture, and collaborative communication. RISK MANAGEMENT IN TRADITIONAL SOFTWARE
9、ENGINEERINGTraditional software engineering practices were developed to support project teams formed by functional sub-teams or cross-functional teams operating under a single central authority. These practices have defined the scope and the elements of traditional risk management.Risk in general is
10、 denned by uncertainty and loss - possibly imputed or indirect (e.g., loss of reputation) rather than directly measurable (Gotterbarn, 2005; Pressman, 2005). In software development, risks are identified as problems that might occur on the project and how they might impede project success (Schwalbe,
11、 1994). The Software Engineering Institute introduced risk management as a software management discipline for dealing with the possibility that future events may cause adverse effects (SEI, 2005). The major functions of a risk management framework include: identification and categorization of risk t
12、ypes, planning how to avoid risks where possible, and otherwise how to detect, mitigate, and recover from problems as they occur. Monitoring, mitigation, and recovery may be specialized for an individual risk or a risk class, depending on the chance and potential effects of that risk. Highly likely,
13、 serious risks receive a specialized plan or dedicated tasks for monitoring, mitigation, and control, whereas less likely, less catastrophic, or more generic groups of similar risks can be handled together.The key risk management functions are outlined in Table 1. Note that the last two functions -
14、risk communication and RMMM review - are ongoing supporting activities integrated with the rest of the functions. Most of the risk management activities in Table 1 are self-explanatory. Risk analysis, however, warrants further discussion.Table 1 Risk Management FunctionsRisk Management FunctionsRisk
15、 Management PhasesRisk Identification and AnalysisElicit, identify, and classify major project and process risks.Process risk data into decision-making information. Determine the values of impact, likelihood, and timeframe.Risk PlanningTranslate risk information into decisions and actions (both pres
16、ent and future) and implement those actions.Risk AvoidanceWhere possible, modify to minimize likelihood/impact of particular risk type.Risk MonitoringTrack risk indicators and mitigation actions. Anticipate increasing likelihood of particular risks.Detect(impending/actual) occurrence where possible.
17、Risk MitigationIf a problem occurs, take steps to limit its scope and impact. In particular, try to prevent cascade of related problems.Risk Management, Recovery, and ControlOnce problem has occurred, take steps to get project/product back on track.Correct for deviation from the planned risk actions
18、.Support ActivitiesRisk CommunicationProvide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks.RMMM ReviewReview and update risk management strategies, planes, and activities, based on current and past feedback and environmental c
19、hanges.Traditional risk analysis categorizes each risk along several dimensions and also considers risk interactions, using past history, industry experience, and organizational theory (Barki et al., 2001; Boehm, 1989; Nidumolu, 1996). From the literature (Pressman, 2005), risks are classified in se
20、veral dimensions, such as the origin of the risk (nature and cause), the definiteness (from near-certain to highly unlikely), the anticipated consequences (degree of risk), and the aspects affected. COLLABORATIVE SOFTWARE DEVELOPMENT AND RISK MANAGEMENTTodays software development has moved away from
21、 the single team-single location-single management structure paradigm to distributed, collaborating teams with flexible management relationships. In addition, recent experience with complex projects has shown that older development practices (Larman, 2004), with fully specified requirements and sign
22、-offs and completely predetermined interfaces between major components, have substantial problems and are especially vulnerable both to schedule pressure and to unexpected changes and events. Finally, economic factors have encouraged inter-organizational development practices such as outsourcing and
23、 off shoring.For these reasons, less centralized approaches to development have been pursued.(1)In distributed software development, teams work at different, distributed sites, often with different specialties and background, with infrequent face-to-face communication.(2)In multi-organizational deve
24、lopment, participating teams work for different organizations. Multi-organizational development can be either:Contractual, with one central authority (either one of the developer organizations or, less frequently, a customer) and other teams working on specific components with carefully specified pr
25、edefined interfaces and behavior, orCooperative, with teams working on subsystems or low-coupled components with iteratively specified interfaces and behavior, often without a clear, universally accepted central authority for resolving differences and conflicts.A typical characteristic of the projec
26、ts utilizing the above less-centralized development paradigm is diversity in corporate and social cultures. The overall project team is composed of teams and individuals who may come from very different social and/or corporate cultures with different nationalities, languages, and expectations for be
27、havior, communication, and work rules.Collaborative development, of course, can take many different forms. In this article, the term collaborative software development (CSD) refers to work that is distributed, multi-organizational, and cooperative. Both management practices and risk management pract
28、ices must be adjusted to each of these pressures simultaneously. Although not all collaborative projects will exhibit all of these features, any collaborative project will share some of the above characteristics, experience the challenges described here, and therefore benefit from some of the propos
29、ed risk management approaches described here, when suitably adapted to fit the individual development situation.Both distributed development (Beranek et al., 2005) and collaborative software development (Deek and McHugh, 2003) introduce a number of new risk management concerns and modify or intensif
30、y others. Collaborative software development entails a comprehensive change in the software engineering practices, from business case and product vision through development processes to management policies. Cooperation and communication concerns are significantly different, not only in level but als
31、o in kind. Software development requires a common product vision and architecture, extensive idea and design exchange, continuous communication, and active use of consultation, approval, and consensus - constrained only by intellectual property, privacy, and security considerations. Some of the more
32、 important differences between traditional software development and CSD are highlighted in Table 2.Table 2 Differences between Traditional Software Development (SD) and Multi-Organizational CSDDifferences between Traditional Software Development (SD) and Multi-Organizational CSDPerspectiveTraditional SDMulti-Organizational Collaborative SDOrganizational cultureStakeholdersStakeholders standard &well knownHeterogeneous stakeholders with varying roles Organizational culture and business practicesHomogeneous organizational cultureSingle set of business p
