Slashdot Mirror
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?
You need to be able to work on a team, and you need to be able to deal with a large group. A large group coding requires CVS or something similar. This should be included in the curriculum.
Care about privacy? Read this!
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.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
I think there should be one project that the whole class contributes to. That way the students can get used to working with a bunch of morons.
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.
'Every story, if continued long enough, ends in death.' --Ernest Hemingway
I'm a big fan of this. We had essentially what you describe at my college, in the form of a Game Development Class run by a teacher in the design college. At the beginning of the semester people pitched projects that they thought would be interesting, the group voted on 2 or 3 to move forward with, and students joined the one they were interested in. Design, development, coding, art, all were created from scratch. We had to go through and decide what external libraries to use, how to manage our codebase, etc. The end goal was to submit the project to the GDC student competition, as well as demo to the class.
Not only was it the most fun I had in any class ever, but it was a great learning experience. Getting to work on the same codebase as 5 other programmers for a full semester is an experience that was very much missing in all the "core" classes. It really drives home the importance of APIs and modular design, as well as teaching you some interesting things about working with other people. I highly recommend the same type of approach to anyone in school who wants a taste of the real world.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
From my (albeit short) experience in human ressources for IT firms ( am a software developer, but I worked for several small companies, so I had to extend my reach a bit) is that this is the biggest reason why, when you're looking for a job, most places tend to require significant real world experience to even consider someone: They are used to the fact that, in general, a student fresh out of school is not very useful in a software development environment (where, unless the company deals a lot with R&D, most of the code is trivial, it is just a matter of integrating the ideas right).
1 or two classes dealing with it could give an incredible jump start for graduates on the job market, once the employers catch on on it.
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.
"Hegelians, who love a synthesis, will probably conclude that he wears a wig." - Bertrand Russell
To answer your questions about languages my opinion is as follows.
A student needs at least 4 semesters with C++. C++ is the mother language and if you learn it you can program in about any other language for the rest of your life.
A student needs at least two semesters in software architecture and requirements gathering.
A student needs at least 2 semesters of data structures.
A student needs at least 2 semesters of networking.
A student needs at least 2 semesters of operating systems.
A student needs at least 2 semesters in secure software coding (and integral with every other class)
A student needs at least 1 semester in structured scripting like bash, ksh, csh.
A student needs at least 1 semester of compiler theory.
A student needs at least 1 semester of language structure, grammars, syntax, etc...
A student needs at least math theory through discrete mathematics, and better yet through calculus.
These of course are just simple undergraduate courses and there is so much more that can be done beyond this.
--- Location Unknown
My own view is that in any engineering discipline, developing a wary eye for risks and other horrors is essential. Experience has proved this "engineering paranoia" to be my friend.
You can use, with good effect, the basics of project management, the rudiments of business planning, and the various models of development.
I tend to favor the spiral model for complex developments, if I can approach the problem that way. The waterfall model works for well defined goals.
I recently looked through portions of the Wikipedia on "project management" so that is a good place to start, if a course is not forthcoming. Recommended.
This is progress?
...and I took a class that attempted to do something similar but it did not really do the concept justice. We weren't graded on the final project at so much as our design and collaboration (team project). What I think they need is some sort of "practical" class. My first/second real job (hah I graduated when the bubble burst) so these were "hired to tag/QA" and "oh you program and have a BS in CS too? you can help the software engineers" type jobs that paid about what I made managing a pizza restaurant. Let me tell you how frustrating it is working with people getting paid 3-4 times as much as you who are writing code in notepad and inable to configure/run a server (Tomcat) nor did they have any idea what version control was, but they had MS's in CS (same school as myself and mostly the same classes).
I really think they also need a class to explain software licensing... as the same people wanted to use code licensed under an "academic" license in a commercial product. But a class to introduce version control, build tools, deploying/setting up web servers and even IDE's etc should be mandatory. Maybe a rundown of what's freely available too.
It was a class at both Universities I attended...
What has been missing in all the classes I ever attended (which has been a while) was source management. I think subversion should be explained in the first class and used throughout the whole degree. Many can code; I want to hire someone who knows how to manage it.
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).
I'm gonna need a spec.
I just finished a Bachelor of IT in an Australian uni. Majored in Software Engineering ... I had 2 project classes in the last year, one for each semester:
- Core project initiation: choose a project, do the requirements analysis, design documents, maybe produce a project prototype.
- Core project implementation: produce the actual project, test and document.
This gets you used to a year long project (as opposed to the 8-10 weeks you usually get per semester). Projects consisted of things the UNI wanted done, professor projects, and real world projects where people come to the uni wanting cheap work done. I know of some project teams that got paid for their semester of uni work.
There was a subject dedicated to the principles of software engineering, which was one of the most valuable subjects, it didn't include any programming, just the preliminary investigation of requirements, UML, etc. I would highly recommend a software development class that doesn't include programming, you will get enough of that in other subjects.
In Soviet Russia, software develops you. . .
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.
If the dollar is an "I owe you nothing", then the Euro is a "Who owes you nothing." - Doug Casey
It's called software engineering. If you want to program and develop software for a living, you should get a degree in SE. Computer scientists are improperly put to work in the industry as code monkeys. A "true" CS degree would be having you touch very little code.
It all depends on why you're attending the courses. If you want to be "marketplace ready", then project management, source management etc are all worthwhile.
Engineering is the art of compromise.
Learning about the software development cycle is something to do in a software engineering course, not a computer science course. Of course these days, with universities and colleges become increasingly career and job training focussed, the differences between computer science and software engineering are blurred. Perhaps the better way to view things is to consider an analogy to other fields where the difference is mmore traditionally clear. Consider someone doing a physics and mathematics degree - they will learn about a great many things such as differential equations and their applications to physical systems. What they are studying, however, is the theoretical underpinnings of such material. Contrast that with a civil engineer who also learn about differential equations and their applications to physical systems. The engineer, however, will be learning how to make use of these as tools. A course in the development cycle of how to build a bridge - design, specification, testing and verification, and construction and maintenance - that's something that is integral to the course of the civil engineer, but something the physics student is likely to encounter since the physics student is not as interested in engineering applications so much as the theory itself. Similarly the software development cycle is something for the field of software engineering.
Craft Beer Programming T-shirts
You forgot a big one... a semester or two in database theory and design. Since most programming projects in the real world end up interacting with data in some way, this could be good. I can't count the number of times where I caught a programmer treating an RDBS like a flat file because they had no idea what a database was for or how they work.
Indeed. Well, obviously no amount of classes will make someone straight out of school a senior developer. The idea is that CS programs claim to give the students the "basics" of everything so they can go on their own, yet fail to give them the basics of the software development cycle... Just an analysis/development/testing/deployement cycle is enough. (I have work on multi-year/hundreds of users projects where profiling was kept at a bare minimum... we would analyse SQL queries and thats about it, because performance wasn't an issue, AND CS programs tend to -overdo- the whole optimisation thing, students don't need more, but thats just a side thing).
More likely than not, someone out of school probably won't even touch more than the code given to them bya project manager, at first. The goal of these classes would only be to introduce them to what -OTHERS-around them do, so that they can understand better how to plug their code in the cycle, and be able to pick up the rest of the "real world" faster.
In other words, anything so that students aren't surprised when they realise the actual coding is an insignificant part of software development, is good enough in my book.
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.
In one camp, you have the guys that see Computer Science as a branch of Mathematics, and find it unfortunate that "Computer" appears in the name. For them Computational Science would be a much better name. Asking whether the software development cycle should be taught as part of a Computer Science curriculum seems just as ridiculous to them as asking whether it should be taught as part of the Mathematics curriculum.
In the other camp, you have the people who are more specifically interested in computers and software development. They see programming as an essential, but far from singular tool in their box, and generally only care about as much computational theory as what is pragmatic. These are the guys that get much more excited about new methodologies than they do about proofs that a language is Turing complete. This group would feel robbed of an essential part of their education were they not taught anything about the software development cycle.
Currently the "real world" has a lot more demand for the second group than the first, but that doesn't make either view more valid than the other. I think the proper thing to do is for colleges to split their Computer Science departments into two entities that give separate degrees. The first, being more properly a science, would retain the name Computer Science, while the other, being more of an Engineering discipline, would be given the name Software Engineering. Then students can choose for themselves which group they belong to. If I'm not mistaken a number of colleges already do that.
There would, of course, be some overlap, but it seems roughly equivalent to the split between Physics and Electrical Engineering, which seems to work out fine at most colleges.
>A student needs at least 4 semesters with C++. C++ is the mother language and if you learn it you can program in about any other
>language for the rest of your life.
I've seen experts in C++ break down totally when they encounter Prolog and LISP. I've seen people who are steeped in a C++ background who's code in Java looks like something out of a programmer's worst nightmare.
There are also a lot of habits that one develops in C++ that not only do not apply in other languages, or which can be downright counterproductive. I agree everyone should know the language and that it has a lot to offer, saying that C++ is "the mother language" is a bit nonsensical.
As to the class list...
"To learn what?" is my question. Why take 2 semesters of networking, and 2 semesters of operating systems? What are you hoping that the individual will learn in these semesters? (the weights that you provide are also not in sync with the documented you cited). Is this more important than distributed computing, algorithm analysis, mathematics passed calculus (the more mathematics the better, my job involves statistics, noneuclidean geometry, differential equations, trig, etc on a daily basis), non-shell scripting languages (Python, Ruby), numerical analysis and scientific computing, technical writing, HCI, general engineering principles (or engineering specializations), databases, computer architecture, etc?
In my mind, specifying the number of "semesters" of each is not a wortwhile exercise. More important are "what concepts do they need to know." Tables 3.1, 3.2, and 3.3 in the document you linked to are an excellent way of breaking this down, IMHO, and much more effective than a nebulous decree that only species the course titles.
Integrate Keynote and LaTeX
It's my understanding that a good CS graduate should be able to pick up whatever language you want in a couple of weeks provided you let him/her know ahead of time what areas you develop in. The purpose of a computer science degree is to give the graduate a diverse background in the constructs and procedures underlying programming. The CS graduate who can't figure out how to solve a simple problem is deficient in critical thinking. It's a failing of the program he went through, and sometimes of his work ethic, but certainly not of the degree as a whole.
Essentially, you're right that CS teaches algorithms, but what you should be looking for isn't dependant on degree. You should be looking for a portfolio of projects that the student has completed throughout his schooling, possibly even before he got into college. You should be looking for competence, and proof that the student is interested in solving problems and not just in the CS degree as a certificate of employability.
The degree is usually just the icing on the cake for a good computer scientist. For the crappy ones, the degree is everything.
SRSLY.
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.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
My experience is the complete opposite. Any reasonably competent CS degree holder would immediately be able to identify an appropriate sorting algorithm for most problems. I can't imagine anyone with that background agonizing for 2 seconds over the problem you mentioned.
The college programming course guy, on the other hand, would probably look for the nearest library, and grab the routine that was called sort. He would then use it without either knowing what "introsort" actually does, or realising that (for example) if you're starting with nearly-sorted data it isn't the best choice, or if you're working with data sets that might contain duplicate keys the algorithm isn't stable.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
Open Source Java Web Forum with LDAP authentication
In my experience, this is the norm, not the exception, at least for large-scale work. I work at a major telecommunications company and am smack in the center of our software development process. Large companies are notorious for being run like a military: the grunts know very little about overall strategy, and are only told what they need to do to do their jobs effectively. Sometimes this means we need to see the company's goals and strategies, but sometimes those goals and strategies are things the company wants to keep out of sight, because they know it's going to be unpopular. We routinely see decisions made by management that appear to be sheer idiocy, clearly run counter to technical recommendations, with no apparent plausible benefit to the business.
In reality, many of these decisions actually are made with business interests in mind. The technical side of the house just isn't aware of it. All they see is a bad decision that nobody wants to explain. This is still a problem, but it's one of communication and trust, not necessarily competency.
Of course, just because I'm considering this to be the "norm" doesn't mean exceptions aren't insignificant or uncommon. In my experience, these issues are less common in smaller businesses as well.
Well it is obvious that your understanding of the market exceeds even that of federal judges who have studied it for years. No one can doubt your logic.
You have programming class, you have unix class, you have database class (sql) ... so you know all these....
... (hmm sendmail is not middleware technically) ....
But you most likely do not have MIDDLEWARE class -> apache administration, tomcat administration, Websphere, Sendmail, etc etc
My point is: people come out of school, and they do not know what ports are, how your code is deployed on a server, and have no ITIL (or some kind of IT management training at all). In other words, they might see the big picture, but have no clue what the code is running on, and how middleware components are interacting with each other, and the application.
I am new at a big company, and have a lot of experience, both dev, network, and admin. I see my colleagues, young kids with 1-2 years of experience, and it shows that even tough they are "software engineers" (just like me), they have no clue of these things, and they will need a few years to pick all that up....
just my 2c....
in short: yes, planning, developing, management, and MIDDLEWARE (admin stuff) + network is all useful and important. And yes, it is more important than an overload of math, or a bunch of other useless crap (no, math is important, but e.g. economy could have been less at my college.
The software development cycle is important, but pretty easy to pick up. You've been learning to meet deadlines for how many years now? And deadlines in school are much more restrictive than deadlines at work (depending on your professor/employer of course!)...
What I think most CS students would benefit from most, from my time spent in the industry, is a few business classes. It's important to know what the business people are thinking, if you want to work for them. You can't just ignore your manager, hope s/he will go away as soon as they start talking, etc. You have to learn how to interact and exploit your manager!
Going into the real workforce after leaving school was quite a shock. It's the politics I was unprepared for. I'd focus on that if I was you. But I'm not, good luck!
The easiest way to simulate the real world is to put students directly into it. By the time I graduated I had accumulated two years of work experience, getting me over the initial "fresh out of school" hump. Interspersing work terms relieves debt load, gives employers a guaranteed screening method for new entry-level hires, and teaches things that students may not have been taught (like the details of languages beyond just what is required for assignments).
A competent co-op program is probably the best way of learning both how projects really work and why a good grasp of the development cycle and its hurdles is necessary.
I graduated from Georgia Tech last year after finishing the 4 year CS degree.
We had multiple classes that had a whole "software development process," and I'd honestly look pretty skeptically at any CS program that doesn't. We had a Senior Design course that was required to graduate, and a required Software Engineering class that encompassed the whole "process." We had to go through the same type of process in a couple other CS electives. To be a bit more clear, the "process" was stuff like documentation and writing papers.
Having said that...I always took on the "master coder" role in our groups and stuck other people with the other stuff. I don't regret it, I've certainly never had to do anything besides code and test my own code now that I'm a developer. Granted, I never WANT to do general project planning/document writing/etc, while some people may find that desirable. Managers probably make more money. Don't know, don't care. I speak and type English very well, if too succinctly, and that's about the extent of my non-coding required skills. I hope to never have to write a 50 page requirements document.
Anyway, to the submitter, you're missing one huge aspect: teamwork. If you're going to try to teach The Real World, then students need to work with others.
Fortunately (unfortunately?) this is GREAT education because it prepares the students for the way the real world works.....