http://www.hut.fi/~llauren/76115/documents/vm.html
Version 2.0
Last updated 31.10.1999
| Version 1.0 | 13.10.1999 | Juha Itkonen | New document |
| Version 2.0 | 3.11.1999 | Juha Itkonen | Updated and a lot of introductory text added to chapters 1 and 2. |
1. Introduction
2. Overview
3. Functions
4. External Interfaces
5. Non-functional Requirements
6. Quality Criteria
When will the software be ready? Though a common question, few software developers seem to know an answer to this, bearing notable correlation with reality. Early British computer scientist Douglas Hartree once said: "The time from now until the completion of the project tends to become constant." This answer however, is not satisfactory in the software industry these days, where workload and personnel asset management is critical.
The Personal Software Process (PSP) is a method for the software developer to estimate and keep track on the time, resources and efforts needed to develop a software. It is not a method for effectivating the software development, but rather a tool for the developer to estimate the required effort to plan and realize the software, to improve the estimating skills and to focus on the programmer's own bottlenecks, problems and issues, and perhaps through this improve on his/her programming skills.
A lot of the PSP effort goes into documenting the whole software development process, which can be a rather exhaustive job. The PSP-HUT system aims to ease some of the documenting load and lower the threshold for a software developer to use, begin to use or continue to use the PSP process as a tool for his or her development. It is not a tool to keep track of the hours sat at work or for the management to monitor the programmers' activities. The PSP-HUT system is a tool for the individual to monitor his or her software development progress.
The PSP-HUT system is also a collaborative tool for users to work in groups, both in a working and educational environment. The user may compare his or her "PSP scoring" to the group's statistics (but never to any other individual) both in numerical and graphical terms. The groups have tools for communicating within the group, both real-time and asynchronously (i.e. chat and newsgroups) to share their thoughts, exchange ideas or discuss the group's tasks, the PSP or any other issues.
The PSP-HUT system is being developed by the PSP Hang-around Group (PSP-HAG) as a project for the one-year Software
Project course (Tik-76.115) at the Helsinki University of Technology. The goal of the project is to build a PSP
community server using Internet technology. One of the main goals of the system is to make learning and practicing
the PSP as simple, easy and enjoyable as possible. Emphasis will be placed more on the usability of the core functions
of the system than on the amount of features implemented.
The Personal Software Process (PSP) is a disciplined approach for teaching software engineers basic principles of software engineering, such as planning, time management, defect prevention, tracking, and removal. The PSP is a staged approach, in which new, more advanced practices are introduced only when the earlier ones have been applied for some time. The PSP has been shown to lead to drastic improvements in the engineer's ability to estimate and plan his own software development work, as well as produce higher quality products.
The PSP demands the practitioner to do quite a lot of measurements and data analysis, a process which is cumbersome to do manually. The PSP-HUT community server system is designed to allow the PSP student or practitioner to easily and efficiently input his data, and help him to get the necessary feedback with a minimum of overhead on his part.
The system is designed for professional software developers who will use it to collect their personal PSP data and analyze it. The system also provides a possibility to organize and maintain PSP courses in which students can learn by reading lessons and instructions and doing assignments following the PSP process and inputting their metrics data to the server.
There are several different ways to use the PSP-HUT system. For instance, the system could be used as an internal intranet service in some organization. Another scenario could be a PSP Service Provider using the PSP-HUT system to provide a public or restricted service for other organizations or individual professionals. In this scenario, the billing becomes an issue that must be taken into consideration. The third scenario could involve some educational use for example at universities.
The system consists of a www server, a MESS metrics server and several client applications. The users use the system over public Internet, an extranet or an intranet. Standard Internet technologies are used and the system does not set any exceptional requirements for the network. The basic functionality for the user is provided using html and possibly Java applets. This means that a standard WWW browser is enough to use the system. However, to use the more advanced data collector components the user has to download and install these separately.
Picture 1: The high level architecture of the PSP-HUT system
The system specifies a well-defined data collection and retrieving interface. This interface is utilized by developing
advanced tools for data collection. These tools can be stand-alone Java applications or plug-in components for
development tools, for example. These data collector tools also allow off-line data collecting. The data collection
interface can later (after this project) be used to extend and develop this system.
The Lucos research project at TAI Research Centre has developed
a system for metrics visualization on the Web. This system is to be used for the graphical representation of the
PSP data.
The system supports using of PSP both for studying it and for applying it in own SW engineering activities. Anyone interested in using PSP and having access to the system can register to be a PSP user. The system supports PSP user in practicing the original PSP (levels, practices and metrics) defined by SEI. In addition to the PSP defined by SEI, the system enables server, user and group specific tailoring of the PSP.
The system also supports group work, benchmarking and communicating between PSP users. For these purposes the system offers the possibility to form PSP user groups. The purpose of the groups can be, e.g., arranging PSP courses, discussing with similar kind of PSP users, working in a SW project applying PSP or having the possibility to create benchmarking data among similar types of PSP users. Each group has a group leader who is responsible for the administration of the group.
In addition, the system must have a root who is responsible for the administration of the whole system.
Related to benchmarking, the system must offer the possibility to deny the use of own PSP data for benchmarking purposes. To guarantee that PSP users can take the most out of PSP, i.e., can be totally honest with the data they input to the system, they have to be confident that the data is for their personal use only. That means that system must take care that nobody except the PSP user him/herself is able to see personal PSP data.
In this chapter, each of these functions is described as a more detailed individual requirement. The used format is described below.
Priority: MUST
Required permission level: none
Additional information: When person registers to the system as a PSP user, certain basic user information
is attached to the user. This basic user information enables:
Based on these requirements the basic user information can include:
Priority: MUST
Required permission level: PSP user
Additional information: none
Priority: MUST
Required permission level: Root
Additional information: none
Priority: USEFUL
Required permission level: PSP user
Additional information: Request for new group requires certain basic group information. This information
enables:
Based on these requirements the basic group information can include:
Priority: USEFUL
Required permission level: Root
Additional information: none
Priority: USEFUL
Required permission level: Group Leader
Additional information: Updating includes permission to add additional group leaders and remove group leaders.
Removing of group leader is possible only if there is more than one group leader in the group.
Priority: USEFUL
Required permission level: Root
Additional information: none
Priority: USEFUL
Required permission level: PSP user
Additional information: none
Priority: USEFUL
Required permission level: PSP user
Additional information: none
Priority: USEFUL
Required permission level: Group Leader
Additional information: none
Priority: USEFUL
Required permission level: PSP user
Additional information: none
Priority: USEFUL
Required permission level: Group Leader
Additional information: none
Priority: MUST
Required permission level: PSP user, with capability to teach PSP
Additional information: Idea is that there is group of PSP teachers that are allowed to create official
PSP courses and exercises which group leaders can use in course type groups.
Priority: USEFUL
Required permission level: PSP user
Additional information: none
Priority: USEFUL
Required permission level: PSP user
Additional information: none
Priority: NICE TO HAVE
Required permission level: PSP user
Additional information: none
Priority: MUST
Required permission level: PSP user
Additional information: PSP work is either a course exercise or an own SW engineering job (i.e. not related
to any particular group) or a SW engineering job implemented in a group. PSP work is created by identification
that attaches the work at least to the PSP user and possibly also to a certain group. For profiling and statistical
purposes the PSP work can also be identified as exercise or actual job.
Priority: MUST
Required permission level: PSP user
Additional information: PSP user must be able to find the PSP work with the existing PSP data that she/he
has already recorded for the job to enable the data to be recorded either in small pieces or all at once.
Priority: MUST
Required permission level: PSP user
Additional information: none
Priority: MUST
Required permission level: PSP user
Additional information: none
Priority: MUST
Required permission level: PSP user
Additional information: PSP user's basic right is permission to view his/her own personal PSP data both
in raw data form and in visual form. In addition PSP user can view profiled statistical PSP data from those groups
that he/she participates. Similar profiled statistic type data can be viewed also about all PSP users and groups
that have accepted the use of their PSP data in benchmarking and statistical purposes. Group leader of a course
type group has also right to see personal PSP data of group members including only the PSP data that has been produced
in the course.
Priority: MUST
Required permission level: PSP user
Additional information: Permissions are same that of viewing the PSP data, see Requirement
3.21.
Priority: MUST
Required permission level: PSP user
Additional information: This possibility is available to enable manual data gathering.
Priority: MUST
Required permission level: PSP user
Additional information: none
Priority: MUST
Required permission level: not applicable
Additional information: none
Priority: MUST
Required permission level: not applicable
Additional information: none
The main user interface is a WWW browser. The browser interface is used for registration and for keeping the user and group properties up to date. All the actual PSP functionality is available through the browser as well, but the browser interface supports only form-based insertion of data. The preferred way to collect data is to use separate data collector programs.
The interface used to submit the data collected by the data collectors is implemented using XML (Extensible Markup Language) files. The specification of the contents of the XML file is designed in a way that makes it possible for various data sources to submit data to the system. This approach hides the details of different data sources from the receiver and on the other hand makes it easy to use the collected data for some other purposes as well. It also makes it very convenient to add new data collectors to the system later without making any changes to the already implemented parts of the system. The XML files are transferred to the server over an HTTP connection. It is easy and relatively simple to implement also other, alternative ways to transfer the data, for example FTP, e-mail, or Java RMI.
The interface to the database is based on LUCOS Server Protocol Specification version 1.14. If a need arises,
some features may be added to the protocol with help from the LUCOS development team.
See also the chapter 6. Quality Criteria.
Good usability is one of the most important requirements of the system. The main objectives of usability are:
The system is provided with good quality user documentation which is complete, correct, unambiguous, consistent, modifiable and written in English.
See also the chapter 6. Quality Criteria.
The system is provided with good quality technical documentation which is complete, correct, unambiguous, consistent, modifiable and written in English.
The system interfaces support the adding of new components and features. Interfaces are carefully defined and clearly documented. If and only if there is time, some specification work could be done to define the alternatives for charging interface.
System architecture is clearly structured and forms a core which is easy to expand in future versions.
See also the chapter 6. Quality Criteria.
Response time of data input and calculation operations is less than 1.0 s in undisturbed 100 Mbit/s local area network with unloaded server. (The delay caused by the components provided by customer (Visualization applet ViCa and measurement database Mess) is excluded.)
Response time must not increase exponentially in relation to the increase of the amount of the users when amount of users stays under 1000. (The delay caused by the components provided by customer (Visualization applet ViCa and measurement database Mess) is excluded.)
Client software works both with Netscape and MS Internet Explorer (version 4.0 or bigger) browsers.
Server works both in Linux and Windows NT 4.0 SP5 environments.
Most important things the customer wants from the system are:
It is clearly indicated by the customer that it is far more important to develop good architectural basis for the system with well functioning core features than try to implement all possible nice to have functionalities with only partial solutions. This is always considered carefully in case new functionalities are required by the customer after this requirement specification has been approved.
From these expectations following issues have been prioritized to form the quality criteria of the project success.
Well functioning core features: All the requirements prioritized as MUST from the chapter 3. Functions.
The SW development process and practices are carefully planned before starting the work in each phase of the project. Features are developed based on principles of incremental SW development to ensure that the most critical ones get implemented first. Quality of design and implementation is assured by reviews and careful testing of each increment. For more information about SW development practices see Project Plan.
The correct functioning of the core features is verified and results reported with properly planned and executed
functional testing.
Good usability (including the requirements related to response time): Requirement 5.1.1 Requirement 5.4.
Usability is achieved by putting effort on designing the user interface, prototyping and producing clear user instructions. In inspections there is always one inspector which has assigned role to check the material from the usability point of view.
Usability is verified and results reported with properly planned and executed usability testing, heuristic evaluation
and cognitive inspection.
Clear Architecture: Requirement 5.2.3
This is achieved by putting effort on thorough architectural design based on KISS (Keep It Simple, Stupid) heuristic and producing clear technical documentation. Close co-operation with the instructors is needed. In inspections there is always one inspector which has assigned role to check the material from the KISS point of view.
The architectural structure of the system is verified subjectively by the customer/instructors already during
the early architectural design phases. Architecture is reviewed together with the customer to get acceptance and
verification that selected architectural solutions fulfill the quality criteria.
Well Defined Interfaces and expandability (makes the adding of new features easy): Requirement 5.2.2
This is achieved by putting effort on thorough interface design and well defined interface documentation. Close co-operation with the instructors is needed. In inspections there is always one inspector which has assigned role to check the material from the interface point of view.
The interfaces of the system are verified subjectively by the customer/instructors already during the early
interface design phases. Interface design is reviewed together with the customer to get acceptance and verification
that interface design fulfills the quality criteria.
Quality of the Technical Documentation: Requirement 5.2.1
This is achieved by putting effort on technical documentation, coding standards and proper commenting of the code. A style guide for programming and technical documentation for this project is created before the design phase starts. In inspections there is always one inspector which has assigned role to check the material from the mentioned documentation criteria point of view (complete, correct, unambiguous, consistent, modifiable and written in English. Consistency with parent document(s) is always inspected.
The style guide and the technical documentation is reviewed together with the customer/instructors to get acceptance
and verification that technical documentation fulfills the quality criteria.
Quality of the User Documentation: Requirement 5.1.2
The reason for quality of user instructions being only in priority 6 is to tackle the usability challenge rather with appropriate and simple user interface than with documentation.
This is achieved by putting effort on technical documentation. In inspections there is always one inspector which has assigned role to check the material from the mentioned documentation criteria point of view.
The quality of user instructions is verified and reported with functional and usability testing.
Well functioning useful features: All the requirements prioritized as USEFUL from the chapter 3. Functions.
The SW development process and practices are carefully planned before starting the work in each phase of the project. Features are developed based on principles of incremental SW development to ensure that the most critical ones get implemented first. Quality of design and implementation is assured by reviews and careful testing of each increment. For more information about SW development practices see Project Plan.
The correct functioning of the features is verified and results reported with properly planned and executed
functional testing.
Well functioning nice to have features: All the requirements prioritized as NICE TO HAVE from the chapter 3. Functions.
The SW development process and practices are carefully planned before starting the work in each phase of the project. Features are developed based on principles of incremental SW development to ensure that the most critical ones get implemented first. Quality of design and implementation is assured by reviews and careful testing of each increment. For more information about SW development practices see Project Plan.
The correct functioning of the features is verified and results reported with properly planned and executed functional testing.