Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects - نسخه متنی

Kweku Ewusi-Mensah

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Project-Team Composition

Software project size and complexity make a given project virtually incomprehensible to any one individual developer. Software projects are, therefore, virtually unique in that they are among perhaps a handful of projects undertaken in organizations where three groups of employees with sometimes vastly different backgrounds are required to work together. First, there are the technical personnel or developers, who usually have highly technical training and experience but may have limited knowledge in the problem domain. Second, there are the end users, who, in most instances, have limited technical background or experience in information technology but are knowledgeable in the relevant application problem domain. And finally, there is management, which may be the "sponsor" or "champion" of the project. In instances where management may lack the requisite technical background and/or the necessary knowledge of the problem domain to oversee the detailed direction of the project, they may delegate that responsibility to other senior technical members of the team.

Software projects are thus group-oriented activities organized and executed in teams. As such, work on any software project is subject to all the vagaries of group dynamics, interactions, coordination, and communication. The diverse backgrounds of the team's constituent members make the ability to communicate a crucial prerequisite if the team is to work successfully on the project's development. How the team is put together from the various stakeholder groups, together with the individual and collective capabilities of the team, are issues of great consequence to the project development effort. To the extent that the work of the project team involves acquisition and sharing of the problem-domain knowledge among the team members, how the team is put together becomes a crucial factor in its success. In addition, effective coordination of the activities of the stakeholders and subgroups involved in the project is critical in ensuring the success of the project (Krault and Streeter 1995; Constantine 1993).

The various roles expected to be performed collectively by the members of the project teams are usually complemented by the specific roles and responsibilities of individual members of the teams. For example, it is important that for each task of the project a leader is assigned with specific responsibility for organizing how the task is to be carried out and what the deliverables should be when it is completed. The critical role played by the overall project leader is necessary to facilitate the coordination and communication essential to the collaborative work of the teams. Software projects are inherently characterized by the dimensions of teamwork and communication, without which failure is eminently possible.

The postmodernist view of software development explicitly recognizes the need for a plurality and diversity of shared responsibilities of all the stakeholder groups involved in the development, so that all legitimate and relevant views will be heard and incorporated into the problem formulation (Robinson et al. 1998; Klein, Jiang, and Tesch 2002). From the postmodernist perspective, no superior or inferior status is conferred on any class of people involved in the project development, be they technical developers, user groups, or management. All the members of the project team play complementary roles and work on the basis of mutual interdependence because of the unique qualifications and experiences each brings to the project team. The changing dynamics of such a team in the life of a project may itself be a source of potential risk. For example, the attrition that occurs when people leave and perhaps are replaced by new people in the course of the life of the project may affect the resources consumed and may further add to the uncertainties of the project development environment.

/ 92