1. Introduction to the Softwareprojekt 2011: Software Engineering in Saros Karl Beecher

3. 3 The Project: What You Will Do ● Participate in the development of a growing, functional, free/open source software (FOSS) project. ● The project? Saros. ● An Eclipse plug-in developed by our department. ● The method? Team-based analysis and modification of the software. 1) Comprehension – learning the system and making a few fixes 2) Two mini-projects Maintenance – stabilise, improve, and correct the system Feature development – introducing new functionality into the system

4. 4 About Saros ● Eclipse plug-in (written in Java) ● “Enables two or more Eclipse developers to edit projects simultaneously in real-time over the Internet and share each others synchronised changes.” ● Communication ● Instant messaging ● VoIP (experimental) ● Screen-sharing (experimental) ● Distributed Whiteboard ● Roster ● Roles and Activities ● Read/write access control ● Follow-mode ● Shared viewport ● Edit highlighting

5. 5

6. 6 Demonstration

7. 7 Approximate Schedule 333435363738 Week Learning & Bug-fixing FeatureMaintenance Mini-projects

8. 8 Teams ● Working in teams (ideally four members per team) ● You should decide on your teams by Thursday 18 August ● Self managing ● Communication and meetings ● Keep in regular contact, make yourself available, co-ordinate effort, make assignments clear ● Coding ● Two heads are better than one ● Testing ● Just running it yourself is not enough! ● Reviewing

9. 9 Comprehension ● Learn about the Saros internals ● Only relevant parts (>60.000 LOC!) ● Architecture & patterns ● Rules ● Reusable components ● Code tours (JTourBus) ● Question sheet ● Documentation ● http://www.saros-project.org ● Learn by doing...

10. 10 Bug-fixing ● Believe it or not, Saros has bugs ● Sometime in the first two weeks you should start to fix bugs ● Some 'selected' bugs, concentrated in a specific area of Saros ● Bug tracker http://sourceforge.net/tracker/?group_id=167540&atid=843359 http://sourceforge.net/tracker/?group_id=167540&atid=843359 ● Bugs of your own discovery ● Not just limited to the first two weeks!

11. 11 Maintenance ● Weeks 35 – 36: work on a maintenance task ● Should now be working in your teams ● Task must involve some kind of maintenance ● Corrective ● Perfective ● Adaptive ● Can propose your own but I will suggest a list next week

12. 12 Feature ● Weeks 37 – 38: work on a feature ● Introduce some kind of new functionality to Saros ● Sources of inspiration: ● Feature request tracker (http://sourceforge.net/tracker/?group_id=167540&atid=843362)http://sourceforge.net/tracker/?group_id=167540&atid=843362 ● Yourself! What would you like to see? ● Me. I will provide a list of some suggested features in week 36. ● There is only two weeks, so the scope is not large (remember, that two weeks also includes testing, reviewing and fixing problems!)

13. 13 Procedures ● When you have registered your team with me, obtain team appointment time (short meeting every Monday from week 35) ● Presentations every Thursday, room 049 (from week 35) ● Each team will be asked to present their work ● Each member will be asked to talk about a particular aspect ● PC-pool rooms allocated for work ● We have the following rooms (in theory) every day between 08:00 and 18:00. ● Windows machines ● Rooms K44, K46 ● Linux machines ● Rooms K48, K38 ● Seminar room (049)

14. 14 Immediate schedule (week 33) ● First week is very important, much to do ● Monday and Tuesday: ● Think about whether you want to take part. ● Play with Saros, learn about it, think about who you will work with ● Wednesday: ● If you registered but decided not to take part you should email me. ● A list of bugs goes live. ● Thursday (Q&A session in 049 at 10:00) ● Registration. You must sign up if you wish to take part. Email me if you can't make it in person. No refusal if you were on original list. ● Register teams. ● ReviewBoard tutorial ● Friday ● Send me answers to question sheet. Any last minute group management

15. 15 Immediate schedule (week 34) ● Should spend most of this week bugfixing and continuing to familiarise yourself with Saros ● Monday: ● I will come around the rooms to answer your questions ● Wednesday: ● I will make a list of maintenance tasks available. ● Thursday: ● Q & A session in 049 at 10:00 about maintenance tasks ● Make a table available for each group to declare their choices ● Announce meeting times and presentation times for each group ● Tutorial about SVN and branch development

16. 16 Regular schedule (week 35 onwards) ● Monday: ● I meet with each team. What have you decided to do this week?Are you having any problems? Do you have any questions about your work? ● Tuesday – Wednesday: ● Development and preparing for presentation. ● Thursday: ● Presentation of work to rest of teams. ● Friday: ● Finishing week’s tasks and deciding course for next week. ● Final week includes a written report! ● Recount your experiences, evaluate the work you did (individually and as a team) ● More detailed criteria nearer the time...

17. 17 Grading ● Grade is a combination of both individual and team performance. ● Individual ● Your own contribution during presentations. Ability to present material and answer questions. ● Your end of course report. ● Participation in reviews. ● Team ● Quality of code (stability, conformance to standards) ● Overall quality of presentations ● Contributions “beyond call of duty”

18. 18 What Now? ● Questions ● Anything more you would like to know? ● Anything I did not make clear? ● Any problems you anticipate? ● Decide if you would like to be part of this project ● Get Eclipse, try it out ● Install Saros, try out a session with someone else ● Install JTourBus, read through the tours ● Explore www.saros-project.org ● Get the question sheet, begin to explore for the answers ● Not essential to form teams immediately, but the sooner the better; learning together is much more efficient than learning alone