Project

General

Profile

ProjectReport » History » Version 34

ancorgs, 2013-08-09 13:54

1 32
{{toc}}
2
3
Justification
4
=============
5
6
Scope
7
-----
8
9
The openSUSE Travel Support Program is sponsored by SUSE but managed independently by the openSUSE community by means of the Travel Commitee. The main goal of this project was to create a web based application to manage the requests and reimbursement in a convenient way.
10
11
Since other free software organizations (like GNOME, KDE or the Document Foundation) have similar programs, the original idea was to write a generic application including all the common features in order for it to be used, extended and adapted to fulfill the needs of any organization.
12
13
Functional requirements
14
-----------------------
15
16
The functional requirements can be summarized in three main goals:
17
18
* Close control over every single request and reimbursement with clear information for every involved person.
19 33 ancorgs
 * Information about the status of the process.
20
 * A well defined process and interface for applicants, committee members and administrative staff. 
21
 * Email notifications of any change and when some action is needed.
22
 * Email reminders if a particular request or reimbursement gets stuck in the same status for too much time.
23 32
* Good management of the program as a whole, both from an operative and from an economic point of view.
24 33 ancorgs
 * Fully structured information.
25
 * Useful reports.
26
 * Fixed or approximate budgets per period or per event, both as minimum warranted available amounts or as maximum limits.
27 32
* Working as a stand-alone application but with an optional integration into the existing openSUSE infrastructure
28 33 ancorgs
 * Integration into the openSUSE authentication system
29
 * Bidirectional integration with openSUSE Connect
30 32
31
Technical requirements
32
----------------------
33
34
From a technical perspective, the main requirements were:
35
36
* Full functionality available through web interface and through a REST json API.
37
* Themeable and responsive web interface.
38
* Flexible user system with pluggable backends (so the application can be integrated in previously existing users infrastructures).
39
* Robust control over information access and full log of information modifications.
40
* Fully documented with information automatically generated from the source code (diagrams, API documentation, etc.)
41
* Good tests coverage.
42
43 33 ancorgs
Development process
44 32
=======================
45
46
Milestones and tasks
47
--------------------
48
49
Following and iterative and agile approach, the project was divided into several milestones which are summarized below:
50
51
* Requirements capture and initial documentation
52 33 ancorgs
 * Document the requirement meeting: issue #215. 
53 32
* First prototype with the basic workflow
54 33 ancorgs
 * Implementation of the general infrastructure: issues #105, #121, #122, #123, #211
55
 * User management and access control implementation: issues #104, #106, #108, #109 
56
 * Request process implementation: issues #111, #113, #114, #115, #116
57
 * Reimbursement process implementation: issues #117, #118, #120
58
 * API and code refactoring: issues #196, #245
59
 * I18n: issue #125
60
 * Documentation: issues #126, #127
61
 * Deploy a test-drive installation: issue #246
62 32
* First finished version with basic workflow
63 33 ancorgs
 * Usability improvements: issues #249, #255
64
 * Email notifications: issues #250, #251
65
 * Automatic calculation of authorized amounts: issue #248
66
 * Tests for access control: issue #110
67
 * Fix automatic documentation generation: issue #312
68 32
* Fixes to requests, openSUSE integration and deployment
69 33 ancorgs
 * Landing page with user guide: issues #253, #371
70
 * Enhancements to the request process: issues #107, #112, #327, #329, #330, #366, #340
71
 * Audits, full log of information modifications: issue #256
72
 * Support for invitation letters management: issue #370
73
 * Added "final notes", to allow feedback on finished (canceled or accepted) requests: issue #254
74
 * Importing profile information from openSUSE Connect: issue #333
75
 * Bento theme: issue #332
76
 * Integration with openSUSE login system: issue #328
77
 * Deployment on openSUSE infrastructure: issues #331, #335, #365
78 32
* Support: post-deployment fixes
79 33 ancorgs
 * Only one task was needed. Add request creation deadline to events: issue #424.
80 32
* Reimbursement polishment
81 33 ancorgs
 * New workflow including signature and payment: issues #247, #119, #511, #540, #542, #545
82
 * PDF for the accounting department (SUSE specific feature): issue #549
83
 * Breadcrumbs: issue #555
84 32
* Reports and alarms
85 33 ancorgs
 * Totals in reimbursements and requests lists: issue #523
86
 * Expenses report: issue #547
87
 * Email reminders for pending actions: issue #252
88
 * Widgets for openSUSE Connect: issue #334
89 32
* Corner cases and alternative workflows
90 33 ancorgs
 * Request from Travel Committee members
91
 * Payment in advance (as opposed to reimbursement)
92 32
93
Achieved goals
94
--------------
95
96
The application has been successfully used to manage the request process for the openSUSE Conference 2013, with 15 accepted requests from a total of 24 and with no reported bugs, issues or complaints from any user. The reimbursement period for this event starts at July 22th. Although the request process worked smoothly, the reimbursement one is way more complex from both technical and administrative points of view, so the final result cannot be evaluated until the reimbursement period is over.
97
98
Regarding the functional goals, all of them have been achieved to a great extent, although some functionality is still missing.
99
100
* The tool provides a close control and accurate information for every single request and reimbursement for all involved users, with email notifications of every step. Email remainders about stuck operations are not yet implemented, but already planned in the currently open milestone.
101
* Good management of the program as a whole is also granted, with fully structured information and a very flexible expenses report with several filters and grouping options and with the possibility of exporting the result to a spreadsheet. Soft and hard budget limits per period and event are not yet implemented.
102
* The application can work both stand-alone and inside the existing openSUSE infrastructure
103
104
All the technical goals have also been met.
105
106
* The web interface is fully functional and the REST API has been completely developed. The latter could need some refinement in the future, since it have not been used in a real production environment.
107
* The themeable and responsive web interface is based on Bootstrap, the most widely used framework for web front-end development. The interface was developed in a very generic way so it should be really easy to extract a "bento" theme for Bootstrap from the current TSP app allowing to theme any Bootstrap based application according to the openSUSE look&feel. 
108
* Devise, the most widely used system for user authentication in Ruby on Rails, was used to ensure connectivity. An openSUSE backend was developed. So integrating future Ruby on Rails applications into the openSUSE authentication infrastructure should be almost trivial.
109
* All the database changes are logged by the application.
110
* 85% of all classes, functions, methods and modules are fully documented (according to yardoc, the tool being used for generating the documentation).
111
* Automated test have been developed for most of the functionality, including unit tests and integration tests.
112
113
Pending issues
114
--------------
115
116
The development is not over yet.
117
118
* Some minor issues still needs to be closed in order to finish the two open milestones.
119
* As exposed in the "achieved goals" section, there is no interface yet for specifying budgets and limits for events or periods.
120
* The definition and implementation of the milestone titled "corner cases and alternative workflows" will be probably delayed until the end of the openSUSE Conference 2013.
121
122
On the other hand, some generic tools and libraries have been developed during the process, like the Bento theme for Bootstrap or the openSUSE backend for Devise (both mentioned in the "achieved goals" section). Some work should be invested in extracting them as individual projects with its own documentation in order to be really reusable by other people in other projects.
123
124
The people in charge of the GNOME’s Conference Travel Subsidy Program are currently evaluating the tool as they have very similar needs. We are waiting for feedback from them. 
125
126
Resources
127
---------
128
129
The whole project was developed by only one programmer. Chiliproject was used to track the development effort. The table below shows the approximate number of hours invested in every milestone, according to the information registered in chiliproject with some manual adjustments. The table does not include administrative tasks like writing reports or managing the chiliproject issues.  
130
131 34 ancorgs
Milestone|Hours (aprox.)
132
---------|--------------
133
Requirements capture and initial documentation|8
134
First prototype with the basic workflow|68
135
First finished version with basic workflow|14
136
Fixes to requests, openSUSE integration and deployment|61
137
Support: post-deployment fixes|2
138
Reimbursement polishment|31
139
Reports and alarms|22
140
Corner cases and alternative workflows|0
141
Total|206
142 32
143
A considerable amount of effort has also been invested in promoting the tool: presentations, blog posts, test-drive installation for the GNOME project members, etc. This effort is not considered in the current report.
144
145
Conclusions
146
===========
147
148
References
149
==========