Development tools

I think you should select the tool that supports the way you are working, not the other way around. This is one of the reasons I think tool discussions usually focus on the wrong thing. They tend to get very long-winded and troublesome since the underlying process is not clear or decided.
However if you are a small team, I think the following tools are of use to you regardless of what process you are using (the version control software are useful for any project size). Many of my students seem to use them when they are doing project work.
  • Version One Team edition - A free tool that supports managing agile software development.
  • Trac - An enhanced wiki and issue tracking system for software development projects.
  • GIT - A free & open source, distributed version control system. I think it is a major upgrade compared to SVN, even if the initial learning curve is steep.
    If you run Windows I suggest you use TortoiseGIT as GIT client.
  • Mercurial - A modern, open source, distributed version control system (sounds very similar to GIT?). I think the learning curve is not as steep as for GIT, and a transition from SVN is probably easier. TortoieseHG is a good client for Windows users and what I use myself.
    In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts.
If someone can comment with suggestions of free simple tools that supports testing/verification or integration I would be very grateful.

Confused by Simulink

The most common modelling tool in the automotive domain is Simulink. It started as a Matlab-based tool to graphically model and simulate differential equations needed in control design. Now it has expanded way beyond that to enable generation of production code for embedded controllers.

For someone like me, with a background in software and systems engineering and only the mandatory control engineering course, Simulink is confusing. Not the model elements as such, since it basically is an executable time-discrete data flow model. But the terminology used in the Simulink community is really confusing since they are using terms very common in software development, but with different meanings. I am not even sure the explanations below are valid...

Some examples:

The importance of the team

I am reviewing and grading documentation in a student project. Or rather 12 student projects, all trying to develop similar software. The context is this: The students work in teams of 6. Each student has a separate role; project manager, architect, designer, quality/testing responsible, GUI designer and communications expert (it is an peer-to-peer application based on TCP). Alla students have to write code, and in addition to this they are supposed to turn in documentation related to their role.

What strikes me is that in the teams with good documentation all documents are good, regardless of author. How come? There could be several explanations:
  • Good students want to work with each other (they could choose their teammates, they weren't assigned by us teachers).
  • In good teams they cooperate on everything, inlcuding reviewing each others documents. In not-so-good teams they instead might try to split the tasks and work as independently as possible.
  • In the good teams there is an exceptional student that functions as a mentor to the others.
  • Excellent documementation from one role supports the others in their roles, e.g. an excellent architeture description supports testing etc.
  • The good teams had not only a notion about what to deliver when they started, they also had a good notion on how to do it early on, e.g. they discussed so they had a common understanding of coding responsibility (everybody had to write code) and they choose an interative process or SCRUM already the first week.
  • The good teams started with coding as quickly as possible. This is counterintuitive, but I think they felt more comfortable spending time on documentation if they already had some prototype running.
  • It seems that analysis paralysis actually produces worse documentation. I think this is due to an inability to focus on the vital concerns and stop when they are sufficiently covered.
  • It is hard to excel if your teammates drag you down. This could explain why there are no groups where just one role shines above the rest.
I'm sure there could be other explanations that I didn't think of...
Copyright © Driver Blog. All Rights Reserved.
Blogger Template designed by Big Homes.