Under a broad comprehension of Software Engineering, it is preferred the term software life cycle instead of just software production. The reason is that cycle starts at software conception and stops when the software is relegated. Given contemporary companies’ market strategies of focusing on their competitive advantages, most of them have externalized their software production to outsourced services. Therefore, the call for software tenders has become a common step in the software life cycle. In this paper, we present a tool which aids non-experts to specify call for software tenders. The motivation was Chile situation of most of rural and semi-urban city halls which do not have engineering teams to build call for software tenders. We describe the problem in terms of lack of competitiveness and empty biddings generated by low quality calls for tenders. As a second step, we show the technical considerations to develop the proposed tool and its features. We include an initial tool perception from a first group of users.
From three decades ago, outsourcing has been a clear industry mainstream [
Due to transparency issues, most of the countries publish their demands of external services on public web sites, e.g. Brasil on www.comrprasnet.gov.br, Mexico on compranet.gob.mx, Ecuador on compras publicas. gob.ec.
Therefore, different enterprises study these elicitation documents and make the decision of applying based on their contents. Acquiring products and services using this way normally means getting specialized consulting and ensured results.
In particular, since October 2004, in Chile came into force a law about public acquisitions which regulates government’s demands and makes mandatory to publish elicitation documents on its purchases’ web site. Al- though the law is not explicit, it is understood that it includes the purchase of software products and services as developing or maintaining software systems [
In spite of requirements, engineering approaches assume and recommend building a call for tenders after re- quirements elicitation [
In addition, we have also detected a big proportion of low quality CST documents. Although we could specu- late and theorize about reasons, the fact is that these documents do not include a minimal set of wanted functions, they do not describe organizational actors, and most of the time they include neither non-functional require- ments, nor basic project stages, nor their corresponding deliverables.
We have previously sustained that software-bidding process requires new supporting mechanisms and specif- ic procedures for both, tenders and demanders [
In this paper, we present a web-based software for supporting the creation of CSTs. We have joined main management topics such as budget, project stages and deliverables to the known structure of IEEE830 software requirements standard [
This paper has been sorted under the following structure: In Section 2, we present the problem in terms of quantitative and qualitative descriptions: quantitative descriptions correspond to metrics based on content ana- lyses whilst qualitative descriptions are based on descriptions which were gathered in a focus group session of experienced software tenders and by our own contact with these governmental units. In Section 3, we present the assumptions which have guided us to the current design of the human-computer interaction (HCI) and function- ality. Here, we briefly present the first experience and perception of a small set of initial users. In Section 4, we show the basics of software architecture which allow us easily modifying sections and examples of CSTs. Fi- nally, in Section 5, we summarize the conclusions and present the planned future work, mainly related to valida- tion of the tool and its impact on local governments. Besides, we add ideas about how to improve the collective construction of CSTs in new versions of T2R2-Software.
The main motivation for developing the tool for software bidding were our findings related to the gap between requirements engineering recommendations (e.g. see [
Moreover, we have previously affirmed that CSTs are different from software requirements specifications (SRSs) [
In order to complete the scenario, other studies support the idea that CSTs only contain a first approach to a requirements elicitation stage [
Our first qualitative approach to the problem was by reviewing the set of best proposals. These calls corres- pond to municipalities of main cities and ministries. As a constant, all worst proposals (from the point of view of expected content) were from rural municipalities. This approach also included gathering some initial informa- tion of these offices. Calling to the corresponding people in charge we normally found technical people from management (normally supporting purchasers in general) and few times technical computing professionals. We called to more than 30 rural municipalities from the south zone of Chile; none of them have a software engineer for carrying out the software procurement process. Therefore, a relevant finding here was that a critical stage of a software life cycle is being developed by people without training on software project matters.
We are absolutely convinced that studying this phenomena worth the effort. But, at the same time, we do not want to wait to have a complete understanding of this phenomenon to try to improve it. We would like to con- tribute now to some initial solution by providing a recommender system which aids to existing people in charge to build better CSTs. We believe that studying some eventual adoption and their results could give us a better understanding than studying the phenomenon just as external observers.
Therefore, we have not proposed a general-term solution to the problem of building a proper CST document, but, we are trying to provide a tailored tool for the specific situation of software public procurements from rural and semi-urban municipalities of Chile.
In this section, we review traditional concepts of HCI design and how they have been applied to the design of our T2R2-Software tool.
We start applying the concept of affordance. In [
The fourth affordance type is sensory affordance, defined as the feature that helps, aids, supports, facilitates, or enables the user in sensing. At this respect the main added feature is the seeing the visual summary of com- pleted, empty and editing document sections.
A second HCI design principle is reducing cognitive overhead. It has simply defined as the challenge of si- multaneously maintaining several tasks [
Learnability has been another point where we have focused our design. Given that the concept of learnability has several acceptations, we have used some ideas from the framework presented in [
Accessing examples for implementing functional affordance
It shows section states for implementing sensory affordance
The second idea of this learnability framework includes the concept of extended learnability, which means to consider how efficiency could be improved over time. To this point we consider that existing CST can be used as initial patterns of new ones. Therefore, experience is not just a matter of recognizing buttons and functionality, but also of having a growing set of documents which can be continually improved and reused.
Finally, also a classical HCI design principle is user satisfaction which is considered an elusive concept hav- ing different approaches to measure it [
We have considered each of these items in the following adapted manners: 1) system effectiveness measure how well the proposed tool accomplish its goal, i.e. the construction of a CST document. In the case of T2R2, we have not just provided an adequate and known user interface but also we have provided an additional func- tion for producing the final document in PDF format, due to the Chilean public platform accepts documents in this format. We have also been award of 2) user effectiveness by providing explanations and examples of the needed sections of the expected document. In general, this factor is closely related to the concept of affordance. 3) Under the same principle we have designed the tool to facilitate the current manual task of specifying a CST. Therefore, the user total effort (given their features) is effectively reduced. Finally, in all cases we have consi- dered 4) user characteristics. In fact, from the beginning we have characterized the expected user in his/her business context due to he/she presents particular education and role in their institutions.
Finally, and in spite of the different approaches to measure user satisfaction, there is a common way which includes applying some instrument in order to know their perception. In the case of T2R2-Software, we have presented our resulting tool to a group of 6 users that works on rural municipalities and their job include speci- fying CSTs. The related profile of participants is presented in
To these participants we explained the tool on two sessions of one and half hour. After that, we applied a usa- bility questionnaire. The results are showed in
. Profile of participants
Participant | Exp (Years) | Dedication to CSTs (%) | Hours to specify a simple CST | Hours to specify a complex CST |
---|---|---|---|---|
1 | 5 to 6 | 0% - 15% | 0 - 4 | 21 - 50 |
2 | Less than 1 | 0% - 15% | - | - |
3 | Less than 1 | 0% - 15% | 0 - 4 | 0 - 4 |
4 | More than 6 | 31% - 50% | 5 - 20 | 51 - 100 |
5 | 1 to 2 | 0% - 15% | 5 - 20 | 5 - 20 |
6 | Less than 1 | 0% - 15% | 0 - 4 | 0 - 4 |
. Answers from participants
Participant | T2R2 helps to get a high quality CST | T2R2 helps to save time | T2R2 is simple of using |
---|---|---|---|
1 | 9 | 8 | 9 |
2 | 10 | 5 | 6 |
3 | 10 | 10 | 5 |
4 | 10 | 9 | 8 |
5 | 10 | 10 | 7 |
6 | 10 | 10 | 10 |
In order to show the architecture we describe three main components: 1) technological platform, 2) conceptual architecture; 3) functional architecture. Finally given secondary research goals, i.e. to understand the process of generating call for tenders, we have also reported the basis of T2R2-Software’s log system.
From the technical point of view the application is a web-based software product using a MySQL database. It has been programmed in Java Server Pages (JSP) using a package of Java classes corresponding to the business layer. Therefore, T2R2 only requires the HTML virtual machines incorporated into Internet browsers and an In- ternet point for accessing the web site.
We have used UML class diagrams to show the main modeled concepts and the corresponding object collections which constitute the conceptual model (business layer) of our application. In
The Governmental Office class represents the collection of all purchasing organizations from state. The re- presentation corresponds to a simple model of state management offices or units. The dependencies (hierarchy) among them have not been modeled. This class has been associated to Software Specifier, which represents the collection of persons who have the task of purchasing some software product; thus, they have to make a CST. The multiplicity of the association between Software Specifier and Governmental Office is many-to-many be- cause we have considered that a person can change his/her job from one state unit to another or even it is possi- ble that a person works part-time for more than one state unit. Moreover, Software Specifier has the stereotype <
Conceptual model for T2R2
We also have modeled that an object from Software Specifier could have many specifications or CSTs. Therefore we have an association from Software Specifier to CST. However, an object from CST must have just only one creator or owner. At once, an object from CST has a set of sections and subsections. In our model, it is not necessary to specify some aggregation between CST and DocumentSection because it is assumed that each CST has all active document sections which conforms the collection represented by the class DocumentSection. However, the association to DocumentSubsection is justified because we need to know the specific text content and its corresponding current state (represented by the enumeration SubsectionState).
In order to make a clear model we have added some objects from more relevant classes (blue boxes). Thus a specific CST may be for acquiring a Courses Management Software—in Chile, municipalities control most of public schools. This document has a section namely “non-functional requirements” (sec object) and into this, there is a subsection dedicated to security (subsec object). For simplicity of both, implementation and document structure, we have made the decision of keeping these classes as two different classes and not as the same class having some recursive association.
We have used UML use cases for specifying the functionality components. Due to the common misuse of spe- cifying use cases as actors’ actions or intentions, it is worth to clear that according to UML [
Firstly the main system’ actor is the Software Specifier, but not the only one, we also have a separated dia- gram for system administrator who should be in charge of users management. Due to the system was conceived as part of purchasing state platform then the Software Specifier is someone that has access to publish calls for purchasing. We have called him/her state purchaser.
Functional components of T2R2-Software
In order to track the project we have enumerated the use cases. The main interactions are offered for viewing existing CSTs (T2R2-10), or creating a new one (T2R2-01). However, we have added a third main function which deals with offering to work on the last document under edition (T2R2-02). These three main use cases have an association to the Software Specifier. We have also included the choice of creating a new CST starting from an existing one (T2R2-04). In order to get some help we provide two functionalities, an abstract explana- tion of a specific subsection (T2R2-05) and two examples of right paragraphs related to specific domains (T2R2-06). For these examples a relevant and useful function is putting the example as part of the editing doc- ument (T2R2-12). As part of the documentation we designed the choice of uploading images (T2R2-08), how- ever, it is a feature that we have let down in order to avoid the common practice of uploading the entire call for tender as an image or set of images—due to documents are first printed and then scanned. Finally we have also represented two simple but fundamental explicit actions such as saving the CST (T2R2-07) and producing the PDF (T2R2-09) which should be later upload into the state purchasing platform.
As it is a problem over which we are still under study, a secondary goal is to gather additional information about the phenomena of formulating a CST. We are very interested on study de behavior of software specifiers. Therefore, a log system seems crucial. Hence we have designed a product that store dates, times and changes on documents. In
Finally, in regard to testing effort, we have made a white box exhaustive testing, which most of the time im- plied refactoring tasks in order to keep separate user interface and business concerns. Unit testing did not really mean a problem. However, at the level of integrated testing, we needed to add some additional functionality in order to allow that two or more users were working using the same user account (which was detected as a com- mon practice in governmental offices). Stress testing has not been considered, under a normal year it is possible to reach 400 CSTs, if we consider three months of low activity (September by independence holidays, Decem- ber by Christmas and February by summer vacations) we have a maximum of 45 CSTs by month, which do not really stress a contemporary web-based system.
In this paper, we have presented T2R2-Software, a tool for aiding software purchasers in the task of generating a call for software tenders. We have presented the problem as a software engineering problem because software life cycle includes from initial conception to software relegation. Therefore, making a call for tender is part of the cycle. We have also argued that there are differences between theoretical and practical issues about pro- ducing calls for software tenders. We have considered the quality of state calls for software tenders in Chile. According to this, we have provided a specific solution for rural and semi-urban municipalities because their calls comparatively present lower quality.
As part of the tool presentation, we have showed main HCI and architectural considerations which have in- cluded an initial users’ perception of the tool and the design of the log system to gather additional information for trying to get an improved understanding about the variables behind the creation of calls for software tenders.
As future work, we hope incorporating features such as: 1) ability to import/export technical documents from XML format, 2) ability to share technical documents in XML format between different users, and 3) ability to easily search complete documents or existing paragraphs. The features 2) and 3) mean to have a collective im- pulse in order to share not only phrases but also, what they have implied in the particular software projects which can be imported by the editing call.
In the scientific part, we want to empirically validate T2R2-Software as a useful tool. It means to approach a good measure of quality of the published calls. Moreover, we are interested in the results referred to the soft- ware quality of improved calls. We have already progressed on this quality model and also on other tool which allows getting simple metrics from CST documents.
From the social point of view, we expect benefits for state units from rural and semi-urban municipalities
Log model of T2R2
which may imply that they have better software products to really manage their resources and accomplish their social goals.
This work has been sponsored by the Investigation Direction, University of La Frontera, Temuco, Chile, DIUFRO DI13-0068 Project.