Software Dev Cycle As Part of CS Curriculum?

tcolvinMI wonders: "I graduated from a small private college a few years ago with a degree in Computer Science. The main focus of the program, at this particular college, was to give you the tools necessary to be able to learn any programming language based on conceptual information, while having been introduced to several popular languages such as VB, C, C++, and Java. However, there was no 'final project' course that introduced a student programmer to the process of software development as a whole. Today, I was talking with a professor and pitched the idea of introducing such a course that would allow students to essentially go through the entire process from design to deployment. Is there any need for such a course? If so, what lessons would you place an emphasis on? So far, my idea is to allow a student to design an application that can be completed within the alloted time frame, develop in an approved language (one they've had and one the professor also knows), go through the QA process and then finally deploy the app to be evaluated by the other students in the class, who have not participated in the project." If you went CS, how well did your lessons prepare you for real project work? If you had a chance to prepare other college students for a career in development, what things would you teach them, and why?

Comments

How it would go

[MyLongNickName]

From My work experience,. here is how it would go, assuming a fifteen week semester:

Week 1: Agree in principle to what that user wants
Weeks 2-12: Go through iterations of determining specifics. Submit statements of work. Get ignored. Call. Get put off. Managers argue about whether background should have corporate logo, or whether it should be a neutral color. Finally get signed documents at end of 12th week.
Week 13-14: Work like mad to code the thing.
Week 15: Users bitch because you aren't done yet.
Week 17 (two weeks past deadline): Get work submitted that meets specs.
Week 17 1/2: Managers complain that five items not on statement of work were not addressed. When you mention it was not on the specs, they reply "well, it is kinda obvious, you should have realized"
Week 18-25: Repeat weeks 15-17 1/2 about five times.
Week 26: Switch major to engineering.

Re:How it would go

[TapeCutter]

Yes it's the same in many other industries, a long time ago I drove a taxi for a living, taxi users quite often expect the driver to know exactly how to get to their street and get impatient if the driver has to look it up in the street directory. I used to tell them "I don't get paid enough to memorise 40,000 streets", nowadays I tell scope-creepers "We will have to estimate the impact" and let the PHB's argue about the costs.

The best PM I ever worked for often said "if we don't find any problems we are not doing our job". The moral is don't let shitty customers and PHB's turn you from a proffesional into a code monkey that simply follows orders, make it clear that you won't put up with their crap and if they are not going to be "part of the team" it will take longer, cost more and the end product will be a dissapointment.

As far as business is concerned there are two problems in commercial software development, time and money. People hire (experienced) software engineers because they don't have the expertise themselves, they expect you to know what you are doing and to be able to point out project roadblocks before they become a big time and/or money problem. If you do this and the project fails it is the PHB's/customers fault, if you don't do it and it fails it's your fault.

TFA: I graduated as a mature age student in 1991 (and quit driving cabs), our final year in the software engineering subject was spent on two projects, one semester working on a project with a group of fellow students and one semester working one day a week at an approved commercial/government project.

Heartily, yes

[qw0ntum]

A class like that would be very beneficial to students, even if it does not completely mimic actually working (nothing really can). So much of CS focuses on the technical end of things, and I don't think enough emphasis is placed on the human side of things, be that interaction with the user or interaction with management.

Experiences in Seattle University

[Merc248]

I'm thinking about dropping my CS major. Why? Although they do teach you languages that are used today in the marketplace and tend toward an education that trains you as an effective software engineer, they don't care about teaching things that make people think about how everything is laid on top of each other and other ivory tower-esque stuff. I was talking to another peer in the CS department (who is similarly disenchanted with the CS program as well) about the various classes he took. "Programming Languages" used to be about, you know, the structure of programming languages. Now it's simply a glorified scripting language survey course. "Operating Systems" used to be about the operating system as a concept. Now it's a glorified Linux Programming course. etc. etc. I'd say that I'd be ready to tackle a project if I graduate with a CS degree from my current university. However, I think I'd simply be another cog in the machine, so to speak. That to me is a less desirable preparation than learning all about theory and finding out how to implement them in the real world by myself.

Definitely

[Bob Gelumph]

There should definitely be such a course.

At Monash University in Australia, the Bachelor of Software Engineering has at least a couple of separate group projects that go through parts of the SDLC other than just the development phase, with the final year having a full project for a real client that lasts the entire university year.

You don't get to just fluff out some documentation with no consequences when you have to produce a product for someone who can get you failed if it turns out to be crap.

That's one of the reasons why it was the first software engineering course in Australia to be accredited by IEAust (like the IEEE).

At UofT...

[ThomasFlip]

At UofT we have a software engineering course. We do a project based on a real world theme starting from requirements on through to design and implementation. We learn a lot about project management along the way as well. The course code is CSC408 for any interested in using Google. We even get to (collectively as a class) choose which language we want to use for implementation. We don't necessarily use CVS, but it is taught in earlier courses.

Re:At UofT...

[FireHawk77028]

I went to a small private college (St. Vincent College, Latrobe, PA). There we had a software engineer class and a senior project. The software engineer class varies a little from year to year, but the professor in charge has been working software internships, or volunteer IT/software work for the community. One of the volunteer projects was a rather complex access data base with front end for a nursing home to keep track of poeple, events, family, etc. The class work itself taught software engineer, process, requirements, etc, and the work was almost entirely out of class. The senior project was usually a self design sollution to a problem, similar to software engineering, but done with less guidance and more freedom (you didn't have to work in a group and you had designed your own project). Software engineering was more "real world" becuase you didnt' have much choice on what to do (there were 3 projects, but still). And you HAD to work with who ever ended up on the project with you.

Re:CVS

[dvice_null]

Not only using a CVS, but also installing such. If you end up working in a company where there is no CVS in use and no-one knows how to install it, how usefull would your skills be there? Well I actually have been in this situation and it took less than a day for me to learn and install subversion there for us to work with.

What I missed at school was courses about GUI designing. I think the GUI designing should be one large part of the programming education, because quite often you have to design the GUI for our own programs, unless you work in large companies, where there are separated people to do this task.

On the other hand, we did have several courses where we designed, implemented and tested a whole program. Either by solo or in a group of 2-5 people. I'm surpriced to hear that they actually have schools where this isn't done.

Engineers overstate PHB decisions ...

[AHumbleOpinion]

Weeks 2-12: Go through iterations of determining specifics. Submit statements of work. Get ignored. Call. Get put off. Managers argue about whether background should have corporate logo, or whether it should be a neutral color. Finally get signed documents at end of 12th week.

As a young engineer I thought such things were complete crap too. However, regardless of how brilliant your spec/design is if it does not get "sold" to the client it is useless. If color schemes and logos make the sale more likely then please let management work on that. If you think they should not be telling you how to design or implement things then you should not presume to tell them how to "sell" something. Another way to look at it, business is a pretty Darwinian process. If color schemes, logos, slogans, etc. were complete crap they would not be used so heavily. Consider how packaging (Windows) triumphs over design (Linux) in many markets.

Week 17 1/2: Managers complain that five items not on statement of work were not addressed. When you mention it was not on the specs, they reply "well, it is kinda obvious, you should have realized"

Part b. Management complains that five items not on the statement were addressed. When you mention that once the project got underway the need became obvious, they reply "it is not in the spec".

I've had buddies who literally had this conversation, and management understood/agreed there would be a problem if the issue was not addressed. Management's rationale was that the omission would lead to follow-up contracts to make revisions, that the cost of this client error was coming out of the developer's pocket when it should come out of the client's pocket. I've also been told that in some defense related projects both parties understand and agree there is an omission/problem, but correcting the spec and redoing the approval process would cost more and take longer than revising/repairing/upgrading the initial delivery of equipment built to spec.

The point that I am trying to make is that we engineers are not the all knowing genius' we like to think we are. We are often quite ill-informed with respect to business. While PHB decisions absolutely do exist, we engineers falsely label some rational decisions as PHB due to our ignorance of issues outside of engineering. Learn from the mistake of the people of the "A" Ark. ;-)

Re:Some thoughts on the subject

[Coryoth]

A student needs at least math theory through discrete mathematics, and better yet through calculus.

I have to admit I am a little unclear of the benefit of calculus to a CS or software engineering student - I think too many CS and SE students waste their time with calculus courses which, while of great value to other engineering disciplines, aren't anywhere near as applicable to CS and SE. What areas of CS or SE would you see a need for calculus? I can certainly see benefits to set theory, combinatorics, and graph theory, which you are perhaps lumping into "discrete math" (though set theory done properly need not be discrete). I can also see a place for abstract algebra: groups, rings (for polynomial rings over finite fields), and fields, which can crop up in a variety of places including information theory. I can also see reasons why it might be worth doing some category theory - it is the language that a lot of advanced CS theory is now being couched in. These are all subjects that tend to get missed by CS and SE students that, perhaps, they really ought to get exposure to instead of more calculus.

TESTING software!

[Killer Eye]

Testing is a part of the software process that almost no one seems to teach (and thus almost no applicants seem to know). I really want to see universities make this a strong focus, even a primary focus, prior to implementation.

I see too much software that is not only untested, but designed in a way that makes testing harder than it should be. This is irresponsible and makes it difficult not only to understand software, but to maintain it (or even replace it, since a test suite tells you what important things the software was supposed to do).

A professor doesn't have to immediately delve into the nuances of some complex C++ commercial testing tool, or the process of setting up a test framework. For instance, a class could start with a programming language that has testing built in really well, like Python. Then, the concepts of testing (like what makes a good testcase) can be taught easily and independent of other complexities of programming.

Re:Some thoughts on the subject

[MindStalker]

I always thought Calculus courses were simply breaker courses for CS. If you can't cut the logic needed for Calculus you really don't believe in CS anyways. And it does help you refine your logic and problem solving skills as well.

We already have it

[Espectr0]

On my university in Maracaibo, Venezuela, we have such a course. It is called "software engineering".

You get a small team (between 8 and 10 people) and have to start and finish a product.
The team must be divided in: an administrator (in charge of the product, releases, etc), analists, designers, coders and testers.

You have to meet deadlines and even dress up and have a presentation in order to "sell" the product.

We did a small webapp that sold pizzas online :)