swalker
Very helpful member
- Joined
- Dec 11, 2014
- Messages
- 1,580
- Reason
- DX MND
- Diagnosis
- 07/2014
- Country
- US
- State
- CO
- City
- Vail
Thanks for that Steve. I'm still interested in your technical recommendations for the project, though we are somewhat constrained, I would like to make it as useful as possible.
I have a passion for helping folks grow and develop in this field. I am glad to help in any way I can.
I encourage you to pay very close attention to what Laurie has written. I agree with her assessment.
But, I know you have a senior project to do and it may not be practical to shift gears at this point. Regardless of whether you do or not, I think you could benefit from what I will write here.
As some background on me, I have spent a lot of time writing code in FORTRAN, BASIC, C, C++, Java, and C#. I have personally authored millions of lines of code in my career. I have also served as an executive in the software industry for over 30 years, rising to the position of President and CEO of my last company. I still serve on an advisory board of that company, though I am unable to work due to my disease. I have hired many interns, new college grads, and experienced professionals throughout my career and have always enjoyed my role as a mentor. I mention that background so that you may have some perspective on where I am coming from with my advice.
First, be clear on your objective(s). Write it (them) down. Is it to learn? Is it to get a passing grade? Is it to get the best grade in the class? Is it to convince your professor that you are the best of the best? I did not apply for my first job out of college. A professor recommended me for the position. He did that because I always set out with the objective of being the best of the best. Believe me, there is a shortage of talent in the market and those who exhibit talent will be sought out by those who are willing to pay for that talent.
Second, establish your requirements. You can use a variety of tools to manage the requirements (from JIRA to a piece of paper). For a project of your scope I would often use Excel. The important thing is the requirements, not the tool. Make sure there are no contradictory requirements. Make sure the requirements are concisely and precisely worded. There should be no ambiguity. Be careful to keep the project scope small enough so that it can be implemented in the time you have with the resources available.
Third, design before you build. It is tempting to jump right in and start building key pieces of your system before you know your objective, requirements, and design. This is a rookie mistake and I would expect someone working on a senior project to make it (because you are rookies). You can get well ahead of the curve by following a disciplined approach and delaying implementation until you know what it is that you are building. That way you increase the odds of building it once (by getting it right the first time).
Fourth, set up the development environment for your team. This can be done in parallel with establishing the requirements and design, though there are some requirements and design decisions that could impact the development environment you use. Be sure to use a collaborative CM tool (such as SVN) for your code, documents, etc. I enjoy using Eclipse with Maven, but I have been a part of building amazing software without them. Be sure to set up a unit test capability within the development environment and don't forget to set up an integration environment as well. You should have fully-automated unit and integration test frameworks established.
Fifth, implement your design. Be sure to write thorough unit tests for each class. Not doing comprehensive unit tests is another rookie mistake I would expect your team to be tempted to make.
Iterate toward completion. Integrate incremental chunks of software as they are developed. Be sure nightly builds with full regression testing is performed. I find integration is eased when each team member is required to run the full test suite on their checkout before they commit any changes to the repository.
Don't forget to write documentation needed for your system and commit this documentation to your repository.
Finally, I like to layer agile over all this. I like the SCRUM discipline and believe that working in sprints is a great way to manage projects. It can really fall apart on larger projects, but is an excellent choice for a project of your size.
Note that I have not said anything about the problem you intend to solve or the algorithms you might employ to solve it. I think that needs to be up to you and your team to develop.
Good luck. My bandwidth is quite limited, but I will be glad help as I can.
Steve