Vision

• Vision
  • Problem and Position Statement
  • Stakeholder Descriptions
    • Project Team
    • PSP student
    • Other software development professionals
  • Needs and Features
    • Have project process documented and traceable
    • User data available anytime, anywhere
    • Multiple user and system interfaces
  • Other Product Requirements

Vision

This page documents the stakeholders' view of the technical solution to be developed. This definition is specified in terms of the key needs and desired features. It contains an outline of the envisioned core requirements for the system.

Problem and Position Statement

Software development is a very intensive activity in terms of dedication by the contributors involved in it and is known to require good quality control on both, the products derived and the production processes themselves, for them to remain in good shape in the long term.

In order to help to improve the results from software development efforts, a vast amount of resources have been invested for decades in research and development of supporting tools, appropriate organizational structures and working methodologies encompassing all their related activities. However, even though formidable progresses have been achieved all these areas, it still remains a key success factor the capacity of the team to effectively exercise control of the overall project and to carry out their duties as much as possible in a consistent and diciplined way.

The Personal Software ProcessSM (PSP) aims to develop a dicipline and skills considered valuable for a performant software development engineer at an individual level, and which also can serve as the basis to improve work at the team level. It is expected that such dicipline and skills have a positive impact in the results of a software development effort, but they require time and proper practice to be developed; their effectiveness also can be leveraged or conditioned by the enviroment supporting.

The purpose of this project is to create opportunities in which some of the techniques prescribed as part of the PSP, as well as some other good software development practices, can be exercised and thus learned by first hand experience. It also comprises a development effort which is conveniently targeted at a set of tools that will help to build a supporting environment for such techniques and practices.

Stakeholder Descriptions

In this section, stakeholders are identified by proper or generic name, and a brief description and summary of key responsibilities of each with regard to the system being developed are presented. The responsabilities of a stakeholder represent their interest on the project.

Project Team

A group of software developers with a personal motivation in the improvement of their practices and skills related to software construction: time tracking, effort estimation, project management, team collaboration, software testing, defect tracking and handling, apply documented software development processes, and some others. Also, there's an interest in gaining experience with development of systems and applications incorporating web-related technologies and approaches, taking into account considerations of interoperability with third parties and cross-platform support.

Their responsibilities for the project are:

• Initiate and execute project.
• Ensure project process is well documented and transparent, and status and progress is accurately reflected on behalf of all other stakeholders.
• Fulfill the role of end user and/or domain expert (when no better candidate is available).

PSP student

An undergraduate student (or perhaps an already practicing software developer) that is being introduced to the principles and practices of the PSP and is likely to be using the "Introduction to the Personal Software Process", by Humphrey Watts, as textbook. While following the assignments that have him start gathering personal performance data, he'll find quite valuable a tool that helps alleviate the burden of collecting and processing it, which is probably the greatest barrier he'll face for a sustained adoption of the practices being learned.

His responsibilities for the project are:

• Use the produced tools for supporting him in carrying out the assignments found in the textbook.
• Provide feedback on the tools' usability and their effectiveness to ease the burden of data collection and processing.
• Report product defects.
• Suggest new valuable functionality to be considered for new product releases.

Other software development professionals

Software developers not actively or directly involved in the project, but which nevertheless may be interested in having accessible project documentation, process guidance, design documentation and/or source code to use in their own projects or as a basis for a case study. May eventually become active project team members.

Needs and Features

Have project process documented and traceable

One of the main goals of the project is to build useful, shareable knowledge about actual software development experiences employing a particular set of practices and techniques with a given environment and set of supporting tools.

Envisioned features supporting this need are:

• Use of OpenUP, an existing and documented software development process, as the basis for the employed project process.
• Written guidelines and procedures about specific application of the process with the project's given environment and employed tools.

User data available anytime, anywhere

Any data the system collects from the user should be as available to him as possible. This means that it should be possible for the user to take it with him or her anywhere, to access it from multiple places, to hand it to external tools that may process it in ways that the original system is not capable of, to publish it to others and perhaps even read it without requiring mediation of the recording application. Definitely, it should be possible for the data to survive the application used to capture it.

Envisioned features supporting this need are:

• Well documented formats and protocols for storage, transmission and exchange of all user data.
• Wherever applicable, support existing open standards.

Multiple user and system interfaces

It should be acknowledged that there's an open ended list of possibilities for the user to interact with the system. In some cases, some data to be collected will be closely related to activities performed solely (or mostly) on the computer, or whose product will be stored in it: writing a document using a text processor, or writing a program using a development tool/IDE, thus good integration with them will be greatly useful.

In some other cases, data collection may not be even fully automated, but rather done manually at least in part, like when recording times and activities by hand in a notebook carried all along by the user whenever away from the computer. Also, different devices may be used at different times to collect data, like smart phones, or via a web interface while traveling, and all of them should collaborate to build an aggregated and unified repository of performance data for the user.

Envisioned features supporting this need are:

• Web services and/or similar provisions that facilitate access and inter-operation by third parties.
• System functionality packaged in components or libraries with documented APIs that facilitate reuse in complementary or supporting applications.
• Wherever applicable, support existing open standards.

Other Product Requirements

It should be researched yet specific standards and already existing specifications, but care should be taken to ensure they're friendly to Free Software based implementations. Also, a Gnu system (or some other Free Software-based stack) should be one of the primary platforms targeted since the beginning.