Studies of Project Tasks

Studies of Project Tasks

DOI: 10.4018/978-1-5225-3707-6.ch004
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Among the projects available in sourceforge.net, the three top ranked projects are selected for studying the pattern of project tasks over a period of 6 years (2005-2011). It is found that the number of tasks in projects decrease with time in these projects. It is also observed that the amount of time taken to complete the task decrease with time. The developers alloted to tasks in a project, success rate the developers complete the tasks completely, and active contribution to the project by completing the alloted tasks of the volunteers are also studied.
Chapter Preview
Top

Introduction

Software products are examples of complex systems. The complexity of software is due to the large number of requirements such a product should satisfy. Additionally, the development of software demands diverse skill sets, technically and other, which one person cannot possibly posses. Any software which is expected to run in real world is therefore built by a group of developers. This feature of software development has forced the practitioners to adopt some design principles to accommodate multiple developers working on a project.

The earliest attempt to solve this problem wasto divide the software development process into various related activities. All the process models and methodologies used in software engineering embody this idea. The basic activities of analysis, design, code, test and maintenance are common to all devel- opment methods. This separation of concern gives an opportunity to divide the software development into tasks which can be allotted to each individual developer or groups ofdevelopers.

Another way to solve the problem of synchronising multiple developers isfollowing the design principle of modularity. Modularity helps to isolate functional elements of the system. One module may be debugged, improved, or extended with minimal interaction to system discontinuity. As important as modularity is specification.

Table 1.
Structure of table PROJECT_TASK
ColumnTypeModifiers
project task idintegernot null
group projectidintegernot null default 0
summarytextnot null default ”::text
detailstextnot null default ”::text
percent completeintegernot null default 0
priorityintegernot null default 0
hoursdouble precisionnot null default (0)::double precision
start dateintegernot null default 0
end dateintegernot null default 0
created byintegernot null default 0
status idintegernot null default 0

Complete Chapter List

Search this Book:
Reset