“Keeping you up to date with everything software engineering!”

CUSEC 2006 and Beyond

CUSEC | December 13, 2004 | 3 comments

CUSEC 2005 is just around the corner so it seems odd to start talking about CUSEC 2006. CUSEC 2006 will be our 5th anniversary and we want to make sure that it will be our best conference to date. We have had a lot of success over the years and it will take a lot to one up ourselves hence the need to start organizing the conference earlier.

It feels like only yesterday when a group of software engineering students from Concordia University got together to organize a conference for software engineering students from across Canada. I feel very fortunate to have been apart of that first organizing committee as well as still being apart of the organization.

At our first conference only a couple of universities started to offer a software engineering degree but there still was nobody in canada who had graduated from an accredited software engineering program. Five years later many schools from across Canada have had one or more graduating classes.

When I graduated I was really disappointed that I would not be able attend CUSEC any longer (some would even say CUSEC is the reason why it took me so long to graduate). After asking around I realized I was not the only one that felt this way. Students have graduated, entered the real world and have so much more knowledge now to share at CUSEC… why close the door to them?

CUSEC 2006, our 5th anniversary, will evolve to adapt to the changing environment of software engineering in Canada. The conference will cater equally to all three groups that make up the software engineering community: students, members of academia and now professionals; while never forgetting its root as a student only conference.

I worked with Frederic Rioux, one of the most active contributors of CUSEC over the years and founding member of the CUSEC’s Central Committee, to come up with an updated version of CUSEC’s mission statement:

CUSEC is a national conference organized for and by the software engineering community in Canada. It is a conference where academics, professionals and students come together to exchange ideas, experiences and learn from each other. We makes sure that there is an equal representation between academics and industry and the conference is a springboard to reducing the divide between the often separated groups.

Students play a large role as both organizers and attendees of the conference. As a student the cost of attending the conference will remain as minimal as possible so software engineers can start attending the conference as students and continue to attend the conference past retirement. Each university with a computer related program will be encouraged to be represented at the conference by organizing and sending delegations.

For each conference a theme will be chosen and the format of the conference will be designed to make sure that attendees will learn the most on that theme while focusing on interactive learning. The environment will be relaxed and laid back so that people will feel comfortable to be themselves. Activities will be organized so that all attendees from different backgrounds and experiences will feel comfortable to open up communication.

In general our mission is to make sure that all of the groups that make up the the software engineering community can attend a mutually beneficial conference and learn from each other while leaving the conference as better software engineers.

The conference will return to my hometown and one of the most beautiful cities in Canada. It is tentatively scheduled to take place from Thursday January 12th to Saturday January 14th 2006 at the Mount Royal (same place as CUSEC 2003 and 2004) Conference Center in the heart of downtown Montreal.

I realize some people are skeptical about CUSEC catering the conference to both professionals and students. It will take much discipline to make sure the conference does not get taken over by corporations. But you have to remember when we were students we were in the same position. We could of easily chosen keynotes from large corporations that would of given us the biggest sponsorship package but instead we choose keynotes that we felt would be the best pillars for that years theme. We stuck to our values back then and there is no reason to believe that we will after four amazing years change our values now.

Here is a list of some of the benefits we envision from going to a 50/50 split with equal tickets being available for professionals and students/academia:

• allow students to meet with professional software engineers and mentors and make contacts in industry;
• help us to raise more money to allow us to bring in more speakers;
• bridge the gap between the way software is presently being developed and academia’s view of software engineering.

We are not going to only strengthen our corporate presence but our academic presence by strengthening our promotion of our Call For Papers as well as create a stronger and more credible review process and committee.

Will the cost of all these benefits be put on the back of students. Absolutely not. The cost of the conference will remain under $100 CDN for students.

All along we have been organizing this conference for you. All the changes that have been implemented from year to year have been the result of your feedback. We have two questions for you that we would like for you to take the time to respond (in the comments section):

• If you could add/remove/change one thing about a CUSEC conference that you have attended what would it be?
• If were given the opportunity to choose just one of the presenters at the conference, who would you pick and why?

If you have any additional comments, suggestions and or questions don’t hesitate to share them with us.

We look forward to seeing you at CUSEC 2005 in Ottawa and CUSEC 2006 in Montreal.

Related Links:

• CUSEC 2005

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

December 18, 2004 02:54 PM | Ness commented:

What I would like to see is more emphasis on what software engineering should be and less emphasis on what it currently is.

Perhaps concentrate on the basic building blocks such as req’ts, design, build and verify while putting less emphasis on the “tools/methods of the day” to do those things (OO, Programming Languages in general, methedologies, and yes - even Subversion).

I think it’s great to be exposed to the current tools used in tutorials and other sessions, but I don’t think keynotes should be based on them.

** I reserve the right to keep my opinion. ;)

December 20, 2004 02:51 PM | John Kopanas commented:

I think you have a good point. But I have a question to help me better understand your comment.

What is the different between the basic building blocks of requirements and methods to gather requirements? I totally understand tools but I am not sure where the seperation between methods of the day and building blocks are. Can you give us an example?

December 21, 2004 01:46 PM | Ness commented:

Interesting. I suppose I should have been more rigourous with my suggestion.

As I understand them, requirements are the outcome which is often the final requirements document. The methods for “gathering requirements” on the other hand appear - to me at least - to be fads. These methods seem to have a certain popularity associated with them which varies over time.

Would you only use one “method” to gather requirements? If you say no this admits that the method has a weakness which does not allow it to satisfy the job of creating a requirements document. If you say yes you should probably read the question again.

I should have defined what a building block is in my first post. My concept of a building block is the common ideas of all systems that cannot be decomposed into sub-ideas any further. It should also be possible to apply these ideas to any system without modification. Be it an online commerce or embeded system critical application (I choose these two systems because they seem to be the farthest apart in my mind).

Therefore the “methods of the day” should have these “building block” ideas embodied within them.
Perhaps we should be disecting the methods to try and extract the underlying “building blocks” instead of going through some use cases for specific situations to show how great the method can be for a very small sample.

Only by having the basics can you extend those ideas to specific cases.

I hope this helps, although this is not a concrete example.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)