| 1 | = Development Process Notes = |
| 2 | This project assumed a high didactic worth, not only in Operating System |
| 3 | [wiki:doc/devel development] related matters or in C programming, but also in |
| 4 | development process itself and its collaborative characterization. Right ahead, |
| 5 | you will find some notes about team's conduct of development, deeply describing |
| 6 | its way of development taking a look to its approach to analysis, to the applied |
| 7 | techniques and to the used tools. |
| 8 | |
| 9 | == Approach == |
| 10 | As you can notice while reading "Development notes", developers team appreciates |
| 11 | high-level '''analysis''' of problems, in order to dominate project complexity |
| 12 | and to understand the aim of specifications, and of project itself. Because of |
| 13 | the risk that this kind of approach remains superficial, it must be followed by |
| 14 | a in-depth analysis, with the purpose to structure internal mechanisms, allowing |
| 15 | insertion of little code [wiki:doc/devel#a2.Internalfunctionstricks hacks]. |
| 16 | Only this kind of dual analysis allow a final and complete '''understanding'''. |
| 17 | Such duality has been also applied in team planning, clearly separating design |
| 18 | time and implementation time, '''discussion''' one and coding one in order to |
| 19 | avoid wastes in terms of time and psychic resources. |
| 20 | |
| 21 | == Strategies == |
| 22 | After knowing of Xtreme Programming methodologies (thanks to SW Engineering |
| 23 | course), we dared trying to apply its paradigm onto our development process, in |
| 24 | order to enjoy its benefits. As mentioned above, we started each day with a |
| 25 | stand-up meeting for planning activities, but we also learned how to code |
| 26 | together, with only one person at keyboard, or how to write code according to |
| 27 | previously agreed standards. |
| 28 | |
| 29 | == Collaborative Tools == |
| 30 | Collaborative work is not easy, because of all troubles originated from |
| 31 | synchronization matters among developers. That is the reason of our experiencing |
| 32 | new tools, aimed to help us in such difficult jobs. |
| 33 | |
| 34 | One of these is `subversion` a versioning substsyem, which trace every changes |
| 35 | to the code and offer a set of features that makes merging/branching operations |
| 36 | easier. In addition to this, and according to XP teaching, we took advantage from |
| 37 | subversion's tagging utility for frequently releasing "stable" sub-version. |
| 38 | [[BR]] |
| 39 | Our public subversion repository is available at [svn://svn.xt3.it/var/svn/kaya]. |
| 40 | |
| 41 | Another usefull tool is a web-based software project management: `trac`. |
| 42 | It offers a complete system, including an enhanced wiki, where we wrote (and will |
| 43 | write) kaya project documentation, an issue tracking system based on tickets, and |
| 44 | others features favoring planning. |
| 45 | [[BR]] |
| 46 | trac web interface for this project is online (we hope!) at [svn://trac.xt3.it/kaya]. |
| 47 | |
| 48 | As you can see both services are proudly hosted by [http://www.xt3.it xt3.it], an experimental team |
| 49 | composed by two of us. |