next »

[cs_prof]

I am interested in both subjects. I do not have much to say on it, though.
Yet there are some standard questions.
1. What textbooks to follow?
2. How to evaluate students?
3. How to get them involved in online collaboration?
4. What kind of projects would you suggest?
5. Does it make sense sharing same project in different courses (say in the two mentioned in this topic)?
6. Software Engineering: do you think it is the right place for introducing software quality assurance and, in particular, software testing?
7. Systems Analysis: do you think it is the right place to introduce UML here? 

More questions to follow. Answers are eagerly anticipated.

[twofish]

I am interested in both subjects. I do not have much to say on it,

Software engineering/systems analysis covers an awful lot.  For example software engineering could mean

1) high level systems design - i.e. designing a system for registrars office
2) project process - the steps from requirements specification to shipping
3) high level application design - design patterns and refactorings

Also the target audience could be

1) MIS people
2) CS theory people
3) application programmers

Also the target audience could have different types of students

1) existing application developers
2) technology managers
3) junior undergraduates

1. What textbooks to follow?

It depends on the type of course.  For CS-geeks, the standard text for software engineering are the Wiley CS series books on design patterns and large scale software design.  For more MIS, I don't know of a good textbook, since this field rapidly goes out of date.  What would be a good mix are two textbooks that offer methodologies that are 180 degrees opposite.

The Mythic Man-Month is a must read classic.

2. How to evaluate students?

Mainly class participation.  One gotcha is that if you are doing a course that is mainly coding you want *encourage* sharing of code, since that is the way things happen in real life.  For anything involving coding, you should have peer code reviews, but it is important **not** to make code quality in the code reviews more than a nominal part of the grade.

In the case of more MIS courses, I'd go for a case study approach in which each student researches a real project in software design.  For example, what went wrong with the Denver-Stapleton baggage system.  Also each student can pick a field and then do a report on the special software engineering challenges of that field.  For example, for medical software, there is HIPAA compliance.  For finance there is SOX compliance.

3. How to get them involved in online collaboration?

Discussion questions and class presentations.  In the case of people with experience, you want them to share war-stories.

4. What kind of projects would you suggest?

In addition to case studies, you could disect a monster open source project.  Like openoffice.org or the linux kernel.

One other project.  "What ever happened to....."  Having the students pick a software methodologies that was in vogue a few years (or decades) ago, and research want happened to it.

Another good project is to have the students draw up a list of questions and interview people via e-mail.

5. Does it make sense sharing same project in different courses (say in the two mentioned in this topic)?

Yes.

6. Software Engineering: do you think it is the right place for introducing software quality assurance and, in particular, software testing?

Yes.  One thing that students will rapidly figure out if you give them case studies is how important testing is.

7. Systems Analysis: do you think it is the right place to introduce UML here? 

For an MIS oriented course, maybe not.

More questions to follow. Answers are eagerly anticipated.

A few general peeves on software engineering courses

1) Most have grading systems that penalize code sharing and copying, whereas the whole point of software engineering is to write and read code that is easy to share and copy.  Copying code off of google in most universities will get you expelled, whereas copying public domain code off of google to fix a problem in real life will get you promoted.  The result of this restriction is that coding exercises in academic courses usually silly throw away things that have little relation to real life.

The reason for case studies and peer review is that it vastly reduces the usefulness of copying things from the internet, which also vastly reduces the need to police for this.  Someone finds a paper on the internet that matches his topic.

2) Topics that are woefully undercovered in academic courses: *LEGACY SYSTEMS*, requirements gathering, quality assurance, maintanence coding, build systems

[dept_geek]

It depends on the age group. If you are teaching grad students, you can go faster. If you are teaching undergrads, you must go slower as most (all??) do not have the professional experience to make this course sequence meaningful.

There are several professional organizations that have developed BOKs for both courses. Start there.  Also carefully read what twofish wrote.

6. Software Engineering: do you think it is the right place for introducing software quality assurance and, in particular, software testing?

Yes

7. Systems Analysis: do you think it is the right place to introduce UML here? 

For graduates: yes. U/G: No. It should be introduced in part II of the course (SE).

[twofish]

It depends on the age group. If you are teaching grad students, you can go faster. If you are teaching undergrads, you must go slower as most (all??) do not have the professional experience to make this course sequence meaningful.

There is an important generational shift that I've seen CS faculty note.  Generation X'er grew up with BASIC and microcomputers so you ended up with people with a lot of hands on computer science experience before they went to college since people were programming since age six.  People born after 1980 grew up after the microcomputer boom, don't have much experience actually programming computers, and I've heard people note that a massive and sudden drop off in computer programming skills a few years ago.

[dept_geek]

2fish: While the programming falloff is noticable, the big thing with SA courses (especially those with an MIS or project management bent) is that the course is much easier if you have seen a programming project "in action." The assignments we give in laboratories don't count - they simply aren't big or complex enough. The 'real world' projects with lots of variables (most of which are out of the programmer's control!) are very frustrating to students who have zero experience.

The u/g SA courses must go slower because the terminology is so new and "ungrounded" (no way to associate the terms with something that the student has seen or done).  We touch on the major points in a term. Grad classes may go in to some significant depth in the same time period.

[twofish]

The 'real world' projects with lots of variables (most of which are out of the programmer's control!) are very frustrating to students who have zero experience.

Agree completely.  In the real world, 90% of the decisions have already been made.

I've found that one useful way of experiencing "the real world" is open source.  One of the nice things about big open source projects is that they open up a lot of the flavor of software development, including the massive amount of politics and bargaining that goes into a non-trivial software project.  The tricky part about this is of course not to overwhelm the student.

One thing that is important in dealing with software engineering is that one learns a lot about good practices by studying bad practices.  An experienced coder tends to instinctively avoid bad practices because of the instinctive memory of having to track down and replace 500 instances of a global variable across a thousand files.  Exposing the pain of bad code is particularly important to people with an MIS background so that they understand why moving a button to the left will take three weeks.

Internships are also useful for giving undergraduate students real world experience, and one thing that is rewarding is to see a light bulb light up in an intern when they make a connection between something that they experience and something that they read about in class.

Something that I haven't seen tried but might work well is to work with the employer of any interns.  If the employer of the intern knows that on week 3, they are going to be studying data abstraction, then they might be able to give the intern exposure to that concept in live working code.

This wouldn't work with experienced coders or MIS people.  In that case you'd probably want to keep as much distance as possible between the course and the employer so that course participants feel comfortable talking about what happened in the office and how that relates to the course.  One rule which is really important for classes with experienced people is that information about what happens in the class is considered strictly confidential since in talking about their work experiences, a lot of sensitive information gets shared.