scholarly journals Factors that affect software systems development project outcomes

2011 ◽  
Vol 43 (4) ◽  
pp. 1-56 ◽  
Author(s):  
Laurie McLeod ◽  
Stephen G. MacDonell
Author(s):  
Анастасія Дмитрівна Морікова ◽  
Ольга Костянтинівна Погудіна

Subject research paper is the development of technical systems. The aim is to improve the quality of planning the basic characteristics of technical systems development project. Objective is to analyze the works in the area of risk when planning projects, justified the choice of method of planning the main indicators of the project taking into account the uncertainties and risks, developed and tested method of accounting for risks of interference in the project of development of technical systems on the example of the development of an aircraft engine. Used theoretical methods are: the method of discrete-event simulation for obtaining histograms of cost and time of development of technical systems, the method of calculating the cumulative damage risk events, the model matrix representation as a mathematical device for the presentation and study of interference risks. We obtained the following results. Analysis of existing work and standards in the field of risk management, reviewed the existing information system of risk-based project simulation and variability of the project. On the basis of the detected restriction provides an improved method for the basic parameters of the project planning. The process of identification and the following categories of risk identified: the expectations, cost, appearance of additional work, return. Given the typology of interference risks formalized the concept of additivity, synergy and cannibalization (negative synergy). An information subsystem that preparesinput to project performance simulation taking into account the risks, where the use of the data matrix relationship likelihood of risks and interference effects manifestations of risk events. Developed information subsystem was tested on calculation Show cost and runtime stages of research works on the development of an aircraft engine. Scientific novelty of the results is as follows: improved method of discrete-event simulation account of technical systems development project risks by adding a formalization of interference risks.


Author(s):  
Rafael Capilla ◽  
Juan C. Duenas

In this chapter we describe the product line models, and show how to apply them for developing and evolving Web products. A product line captures the common and variable aspects of software systems as key assets under a common architecture. Software companies are increasingly adopting this approach in order to accelerate the development of families of similar software products. In certain domains, such as the Web systems, development and maintenance operations are required more often. New techniques to engineer Web sites are needed in order to reduce the time to market for the Web products and to maintain the systems afterward. The authors believe that understanding the notion of lightweight product line and the role that the architecture plays will help software engineers in the construction of software products, and they will be able to manage the evolution effectively against future changes.


Author(s):  
Subhas C. Misra ◽  
Vinod Kumar ◽  
Uma Kumar

Successful software systems development is a delicate balance among several distinct factors (Jalote, 2002) such as enabling people to grow professionally; documenting processes representing the gained experiences and knowledge of the organization members; using know how to apply the suitable processes to similar circumstances; and refining processes based on achieved experience. Software projects have two main dimensions: engineering and project management. The engineering dimension concerns the construction of a system, and focuses mainly on issues such as how to build a system. The project management dimension is in charge with properly planning and controlling the engineering activities to meet project goals for optimal cost, schedule, and quality. For a project, the engineering processes specify how to perform activities such as requirement specification, design, testing, and so on. The project management processes, on the other hand, specify how to set milestones, organize personnel, manage risks, monitor progress, and so on (Jalote, 2002). A software process may be defined as “a set of activities, methods, practices, and transformations that people use to develop and maintain software, and the associated products and artifacts.”1 This is pictorially depicted in Figure 1 (Donaldson & Siegel, 2000).


Author(s):  
Steve Clarke

In philosophical terms, a key issue of communities of practice (CoPs) can be located within one of the key philosophical debates. The need for CoPs is traceable to the inadequacy in certain contexts of the so-called scientific or problem-solving method, which treats problems as independent of the people engaged on them. Examples of this can be drawn from the management domains of information systems development, project management, planning, and many others. In information systems development, for example, the whole basis of traditional systems analysis and design requires such an approach. In essence, in undertaking problem solving, the world is viewed as though it is made up of hard, tangible objects, which exist independently of human perception and about which knowledge may be accumulated by making the objects themselves the focus of our study. A more human-centered approach would, by contrast, see the world as interpreted through human perceptions: the reason why the problem cannot be solved is precisely because it lacks the objective reality required for problem solving. In taking this perspective, it may or may not be accepted that there exists a real world “out there”, but in any event, the position adopted is that our world can be known only through the perceptions of human participants. This question of objective reality is one with which philosophers have struggled for at least 2,500 years, and an understanding of it is essential to determining the need for, and purpose of, CoPs. The next section therefore discusses some of the philosophical issues relevant to the subjective-objective debate: a search for what, in these terms, it is possible for us to know and how we might know it.


Sign in / Sign up

Export Citation Format

Share Document