UCOSP

Undergraduate Capstone Open Source Projects

The software development process of Basie

Posted by Josh McCarthy on 2009/10/20

Recently I attempted to describe what kind of process we used while developing Basie. My first shot at the definition was a little off, but it turns out that there is no clear definition for how we  do things. I’m looking for some feedback from fellow students on what they think of our current process and how they would go about defining it. I’m planning on coming up with another revision of this definition once I hear what others have to say. I’m sure there are people out there who have plenty of experience when it comes to this, so please, check out the Basie blog. I would love to hear your feedback.

6 Responses to “The software development process of Basie”

  1. Eric Henry said

    On the Thunderbird team, as far as I can tell we have been very loosely following the Scrum development process (whether that has been on purpose or not, I don’t really know). At this point in the semester we have two primary goals for our project: to have tests for as much of the code as possible, and to patch as many bugs as we can that will have problems for the release of Thunderbird 3 (ideally all of them would be patched). To achieve this goal, we have been having weekly conference calls where we discuss what we have been doing the past week and what we plan on doing the next week. If we are ever confused about what we should do next, we discuss what there is to be done and go from there. Often we will look to our team lead for an indicator of the priorities of a set of tasks so that we can be working towards the most important tasks first. As we have code to check in, we use Mozilla’s bugzilla software to post our patch, assigning our patch to be reviewed by our team lead. If our patch receives one good review, it waits for a second and then gets committed to the repository. If our patch doesn’t pass the review, we make our necessary changes and resubmit.

    This process has been working quite well for the Thunderbird team, though it has not been without its problems. For the most part I have always had a good idea of what I need to do and whether or not I am on target. We have been able to easily shift gears when new things come up, and our code is always examined before it “goes into production”. I’m sure I’m forgetting something, but the only problem that I have seen is when we underestimate the amount of time needed to complete our task(s).

  2. Mé... said

    Hi Josh,

    Your post is very interesting. You introduce very good questions and many things in your reasoning deserves our attention.

    Let me explain our team development process, how it works for us and what could be improved.

    Markus is composed of around 8 people and most of us are newcomers. Of course, we are not by ourselves and have access to experienced people if any questions. We have great proactive project leaders, very important aspect to remain motivated and focused on what really worth for the project.

    We meet every week on IRC where we principally talk about our roadblocks. The goal here is to find solutions in order to continue the development for the next week. It is important though to not wait for a meeting to solve issues and fortunately, we have blog where we can share about everything… Communication is very important and IRC, blog and mailing lists are there to achieve it. I like to be able to go back into any conversation we had, and IRC logs gives us that possibility.

    I think that our implication in the project can be divided in two main orientations, which are maintenance and new development. Maintenance is small improvement to the software that comes from a bug or from small users request. They are logged into tickets prioritized and assigned to developers. Usually the ticket description is enough to figure out what we have to do. We publish our development as often as possible in Review Board, and wait for a “Ship it” from our leaders before committing the modification in the trunk.

    New development needs a little more investigation. It starts with a need expressed by our client. User stories and prototypes help developers and client to confirm that each other have the same view. Once everybody agrees on functional part, we dig into technical aspects, which are DB schema, class models, impacts on the existing programs and any other technical aspect. The goal here is to exchange with our teammate about what should be the best way to implement the request, to let traces of our development decisions (Why and how we have taken a decision instead of another) and finally, to have a plan of what has to be done. Final step is to divide the work into as small pieces as it is possible to divide it, create tickets and publish the development on Review Board as often as possible. That’s my first time with Ruby on Rails and for me, Review Board is very interesting to learn how to code and to have input about development questions.

    One last thing I really want to put emphasis on is QA! There is many tests levels that can be done on an application before sending it in production. At development level, there is unit test. I think that no new programs should be committed into trunk without a unit test. That’s the developer’s responsibility to produce good development and unit test is a tool to reach it. In my opinion, MarkUs team really has to improve that department in order to increase everybody’s confidence in the application.

    That’s about it for our project development process. I am new on that project so I might have forgot some aspect of our process but at least it gives you an idea of what we are doing, what works for us and what could be improved.

    Here is a link that comes from my QA teacher and that might be interesting for you. It talks about Agile software development in a distributed environment.

    http://people.canonical.com/~ianc/papers/community-agile/community-agile.html

    Nice to talk with you,

    Melanie

  3. omatthews said

    On the WikiDev team, I’m not sure we’re following any predefined process. Currently we have five students separated into three sub-teams working on three related but separate tasks. The non-student, permanent members of the team assist/lead us and steer the project as required. The sub-teams are organized by geographic location to allow for physical meetings if necessary. We hold weekly IRC meetings to discuss what each sub-team has accomplished in the previous week, any problems or issues encountered, and what each of us intends to accomplish in the coming week. For collaboration and documentation, we use our own WikiDev system, which integrates our IRC logs, mailing list messages, Bugzilla tickets, and SVN commit logs into a custom wiki. This allows us to refer back to previous communications in a centralized, search-able place. We update our current status and progress to sub-team specific wiki pages as well as our individual wiki pages. We use Bugzilla tickets to assign tasks to a team member (often ourselves) and then we refer to the ticket number in our SVN commits.

    These methods have been working well for our team so far. The weekly meetings ensure everybody is staying on track, and our sub-team setup has been great for collaboration since it is sometimes nice to actually meet in person. Our wiki has also been very convenient in organizing all of our communications. However, when focusing on my sub-team’s task, it is sometimes difficult to keep track of the project as a whole, and what the other team members are working on. Therefore, during some design discussions, it is easy to feel disconnected.

  4. mcneilm4 said

    For the ElmCity team, it took us a while to determine a development process. During the code sprint, we used something similar to the spiral method. We gathered our requirements, designed it, coded it, and then revisited the requirements again. From there we would make the modifications to the requirements, then modify the design and then modify the code. This method seemed most useful at that time because (1) we were all in the same room and (2) we had a really vague idea of what to do. Since our team lead was not there, it was hard to set a specific direction, however using the spiral model allowed us to do a lot of trial and error. We were able to keep returning to the requirements and see what was working, what wasn’t working, new features we want to implement, which features were not needed, and how to get in the general direction of where we wanted to go.

    After Toronto, we tried using the spiral model for a while. However, since we were all working on the project at different times, different locations, and working around different schedules, communication became an issue. After a couple of weeks, we finally found a time that would work for all of us and started to utilize the ticket system in Google code. Since then we have been mostly using something similar to the V-model. We get requirements from our team lead on what needs to be done. From there we code it, create unit-testing for it, then commit what we have worked on, and then continue on to another task. We try to have a conference call every week, but due to varying schedules, not all of us can make it. Because of this, the ticket system has become really useful.

  5. nilgoyette said

    I don’t think it was a good start for the Eclipse4Edu team. Let me explain.

    The main reason is that we were all working on different parts of Eclipse4Edu. We were choosing bugs for a part of the system that interested us, without much communication with the team because they were working on their own bugs.
    Of course, we communicated on the mailing list, bugzilla and the monday call-in, but I don’t feel it was enough. Maybe because we focussed on our own bugs without helping the others. Is a team still useful without help or code review?
    So, as I see it, we were not really working as a *team*.

    There’s several problems with this process.
    If we all work on different part of Eclipse, we end up with no complete/usable parts in december. Yeah, there’s a lot of new features, but they are all scattered in Eclipse4Edu, so I don’t feel like we have a better product. There was nothing mature.
    I guess I don’t really need to explain what’s wrong with a team that does not communicate, but I’ll do it anyway. Two heads are better then one. I don’t like to use a proverb, but it’s a fact of life for me. Eclipse4Edu will definitely be a better tool if we work as a team.

    The good news is that we changed our process!
    We now have a common goal. Someone in the team convinced the others to work toward the same goal : the Scheme implementation. It was a defining moment for the Eclipse4Edu team!
    Since the call-in were not good for us, we decided to use IRC twice a week, on monday and thursday.
    We now have a SVN, so we can share our code easily with our peers. +1 for the code review.
    We are helping each other much more now that we are communicating on IRC.

    I’m now confident that we have a process that will lead us somewhere.

  6. Ioana said

    Like the other teams, for the Robocup project we haven’t been strictly following any of the predefined development processes. I would say we used some elements of extreme programming, for example we usually had at least two students working closely on each feature. We’ve been working with a code base from the summer term students, and we’ve been using a svn repository. We also created an account on reviewboard, which I think we should have used more than we had.

    At the code sprint, we decided on a list of goals we’d like to achive by the end of term, and divided them among two teams. Initially we had 6 students working on Robocup, but one of us had to drop out, so we didn’t stick with the original teams, and just worked on whatever tasks we decided on each week. We’ve been havign weekly meeting on irc, where we discuss what we’ve accomplished the previous week and what we plan to work on in the near future.

    I think our development process has been working reasonably well. It would have been good to do more unit testing, but this has been difficult for some of our code, especially the machine learning tasks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: