Amyot: Guidelines for Graduate Students Supervised
Version 1.1, June 17th, 2004
(Based on Dr.
Timothy C. Lethbridge's
guidelines, version 1.1. With all my thanks.)
This document is designed to be read by prospective students, new
students as well as ongoing students.
N.B. Bien que ce document ne soit pas
encore disponible en français, il est certes envisageable de
travailler et faire votre thèse en français avec moi si vous le
désirez. Contactez-moi si vous avez des problèmes
à comprendre le contenu de ce document.
These guidelines are provided so that everybody has an understanding of
how I plan to work with graduate students as their supervisor. If you
have questions, please don't hesitate to talk to me about them.
Understanding the guidelines will hopefully help prevent various kinds
of problems, including mismatches in interests.
My motivations as I work with graduate students are:
I also need to warn you up front about a couple of aspects of my
- To ensure that you, as a student, have the highest possible
quality education, and
- To ensure that I, as a professor, get my research done
- I am a fairly young professor without only a couple of years of
- I have little financial support for specific projects.
1. What kind of grad students am I looking for?
I can supervise students in Computer Science, Electrical Engineering,
and Systems Science.
If you want to join my group, then you should have most of the
below. It is up to you to show your initiative and convince me
that you have these qualities:
a) You show enthusiasm about at
least one of the topics of my primary research which currently
- User Requirements Notation
- Formalizing and connecting the Use Case Map notation and the
Goal-oriented Requirements Language
- Connection and transformations to/from other languages, e.g.
UML, LOTOS, MSC, SDL, TTCN, ASN.1, eODL, Petri Nets, etc.
- Methods and tools
- UCM-based patterns for requirements definition, analysis, and
transformation to designs
- URN for Performance Engineering
- Empirical studies
- Requirements engineering tools
- Integrating the UCM Navigator and
- Java/Eclipse-based URN tools
- Testing, Validation and
- Scenario-based validation of requirements and designs (UCMs and
UML Activity Diagrams)
- Reverse-engineering of dynamic
- Use Case Maps scenarios for understanding existing software
- Scenario-based performance engineering
- Definition of Core Scenario Model (scenarios + deployment +
performance info), and transformation from UCMs
- Design reasoning in scenarios to adapt to performance problems.
- Identify patterns and rationale for searching in the space of
scenario designs, given the location of performance problems.
- Personalized communication features
- IETF Call Processing Language, policy languages, and feature
- Students interested in other fields might also be my students,
but I might expect them to work more independently, and they would be
lesslikely to get funding from me. These other (more general) areas
- Formal methods,
- Software engineering,
- Requirements engineering, and
- VoIP communication/collaboration applications.
b) You are eager (not just
simply willing) to perform research that fits into my research plan.
This includes working on specific subprojects that I have stated I will
do in grant proposals, and following the methodology I propose. Note
that, if somebody else is already doing a subproject, then it will no
longer be available to you.
c) You show that you have your own
ideas that fit in with and extend mine.
d) You communicate well with me.
This primarily means you listen to and quickly understand my ideas and
see my "vision" for the research. It also means you express your own
ideas in a way that I find concise, clear and easy to understand.
e) You are eager to work with people
in industry. This includes travelling to companies (e.g. Nortel,
Mitel, KLOCwork, IBM/.Rational, EION, Telelogic, and others in the
Ottawa area), performing a considerable amount of work in companies
(e.g. one day a week), and collaborating on (often confidential)
f) You have an appropriate background
in my research areas, and particularly in the area of your research
topic. This does not just mean basic computer science, it also means
knowledge at the senior undergraduate level of:
If you are missing one of these areas, then strong background in
another area can make up for it provided you study the missing area
early in your graduate studies and it isn't required before you can
start basic work on your thesis. In general it may not possible for me
to educate you in missing areas using directed
studies courses because it may take too much of my time. Please consider these aspects
seriously before contacting me.
- General software engineering (equivalent to SEG 3100 or SEG 3300)
- Object oriented analysis and design, with UML (equivalent to SEG
3110 or SEG 3310)
- Software validation and verification
- Requirments engineering basics
- Formal methods (in telecommunication or distributed systems)
g) You show a willingness to
progress rapidly in your studies. In general, I will be
reluctant to accept part-time students.
h) You have some industrial
i) You have good grades (A) in
programming and software engineering courses. Good skills in
UML, XML, C++ and Java are a plus!
j) You demonstrate good writing
skills. This does not eliminate people whose mother tongue
language is not English or French.
k) You show initiative. For
example, I expect that grad students will have read through all
relevant material on my Web site (not just titles) before approaching
me to be their supervisor.
l) You show good research skills:
Among other things, this includes digging up material in the library
without being asked, formulating good research plans, evaluating your
research well, being critical of others, etc.
m) You are a team player.
Most of my research is done in collaboration with other professors from
the CSERG group (L. Logrippo, G. Bochmann, R. Probert, H. Ural, A.
Williams, S. Somé, T. Lethbridge, A. Felty, I. Kiringa, and
others) or from Carleton University (M. Woodside, D. Petriu, L. Briand,
F. Bordeleau, J.-P. Corriveau, and others). One of them may become your
co-supervisor if you are my Ph.D. student. Additionally, many group
meetings and much collaboration with other students are to be expected.
2. How do I select grad students?
I select grad students based on the criteria listed above. I will never
accept a grad student without interviewing them first and seeing
samples of their work.
If I do not select you, it may have nothing to do with you as a person
or your abilities; it might just be that I have no more spaces
(regardless of whether I am funding them), that your interests and
abilities do not match my needs (see above), that our communication
styles and personalities do not match well, or that I am unable to
evaluate you adequately.
I will never select a grad student who emails me randomly and expresses
a non-specific interest in my work (actually, I may even not reply to
generic requests). If you want to be my student, you should write
something that convinces that all the points in the section above
apply. You should also arrange to talk to me in person or by telephone.
Note that I get many expressions of interest and don't have time to get
back to everybody. If you are really serious about working with me, do
not give up if I do not reply by e-mail right away. If you are not
serious, please try to contact other professors.
Finally, just applying to the university and listing me as your
proposed supervisor is insufficient.
3. How do I support grad students?
I sometime get funded for specific projects. If I support you, you have
to do the work that was outlined in the proposal I wrote to obtain the
I will support (i.e. with money) you only
if we agreed that I will do so
when you /started/ the program. I will not normally entertain
requests from unfunded students to start funding them. This is because
I must plan my budget carefully.
Support is always subject to the availability of funds, and you must
realize that the grants I receive are subject to renewal and
variations, and can even be cut (especially in the absence of
When you agree to be a grad student with me, I will only undertake to
support you for the period of time that a grad student would normally
take to complete their program (see below). Support beyond the initial
period will only be considered if you have made good progress, yet the
research has turned out to be more difficult than expected; and in my
judgment it is not your fault that you are not finished.
Students with their own source of funding (e.g. scholarship) or without
the need for funding are obviously more than welcome and will be given
Funding arrangements if you do other work:
I will allow you to do 1 TA (10 hours a week for a term) a year. In
addition, I will also allow a PhD student to teach 1 course at just one
time in their program. If you want to do any other work, then I will
have to reduce the amount of support I give you, since you will not be
able to do the work that the funding agency is paying me the money to
Also, working more than the above amounts puts you at severe risk of
delaying the completion of your program.
In the following situations, I will review of the money I give you, and
possibly cease to fund you or reduce the funding:
- Inadequate progress (see the time-line below) and/or doing too
much outside work.
- Not fitting your topic with the intent of the funding. Remember
your research is part of a larger research plan, and I have to ensure
that the larger plan is being adhered to.
- I am not satisfied that you are doing good research, after
several attempts by me to help you get on track.
- The project funding has expired.
Funding arrangements while taking courses:
At the beginning of your program while you are taking courses (or
working on your comprehensive), it is normal not to be able to make
significant progress on your thesis. If I fund you during this period
(this might not always be possible) and you then quit without
accomplishing the planned research, then I reserve the right to ask you
to pay back the support money.
4. What will be the time-line of your research?
You will plan your thesis and develop an initial proposal and project
plan in the first 4 months of your program.
You will monitor your plan and discuss it with me when changes are
needed. Inevitably, changes will be needed as your research leads you
in unexpected and interesting directions.
Note that Ph.D. students also have to develop a formal written thesis
proposal that will be more in depth (see below).
Duration of Masters Degree:
A Master's degree should normally take about 20-24 months of full-time
work. The national average is over 30 months, but I believe this is
excessive. Excess time can be caused by such factors as a) a topic that
is too uncertain or difficult, b) inadequate communication with the
supervisor, and c) doing excessive outside work.
- We will work together to ensure you have completed your program
in this time.
- If I am supporting you, I will support you for up to this 24
months period, subject to availability of funds.
- Coursework will normally take you the first academic year; until
this is complete, thesis work should progress at 1/3 intensity.
- Thesis work will normally become a full-time effort after 8
months (i.e. your first summer) and will take the following academic
year as well.
Duration of Ph.D. Degree
A PhD degree should normally take 4 to 4.5 years of full-time work. The
national average is 4.5 years.
- If I am supporting you, I will support you for up to 4.5 years,
subject to availability of funds (although I challenge you to complete
your work in 4 years). We will work together to ensure you complete
your work in this time.
- Coursework and the comprehensive will normally take you the first
academic year. It is probably easiest to register for the comprehensive
in your first summer and write the comprehensive in August. Students
find it hard to get on with their thesis while the comprehensive is
unwritten. During this first year, thesis work shouldtake about 1/3 of
- Thesis work will normally become a full-time effort after 1 year.
After 18-20 months, you should be ready to present your formal thesis
proposal to your committee.
You and I should discuss all courses in which you plan to register. You
should study the calendar and propose courses to me. I highly recommend
I will also be looking for some of the following undergraduate courses
(or equivalent) in your resume:
- CSI 5109 - Specification Methods for Distributed Systems
- CSI 5110 - Principles of Formal Software Development
- CSI 5111 - Software Quality Engineering
- CSI 5112 - Software Engineering
(which I teach in the Winter)
- CSI 5118 - Automated Verification and Validation of Software
- CSI 5122 - Software Usability
- CSI 5143 - Real-Time System Development (Carleton)
- CSI 5171 - Network Architectures, Protocol, Services and Standards
- CSI 5174 - Validation Methods for Distributed Systems
- CSI 5314 - Object-Oriented Systems (Carleton)
- ELG 6112 - Performance Measurement and Modeling of Distributed
- ELG 6135 - Representations, Methods and Tools for Concurrent
- ELG 6186 - Object Oriented Design of Real-Time and Distributed
- 94.515 - Software Quality Engineering and
- SEG 2101/2501 - Software Design III
- SEG 3100/3500 - Software Development of Large Systems
- CSI 3104/3504 - Introduction to Formal Languages
- SEG 3110/3510 - Advanced Object-Oriented Analysis & Design
- SEG 3120/3520 - Analysis and Design for User Interfaces
- CSI 3125/3525 - Concepts of Programming Languages
- SEG 3300/3700 - Introduction to Software Engineering
- SEG 4111/4511- Software Quality Engineering
5. What is my style of supervision?
I like to meet with students about once every 10 to 20 days, especially
after your coursework is complete. I will set aside a period every week
for personal discussions with grad students - if you want to take some
of this time, then let me know. If I have not met with you for a month,
then I will ask to see you. My students will also be expected weekly
group meetings (plus those specific to the projects in which they are
I don't mind talking with you at other times, but I reserve the right
to say no if I am to busy.
It is best for us to base our discussions on something you have written
- so attempt to write something for every meeting, even if it is just a
paragraph describing progress. These things you write for meetings can
become part of your thesis.
How do you develop your ideas and how do we agree on a topic?
When you start work, either you or I will propose a research topic, and
we will agree, in writing, about what you will do. If you want to
change your topic I must agree. Remember that I need to get certain
research done to fulfil the requirements of the funding agency.
I will give you orally and in writing any ideas I have about the topic
(I will attempt to summarize these by email so we both have a written
record). My ideas may be very concrete or abstract. It is up to you to
decide if you are happy with the topic and the information I have given
you. If you are not happy, you must seek clarifications and more
You will also get the opportunity to present your ideas regularly to
the RDA/CSERG research groups and to get feedback from them.
6. What are the steps in research?
The early part of the research should be spent gathering information.
You should search the literature and read as many papers as possible.
You should also talk to industrial research funders such as Telelogic,
Nortel, Klocwork, and others. Take full advantage of the uOttawa
library, the ACM and IEEE digital libraries, and also CISTI (the
National Research Council library).
Then comes the phase where you experiment with your ideas. Often there
will be program design and implementation during this period of time.
The choice of programming language is yours, although it should fit in
with the infrastructure (see below).
The final phase is evaluation your ideas; this will normally be both
theoretical and empirical (experiments or analysis of observations). It
is essential that you use good statistical methods and gather
sufficiently large amounts of data if you do empirical work.
These latter two phases will normally iterate. Also, you will continue
to gather information throughout the research.
I strongly suggest that you write down paragraphs and chapters
throughout your research. That way, after the research is complete you
have most of your thesis written. A common problem students have is
fear of the writing phase - due to this fear, they drag out the
research phase for too long. Also, writing helps organize your thoughts
and stimulates you to develop new ideas.
In addition to formally writing about your work as it progresses, you
should also keep a handwritten hardcopy lab-book (or a series of such
books) where you keep all your informal notes.
7. Other points
Responsibility to work with companies that are funding the work
For work funded by a company, you must do the following: Work with the
company to understand their needs, and then implement your ideas so
that real software/requirements engineers can test out your ideas.
Having real software/requirements engineers work with your ideas leads
to a form of empirical evaluation provided you systematically gather
data during your observations. Non-disclosure agreements and IP
protection are usually requested for industrial collaboration.
Building on the infrastructure
We have developed an infrastructure of software (e.g. the UCM Navigator
in C++, feature interaction tools in Prolog, XML/XSL/Java tools, etc.).
This was done at great expense to make it easy for students to then try
out ideas. Access to industrial-strength tools will also be provided by
various collaborators (e.g. CSERG/ASERT lab). It is important, then,
that you take advantage if this investment by implementing your ideas
on top of the existing infrastructure. This is important for two
reasons: Firstly it means that users are not testing your ideas in
isolation; secondly it allows us to give something concrete to those
who are funding us.
Note however that we are not developers; we should remember that we are
at all times trying to answer research questions. Development of
software is merely a means towards that end.
Even though we are working in a research context, the software we
develop should be of good quality. You should particularly focus on
maintainability: Other students will have to build on what you have
One of your responsibilities when you become a grad student with me is
to learn everything you can about the infrastructure. You should, of
course, read all the relevant papers found in the UCM Web site, URN Web site, and the LOTOS Web site.
In the past, our group normally had access to a full-time research
assistant, namely Jacques
Sincennes (hopefully this will continue in the future). He
will be able to give you help learning about the infrastructure and may
be able to program ideas that you develop. You will have to work with
him to implement ideas that you want to develop yourself.
English grammar, spelling etc.
It takes me a great deal of time to fix the grammar of non-English
speakers. Therefore I ask you to find a friend (or pay somebody) to
proof-read your work if you know your English is not particularly good.
Do this before submitting anything new or that is significantly
I will normally expect every Masters student to try and write one
publishable paper out of their research. For a PhD student I would
expect about 3 papers, one of which is in a journal. I would normally
be the co-author of these papers since many of the ideas come at least
partially from me.
Office space and equipment
Subject to availability of funds I will supply a PC to PhD students in
their office when they start work full time on their thesis after the
first year, however when it becomes obsolete I may not be able to
replace it (this is another incentive to get done by 4 years). Other
students should use the ASERT lab(s) if space is available.
You are responsible for your own progress
I will give you assistance when you ask me, however I will not pester
you to see if you are making progress. If I notice that your progress
is slacking off, I will sit down and discuss it with you, but the
ultimate responsibility remains yours.