Tool Usage in Students’ Software Projects
Pekka Mäkiaho – Timo Poranen, University of Tampere, School of
Information Sciences
23rd of August, 2012
Background
• Two courses, year 2011-2012: SW Project management and Project work
• 14 projects, average size: 1331 working hours• 30 project managers, 67 developers• 5-10 ects• WWW-, desktop- and mobile phone –
applications• Free to select the set of SW tools
Tools in Software Developing projects
Project risks:– Technology risks– People risks– Organizational risks– Tool risks– Requirement risks– Estimation risks
SW tool categories:– Management tools– Development tools– Communication tools– Sharing and
documentation tools– Other tools
Research problem• Not a specific problem but getting an overview on:– the tools used in different categories– the processes that were used when selecting and changing
the set of tools– opinions on particular tools
• Target to improve course practices and teaching
Data gathering (1/3)• 3 Questionnaires during the course for all students• Extra questions to project managers• Observing the projects during the course in 6 reviews and by
weekly reports• Final reports after the projects
Data gathering (2/3)Q1 (1 month after the project start)– List all the tools you have used and on which purposes– Explain the method you used when selecting the tools
(PMs only)Q2 (in the middle of the projects)– Report any changes in tool usage– Explain the methods in tool changing (PMs)
Q3 (in the end of projects)– The same question on tool usage as in Q2
Data gathering (3/3)Tool selection process/reason categories:
– Own evaluation– Team member’s
recommendation– Client’s recom.– Course recom.– Earlier experience– Managers recom.– Free to use– To try a new tool– Related to project’s topic
Tool change reason categories:– Not all used the tool– A more suitable tool was
found– Tool did not work as expected– New need came– Not suitable technology to
use a tool– Not reported
An example project (1/3)(mobile application)
• Project management tools used (number of users)• Redmine (6), Kanbanery(5)
• Developing tools• Eclipse(4), AndroidSDK(1), RapidSVN(1)
• Communication tools• Email(5), IRC (5), Skype(1), SMS(1), Phone calls(1)
• Sharing and Documentation tools• GoogleDocs(4)
• Other tools• Stackoverflow(2), Photoshop(1)
An example project (2/3)(mobile application)
• Selection process • “Tools were evaluated and recommendations came
from all members. Also some tools came as given like Redmine Wiki from University and Android SDK from the client.”
• Foreseen tool risks• “Emulator performance issues”
• Unforeseen tool risks• “Android not being as open as we thought it is, Trying
Kanban without physical board, one computer broke”
An example project (3/3)(mobile application)
• Changes during the project• “It was noticed that UI-group did not use IRC and also,
that the information sent by project managers, just lost to the chat stream of developers. Thats why IRC was left only for developers and phpBB forum was taken to use as an official communication channel”• “Using of GoogleDocs increased during the project as
there were more documents to share.• “In the end of project fast communication was needed
so SMSs and phone calls were also used.”
Findings (1/4)• On average, 14 different SW Tools were used in a single
project.• 4.7 development tools in a project• Total number of dev tools was 32
• 14 of those not used by more than 1 student• Most used dev. tools
• Eclipse (32 users)• Netbeans (26)• MySQL(10)• However, these three were used only in 5 projects out
of 14
Findings (2/4)• The project management tools used in projects
• Redmine (11 projects) – recommended and provided by course• Wiki (3) – GoogleWiki, MediaWiki, DokuWiki• JIRA (2)
• Communication tools• On the top of phone calls, email and SMSs more than
half of students reported IRC, Skype, Facebook or Flowdock
Findings (3/4)• Personal experience had the most significant effect on the
tool selection process• 9 groups out of 14 mentioned “earlier experience”• “Managers recommendation” was mentioned by 7
groups• Only 1 group did not report any selection process / reason• More than half of groups did not report any (official) changes
on tools usage• Most frequently reported reasons for dropping a tool were
“not all used the tool” and “a more suitable tool was found”
Findings (4/4)• 12 tool related realized risks were reported in these 14
projects• 5 project reported foreseen risks
• Inexperience of project members• Technology issues
• 7 projects reported unforeseen risks• Wrong technology expectations• Users were not familiar enough with the tool selected
• 3 of these projects reported both foreseen and unforeseen risks
• 5 projects did not met tool related risks at all
Conclusions• Projects used on average 14 (min 8, max 23) tools• Personal experience had the most significant effect on the
tool selection process• Main reason for leaving a communication tool was lack of
commitment. (IRC, Skype) • SoMe (Facebook) was used a lot in communicating and in
management (meeting arrangements).
Further work• The correlation of tool selection and tool usage with the
process and product quality can be studied more precisely
• Continuous improvement of course's teaching practises