.: THE AWARENESS NETWORK, TO WHOM SHOULD I DISPLAY MY ACTIONS? AND, WHOSE ACTIONS SHOULD I MONITOR?

THE AWARENESS NETWORK, TO WHOM SHOULD I DISPLAY MY ACTIONS? AND, WHOSE ACTIONS SHOULD I MONITOR?

ABSTRACT:

The concept of awareness plays a pivotal role in research in Computer-Supported Cooperative Work. Recently, Software Engineering researchers interested in the collaborative nature of software development have explored the implications of this concept in the design of software development tools. A critical aspect of awareness is the associated coordinative work practices of displaying and monitoring actions. This aspect concerns how colleagues monitor one another’s actions to understand how these actions impact their own work and how they display their actions in such a way that others can easily monitor them while doing their own work. In this paper, we focus on an additional aspect of awareness: the identification of the social actors who should be monitored and the actors to whom their actions should be displayed. We address this aspect by presenting software developers’ work practices based on ethnographic data from three different software development teams. In addition, we illustrate how these work practices are influenced by different factors, including the organizational setting, the age of the project, and the software architecture. We discuss how our results are relevant for both CSCW and Software Engineering researchers.

ARCHITECTURE:

EXISTING SYSTEM:

Ehrlich explains that “an expertise locator provides a valuable tool for individuals to develop awareness of ‘who knows what’ and to reach out to people across the organization.”

Expertise networks are intended to cover organizational timeframes. Expertise networks cover careers and multiple projects. Expertise networks focus on general abilities. Expertise networks are enterprise wide. Expertise networks reflect the developing and maintaining of an information repository. Expertise networks require eliciting tacit knowledge and transcribing explicit information. Expertise networks prescribe new contacts or remaking old contacts.

DISADVANTAGE:

Ø Expertise networks are intended to cover organizational timeframes.

Ø Expertise networks cover careers and multiple projects.

Ø Expertise networks focus on general abilities.

Ø Expertise networks are enterprise wide.

PROPOSED SYSTEM:

Awareness is “an understanding of the activities of others, which provides a context for your own activity.” In the introduction to this present paper, we described an awareness network to be “the network of actors whose actions need to be monitored by an actor and those to whom this actor needs to make his or her own actions visible.” Awareness networks reflect the carrying out of a specific task. Awareness networks require displaying and monitoring one’s activities. Awareness networks emerge by observing coworkers’ Activities. Awareness networks exist in task and project timeframes. Awareness networks cover members in a team and one or a few projects. Awareness networks focus on specific activities. Awareness networks are team sized.

Advantage:

Ø Awareness networks exist in task and project timeframes.

Ø Awareness networks cover members in a team and one or a few projects.

Ø Awareness networks focus on specific activities.

Ø Awareness networks are team sized.

MODULES:

TASK ASSIGNMENT:

For accountability purposes, all changes in the Alpha software need to be associated with a problem report . Among other pieces of information, a PR describes the changes in the code, the reason for the changes (bug fixing, enhancement, etc.), and who made the changes. An Alpha developer is delegated new tasks by being assigned to work with one or more PRs. These PRs are reported by other team members. Whoever is filling in the PR is responsible for filling in the field “how to repeat,” which describes the circumstances (data, tools, and their parameters) under which the problem appeared. When software developers report a PR, they also might divide a PR into multiple PRs that achieve the same goal. This division aims to facilitate the organization of the changes in the source code, separating PRs that affect the released Alpha tools from those PRs that affect tools or processes not yet released.

As mentioned in the previous section, each developer is assigned to one or more processes and tends to specialize in that process. A manager will follow this practice and assign developers to work on PRs that affect “their” respective processes. However, it is not unusual to find developers working in different processes.3 In this case, Alpha developers need to identify and contact the process owner to find out whether there is a problem in the process. 4 If there is a problem, developers will start working to find a solution to this problem. Even if the problem is straightforward, before committing their code, Alpha developers need to contact process owners to verify, through a code review (a prescription of the Alpha software development process), whether their changes in the process are going to impact the work of these process owners. Code reviews are performed by process leaders whose processes are affected by the changes in the PR. If the changes involve more than one process, a request for a code review has to be made to the owner of each process affected by those changes.

IDENTIFYING WHO TO CONTACT:

The need to contact process owners means that the developer working with the PR needs to identify the owner of the process being affected. This is not a problem for most developers, who have been working in the project for a couple of years and already know which developers work on which parts of the source code. In contrast, developers who recently joined the project face a different situation because they lack this knowledge. To handle this situation, newcomers use information available in the team’s mailing list. The software development process prescribes that software developers should send email to this list before integrating their changes in the shared repository. Developers thus associate the author of the emails describing the changes with the “process” where the changes were occurring: Alpha team members assume that if one developer repeatedly performed check-ins in a specific process, it was very likely that he or she was an expert on that process. Therefore, a developer needing help with that process would know who to contact for help.

PR WORK:

After having his or her changes approved by the process owner(s), a developer fills in the other fields of the PR, describing not only the changes made in the code (through the designNar field, for example), but also the impact these changes are going to have on the V&V staff.The information about the impact on the V&V staff is re- corded in two PR fields: (i) the “how-to-test-it” field is used by the test manager, who creates test matrices that will later be used by the testers during the regression testing; and (ii) another field that describes whether the Alpha manuals need updating. The documentation expert uses this information to find out whether the manuals need to be updated, based on the changes introduced by the PR. In some cases, developers are even more specific:

SYSTEM REQUIREMENTS:

HARDWARE REQUIREMENTS:

Ø System : Pentium IV 2.4 GHz.

Ø Hard Disk : 40 GB.

Ø Floppy Drive : 1.44 Mb.

Ø Monitor : 15 VGA Colour.

Ø Mouse : Logitech.

Ø Ram : 512 Mb.

SOFTWARE REQUIREMENTS:

Ø Operating system : Windows XP.

Ø Coding Language : ASP.Net with C#

Ø Data Base : SQL Server 2005

Data Flow Diagram / Use Case Diagram / Flow Diagram

The DFD is also called as bubble chart. It is a simple graphical formalism that can be used to represent a system in terms of the input data to the system, various processing carried out on these data, and the output data is generated by the system.