In-House Software Suggestion

I think it is a great idea and would be a lot of fun. The only thing that concerns me is how it would be marked. Like you said the real world is messy and a solution can be rather difficult to track down sometimes.

My suggestion for the marking (if I may be so bold) would be to develop our own in house testing of the plugins so that a lot of the marks can be easily earned by following what api can be found and then the rest could be with how well they work in real life.

Bryan Heisler
"Half the lies I tell aren't true"
--Elazmeh

Actually, I think this would be better than what we had in the old 343. One of the things which I find difficult is adequately diagramming/documenting systems to integrate with prexisting frameworks, as all of my previous experience in coursework involves starting from scratch. I think students would get a lot out of learning how to work with completely foreign code.

I would also think that, assuming the projects were successful, that contributing the code back would be a good idea. That could even be part of the project, as most high-profile OSS projects have pretty strict standards for inclusion.

--
Andrew

I can't claim to be an authority on the subject, but I have been working in the software development industry at a well-known Telecommunications Handset Manufacturer for the last 2 years in conjunction with finishing up my undergraduate studies at UofG. While piggybacking on the foundations/architectures of open-source projects does remove a significant portion of the leg-work from the design process (for numerous reasons, as stated in the parent), IMHO, it still doesn't capture what is really lacking in our software engineering/system analysis curriculum.

It's trivial enough to build a piece of software that accomplishes some real-world task -- this is currently what the 12-week restriction permits. However, designing a system to scale, evolve while maintaining conceptual clarity is quite another. Unfortunately, it is very difficult to accelerate the growth of the software life-cycle (especially in a classroom setting), so this experience is largely absent from the curriculum (and for good reason...).

Unless I am mistaken, starting in 2008, a new course will be introduced dealing with software verification and testing. If the spirit of this course was embodied in building upon previous courses (whether it be an actual arrangement or not), in addition to the introduction of both the applied and theoretical aspects of white/black box testing, integration testing, regression testing, performance benchmarking etc., I think students would have a much better understanding of what software engineering actually is by the time they leave the program. Even in large groups, building software systems in an academic setting doesn't give you a feel for working on a truly vast project -- I think it would be a real plus for Guelph students if they left the program with a tool chest of ways to ensure they can dig into an active development process and more importantly ensure what they produce will "play nice" with what is currently there. I have hired many coops that can certainly write code, but are quite wet behind the ears when it comes to extracting knowledge from a large source code repository, adding to that repository through application of said knowledge and testing what has been produced such that a level of confidence regarding correctness can be provided to supervisors/mentors. I have included a few suggestions that are geared towards addressing these points below.

So, to summarize I would change our existing System Analysis and Design/Software Engineering courses in the following way(s):

Analysis and Design -> Focus more on the establishment of requirements and methodologies employed for ensuring their satisfaction. Perhaps do-away with ground-up endeavors in favour of the extraction of designs from existing projects (Open source?). Topics to explore could include: Trade-offs in cost/benefit, prospective scalability, mapping of requirements to features specifications and feature specifications to implementations and perhaps even schedule/milestone estimation and forecasting. Actual programming can certainly be present, but the marathon end-of-term project need not be a ground-up endeavor -- an elegantly implemented plug-in should suffice provided a concise and clear design is provided along with evolution paths and future design ideas. In a sense, it is not as important that the project be completed in a sub-standard form, but that the approach taken was sane and easily understood by others.

Software Engineering: Unlike the previous refinements, in this course the end-product is everything. Granted, relaxing the restriction in the previous course removes the student from experiencing the pressure of having to deliver a software system on schedule, but I think the trade-off is worthwhile if they have a better understanding of how to do it well. This course should include an introduction to source code repositories, code line maintenance, defect forensics etc. The grade a particular group receives should factor in the /process/ of developing the system in addition to the end - product. Intermediary builds, evolved specifications, clean source code repositories should be stressed. Testing is introduced early and cast as a development aid, not a chore. However it is not considered in judging the merit of the final project.

I am unsure how these ideas would mesh with the requirement to incorporate group work into the curriculum, but I don't see any immediate issues here.

Anyway, this reply has quickly ballooned on me, so I will leave it at that. I completed my undergraduate thesis in this area, so if anyone would like to discuss further, please feel free to contact me!

-Grant