Software planning: integration

I'm currently the team leader of a group of students working on a project for a course right now consists of both electrical and computer engineering students. I'm one of the electrical engineering students, and I have yet to work on the software components of the project yet. I feel that the planning for the software development and testing could be more organized, but didn't really know where to get started. The team has assigned a software lead, and collectively brainstormed on what the project should be able to do in layman's terms (i.e. without technical jargons related to programming, script, and other languages or framework). What would you suggest the team doing to better plan the development, testing, and integration process? The criteria that the team is taking into account are consistent input + output between different functions and systems, communication protoco开发者_C百科ls between systems, and operating condition. Thanks in advance.

Since the team has already brainstormed on some high-level requirements for the project, you are well on your way to a decently-organized project. I would suggest that you collaboratively write up and review a more technical specification of what you are developing. The act of getting it all on paper, defining discrete components/modules/etc, and defining the interactions/expectations for these parts will all help to iron out details and identify potential problems and misunderstandings early in the project. Spending the time to do this early in the project will help to avoid wasted time later.

Use version control. Keep the group talking to one another and informed of any changes to the specs or requirements. If it is a complex project, I would suggest making some milestones, so that you have your crucial functionality before the deadline so that you can start adding any nice-to-have functionality as time allows.

Take a look at "functional specification" templates and examples online to get some good ideas of what yours might include. Don't take them too seriously, and don't follow them to the letter - you know what is needed to properly define your project, and what is not necessary. But I think getting it all on paper and talking it over is what will help your project the most.

First make it work, then make it good. This means integrating early and only then adding more functionality. Do not use too much time planning it in advance, as your plan will probably not hold anyway. I have seen this in practice too many many times when people start integrating parts only after a week of coding them separately. It never goes according to the plan.

Having a working application also speeds up the development because actual testing can be done instead of having to rely on placeholders that do not actually function. It appears to have a psychological effect as well.