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.
My CS program, and most that I've heard of, have some large project as a sort of finale; guidelines are given, or even a broad topic (compilers, databases, and so forth) but the design, implementation, testing, profiling, and the works is left up to Teams that the classmates pick.
I did computing at AS (penultimate year of High school equivalent I think), we covered the theory of the system development cycles, did several mini projects that included the rest of the class trying them out e.g. lottery simulators, and the final project was pretty much as you described.
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've had to hire people before in different situations. And with what I've learned in the past, and from my experience, this is what I have:
When given the choice between hiring a recent CS grad or hiring somebody with a diploma from a 2 or 3 year programming course in a collage, I'd rather hire the collage grad.
Why? Because CS teaches ALGORITHMS, but collage teaches PROGRAMMING. If I hd to hand-hold one more CS graduate who spends 2 days agonizing over whether to use a quicksort of a bubblesort when faced with an unordered list of 10 items, I'm gonna kill somebody.
Life cycle is definatly a good idea - I'm actually surprised it's not there already. (I went to school 25 years ago, but for Soviet Studies, not CS)
As a former CS major, I would be very excited to see a course like this offered. So often comp sci "conceptual" learning is linked to software patterns or algorithms; the "skills" parts are in crazy blasts of code that you may or may not be able to understand a month later due to the time constraints on getting it going. Grounding in concepts such as development lifecycle or even how to socially interact/communicate with people :) are useful foundations for the real work you'll be doing later. I certainly wish I had the lifecycle understanding; looking at job postings, companies certainly seem to put stock in it. Then again, they also think UML is useful...
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
I'm currently in my second year as a CS student at one of the largest research universities in the country, and I'm pretty sure that we don't have anything like this, or at least not that's required of us. I think that this would be an excellent idea, but an alternative could also be requiring students to participate in an internship or coop program involving software development, which yields valuable real-world experience.
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 are several software engineering courses at my college (Georgia Tech). The class gets broken up into groups of say, 5 people, and we have to come up with all the documentation (planning, requirements, design, testing) at the same level of detail as a real-life project. We then have to juggle keeping up with documentation and getting the code done before the deliverable date. It's quite educational - I'm not sure why nobody else has posted about this...
(Oh, and make sure none of them are included in the group which ultimately has to evaluate the success of the project.)
Your Servant, B. Baggins
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.
I had a class called "Database project" where we were formed in small groups. Each group was given a situation where "X" company needed a specific database that would fit their needs. From there, we started brainstorming on what information the database needs to hold, design different ER diagrams trying to find the best solution. We'd every few weeks show what we had to our teacher and he'd comment on it, whether we would or wouldn't have any problems continuing to the next step. We sort of stopped where the database was up and running and didn't really work with the DB itself once it did run, since the semester was over!
:P
Other than that course where we had to progressively design a system and/or software solution, I'd say our other thing that we're doing right now that would come even close to what you're saying is the internship that I'm doing this semester. I know it's not a typical course like one where you to go to class every few weekdays and take lectures or work in the labs, but.. yeah.. thats all we got
It is an interesting concept though.
This is a question which comes up from time to time on Slashdot. I think the best approach is to pick an existing Open Source project and add a feature to it. That way students have to deal with an existing structure, existing policies, coding standards, etc., none of which are likely to be perfect, much as they would in the real world. Additionally, by focusing on a (non-trivial) feature, there is greater likelihood of actually completing the job in the time allotted. It gives the students a public chunk of code and a public acknowledgment they can point to. Lastly, it does the world some good. Different teams in the class can focus on different features if you like.
I can't believe that you didn't have a major project while at college. I'm proud to say that our Computer Technology program (www.sait.ca) has 2 major project courses that includes the completion of a comprehensive technical design document and then implementing the design. This takes place over 2 semesters and our students work in teams of 4 or 5. They must find a client who will be a technical advisor for the project. It's the only way students can grasp what it takes to complete a software project from concept to final implementation.
I graduated in 3 years (UK) with a BSc(Hons) in Computer Science and here is how they taught us: In the 1st year we learnt algorithmics stuff, in the 2nd year we studied software engineering methodologies such as extreme programming and finished a class-wide group project, and in the 3rd year each student completed an individual project in any language and any area we liked, and it was counted as 3 courses in the transcript. So, we learnt to work in teams and also alone. Very good.
Problem is in one semester you really can't complete any projects are worthy of a real software development lifecycle. You can complete a quick thrown together application, but you already know how to do that. If a 'real world' project, was for six months, it would not be worth throwing time into. And applying the process of a year long project to a six month project just confuses students who don't understand "why all the extra work?"
My experience is that most college grad CS students don't have a clue on how to do a real project (multi man year). But that's fine. They know how to code and they start at the bottom (which is the coders) and work their way up. Besides, you can not teach the 'right way' to do a lifecycle since it is usually different every where you go.
IMHO there are 2 different domains to lifecycle; The management domain: requirements management, change and problem management AND the design domain: Software Modeling (UML, Domain Specific Modeling and Database design which should be but is not always part of the application modeling because of legacy databases). Add to that a bunch of currently in use methodologies (xtreme, test driven development, agile etc) and it seems to me to just be too much for 1 class. I've seen a few attempts to put it into a Software Engineering class and the results where not good.
slashdot troll = you make a compelling argument I do not like the implications of.
the completed assignment should have some agreed business benefit and the student would need to estimate and track their dev costs committing to in-year investment payback. then the professor should show them how the loaded cost for outsourcing their effort is $20 per hour.
A class like that is absolutely essential. Any undergrad program which does not include at least one software engineering course is doing a disservice to its students. Such a course should include a study of development methodologies, requirements analysis, basic OO, user interface, and database schema design, source control system, basic project management, UML diagrams, etc.
I had a second software engineering course that also covered design patterns, unit testing, software architecture, and refactoring.
These two courses have put me is a far better position to be an effective software engineer than most CS grads. In large enterprise systems, the code most CS majors produce is crap -- it's poorly designed and poorly implemented. Understanding complexity theory or numerical analysis is a good thing, but in the real world, it's all secondary to understanding things like object-oriented design patterns. It's a shame more undergrad programs don't place a similar emphasis on practical software engineering.
-James
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
I am currently in a program at a college doing this very exact thing. For the last two semesters we have essentially our Final Project, which for the first semester is basically doing the planning and design stages of developement, and the second semester actually building it and implementing it basically targetting the end of the semester.
The really neat part is for our CIS progam, they encourage that we actually get a client and build a project that they need completed, and will actually be used by the client. This is for the added benefit of for 1 potentially being hired by the company upon completion, or atleast getting references and building contacts for future usage.
However, for our case, this project primarily is ours to design and build. We have a project advisor who gives us feedback, and who report to for our course mark, but doesn't really do anything beyond providing feedback, and sort of making sure everything gets done.
I find this concept for a final project to be very beneficial, you can actually say that you have real world experience in building a production system, that is used by a company. I would iamgine this would look a whole lot better to a potential employer then a student who knows the technology, but has never had the chance tow ork on a system deployed in a production environment.
I'm wondering if their CS program has ABET certification and what not. I find it odd that such a thing was not covered.
Part of the curriculum at ASU is an Introduction to Software Engineering course (CSE360) where we do nothing but study the design process, and spend the whole semester on a big group project.
Plus we revisit the concepts over and over in other classes like Software Analysis and Design (CSE460) and Databases (CSE412), which are, admittedly, electives... but the topic still comes up in almost any class that has major projects to do... or with the new CS/CSE curriculums which require capstone projects.
I learned quite a bit from being in the lab for 12 hours at a time, trying to iron out some requirements we missed in our planning stages.
I have taken a course like the one you have described. It was a 400-level at SUNY Albany, called Software Engineering.
The course was taught by an adjunct professor, whose day job was the CEO of a small (i.e. 7-people) local software house.
As a class, we decided upon what we were going to build. We were then divided into three "companies" that were to compete with each other to produce a finished product. We were to use RCS (this was 15 years ago), and write the app in C, to run on a UNIX platform. Some supporting BASH scripting was permitted.
The project we built was a calendar/schedule app, and the one our team built was called HERMAN. Alas, we came in second, but it was good enough for me to pass the course with a B. (grades were mostly based on the project, but there were tests as well that caused a shift in individual scores)
In recognition that the course was very difficult, the professor created a scoring system of 160 possible points, with 120 or greater mapping to an A.
www.wavefront-av.com
Assignment: Pick up the undocumented, buggy, unfinished, unspec-ed project from the previous years senior class (i.e., none of the original developers are still around to ask questions), and add a difficult, meaningless feature that has to be done by the end of the quarter.
Sigh. I guess I've been doing this too long.
And the worms ate into his brain.
The hardest part I had to deal with were the way other players in the process dealt with the development and the product. Customers, managers, projectleaders, all had 'irrational' influence on the projects and I often found political influence in what seemed strictly technical issues.
My experience is that this is a part of the work, in more or lesser extent (varies per company/product/project). It sometimes was frustrating but it could also be a benefit as it enabled myself to grow as a person, sometimes even fun because of the quality of the personalities of some managers and customers.
I'm afraid this is something that has to be experienced in reality, it can't be taught or simulated, I think.
Practicing a real life business case might be usefull to experience trade-offs in, for example, features vs. test effort, imho. Planning and maintaining a planning is incredibly hard, there's never enough time at the moment you need it and the 'other' people I mentioned above are going to be a pita just when you can't use it.
"I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
If the students are going to be designing a project, then it is vital that the "customer" is represented, and NOT by another CS major. Designing & building software for other programmers is easy. A much more important skill to learn is how to design and build software for someone who doesn't think like a programmer.
It is pretty insane that people on here are saying they've never taken such a course in their university/college career.
In Canada, not only will your CS/CE degree include such a course as mandatory, during my time in high school (this is in toronto) we had a grade 13th CS course that went through all the different steps of software engineering, going through the various waterfall/spiral dev cycles, writing specs, feasibility studies, to actually implementing and testing a project.
It blows my mind that people who would be working as CS professionals would not have such knowledge before entering the workplace.
sure I'll have a sig.
Whatever steps you pick in /your/ real-world scenario, don't forget the bit about "running out of funding" the week before you ship. [Yay, no final?]
/really/ into guns [look, I understand that there is *good* "into guns" and there is *bad* "into guns," and *then* there is this person's relationship with firearms that is best left unexplored in a public forum], and everyone is like, "Do we fire this gurl, or just secretly move the company overnight and not tell hier?" only the person lives in a van in the company parking lot, and even has the company's name on the van's vanity license plate.
And at least one sales type who goes out into the field and comes back with, "I promised the customer X. We can do X, can't we? Can we have X working by, um, Tuesday?" Where X is something like "a financial planner" and your company does real-time messaging software for PDAs.
A-a-and the cross-dressing halfway-through-the-(ahem)-process wacko cow-orker who decides to write everything in Oberon ("It's soooo cool!"), smells bad, is
Finally, the CEO who is a fanatic Beavis and Butthead fan, and looks nearly identical and sounds almost exactly the same as Beavis. "How come we have so much trouble getting funding?"
I wish to god I had made this up.
Any sufficiently advanced technology is insufficiently documented.
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.
I'm in my 3rd year as a Computer Science undergrad student at the University of Guelph, in Ontario, and the core curriculum for a Bachelor of Computing here has 3 Software Engineering-type courses, starting in 2nd year. Forgive me while I plug my school, but I think Guelph does a fine job in this area.
The first is a course (numbered CIS*2750), that leads you through developing an application, where each assignment is a milestone along the way. When I took the course, it was to develop a GIS-themed application. The first assignment was a DXF library for reading, writing, and manipulating (removing layers, etc.) DXF files. The second was to write command-line programs to use the library, and also to add more ways to manipulate the DXF files in memory (merging two files, for example). The third was to write Python wrappers for the library and a GUI using Tkinter. The final part was to interface with a database to add notes (and display them on-screen). The end-result was a fairly rudimentary DXF viewer.
I'm currently taking the second course (numbered CIS*3750), which is a group project (groups of 5-6, chosen by the students). The groups each pick a board game, and must write a computer version of it. There are three milestones for this course: the first two are documentation (subject matter model and technical model), and the final one is implementation. We just submitted the second milestone yesterday. Dealing with interpersonal issues, and the sheer size of the documentation (the documentation for the first milestone was 68 pages, and I think the second milestone was around 40 pages), are most of the challenge in this course. Of course, we haven't even gotten to the implementation yet.
I don't know much about the next course, except that it's called Software Engineering and that I'll be taking in the summer (I think). I know that Guelph tries to be fairly "practical", with streams like this, but I assumed that at most Computer Science programs included some courses like this. At any rate, there *are* universities that teach team programming and project management.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Whoops, silly middle mouse button...
One such course that addresses at least part of the development cycle:
http://www.cs.rpi.edu/~milanova/csci4440/ (Fall 2006)
http://www.cs.rpi.edu/~hollingd/sdd/ (Spring 2001)
Software Design and Documentation was a required course for a CS degree.
For me personally, it would be very beneficial to see it all fit together in the end. Couple quarters ago our instructor, instead of teaching us rudimentary Java skills, and since all of us had already taken a number of his previous courses, within a couple days he broke free of the standard curriculum and had us code a SMTP email program. We were given the basics it needed to do and the rest was up to us. Each of us worked on it individually and I can tell you the learning experience was a good one. No one to hold you hand, no one to push lame work onto to, and lots of your own research. Your idea is excellent and certainly goes a couple steps farther than my experience. I would immediately sign up for such a course.
Different colleges have different goals and approaches; you need to pick your college to go with your goals. Many CS majors do not go on to become software developers, so it is perfectly legitimate for a college not to include project development experience in their courses. Even if you picked such a college, nothing prevents you from participating in one of the many open source projects or to start your own.
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.
I recently graduated from the University of Dortmund in Germany. I must say that compared to a lot of what I read on slashdot, it's been a great experience and quite well designed. Besides the obvious data structures, theory and programming courses, we also had several projects. During 2nd or 3rd year, we did a one-semester thing in groups of about 8 students. We were provided with specifications and had to develop two applications, one a game and the other a more serious app. The whole cycle was required, starting with annoying UML diagrams and finishing with a presentation of the applications at work. We worked around most of the requirements, such as coding first and then using a program to generate the UML diagram from the source for us - but that was only because the lecturer totally failed to explain the benefits of UML to us. To be honest, while I see the reason to specify interfaces and APIs, I still think UML sucks.
The second project was much better. A whole year, 12 to 15 students, just one application and a very light load with other classes so that we could easily spend 20 hours or more a week on it. This time, we had to start completely from scratch, with just a vague idea of the direction we would be going. Again, there were specifications to be written, UML diagrams to be drawn and reports to be produced. Of course, there was lots of coding, but also all the pain of integrating different modules, testing and bug fixing. In the end, this second project was a great experience. Because we were running things as we see fit, we much better learned that yes, specs are useful and yes, CVS (or any other VCS) is necessary and that no, you cannot depend on anybody else to do your work (or their own, really). I know for a fact that some groups ended up working well into the following summer as they did not get their product done on time. Only this kind of approach will teach you hard reality IMHO. If you know that you will be done by the end of the year no matter what, you do not put as much effort into organizing things properly.
And finally, everybody has to go through writing a thesis, of course, which in most cases is a 9 to 12 month development and documentation project. While it's not cooperative, you get to practice the whole software life-cycle one more time. All in all, I think my university prepared me well for whatever may be next.
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
As a professor I see much of this has been solved as far as curriculum for Computer Science is concerned...
A student needs at least math theory through discrete mathematics, and better yet through calculus...
You're a "professor" of "computer science" and you think all a "computer scientist" needs is "discrete mathematics" [whatever the hell that is]?
Maybe, just maybe, a "computer scientist" might want to know just a little linear algebra & hilbert space theory, so that when they are asked to run a least squares regression, they'll have just the vaguest idea what all that AA* stuff is about?
Or maybe they might need to know just a little bit about fourier analysis & the discrete fourier transform, so that they might understand the manifest importance of the improvement from O(n^2) to O(nlog(n))?
Or maybe they might need to know some group theory, so that they could understand something like the Polya-Burnside method?
Good grief, and people wonder why the Chinese & Indians are cleaning our clocks...
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.
Yes, such a course would be very useful. Some people are already teaching courses like this. (See, for example, http://philip.greenspun.com/seia/ )
One difficulty with courses like this is that it puts a different kind of responsibility on the instructor as well as the students. The instructor doesn't merely stand before the class, pontificate for 45 minutes twice a week, and grade routine problems sets and examinations. Rather, the students have to (either independently or in consultation with a "client") build a real, working piece of software. The instructor has to do more mentoring than lecturing, and will have to spend more time and thought grading what the students come up with.
It's about turning CS students into engineers, rather than just programmers, and it's an extremely worthwhile thing to do.
My university has courses like this already. They call 'em Software Engineering I and II. You start off with a problem. You have to write the proposal for the professor to make sure its not some idiotic project like "build a shopping cart." Once it is approved, you have to go from design through implementation. I'm sure they'd go further if the semester were longer. We have to do everything from use cases and statecharts to the actual coding and testing. Through the first half of the semester, you don't even talk about platform or implementation details such as programming languages, and supporting technologies. My team would meet at least twice a week for 3 hours at a time. Trust me, you would experience a lot of the turmoil that a lot of real-world programmers go through. I haven't taken the second course yet, but I definitely plan on it even though its not a requirement. Software Engineering I is required tho. Many students take it as their last course before graduating.
I was crazy enough to attempt dual degrees in CS and Electronics Engineering. Due to silly requirements and competive politics, I ended up getting more CS credits than engineering and dropped the engineering degree. Anyway, in CS, the only large project I worked on was a C compiler, but that was really just a series of weekly homework assignments. There was no actual project oriented offering. In EE, I got to work on 2 large projects: one was the 2nd half of the class, the other was semmester long, and involoved teams of 5 or 6 students. We did planning, requirements analysis, design and implementation. While my profession career has been 90% software work, it was the EE program that prepared me the most for the real world. As for co-op/internship programs, at all the clients I have worked for, the CS students I saw were treated like "gofers". This is very unfortunate, though in recent years, I can begin to understand. The students I've worked with had almost no practical skills. Oh, they could write simple programs to do calculations and sorting and such, but were totally lost in the realm of complete applications, let alone integrated systems. The EE stufents, however, were much better prepared for realities of business.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
My degree was in CIS, which is different from CS, but we did this at my university. The way it worked was basically that potential clients would contact the school, and the professors keep track of available projects. A few weeks before the term starts, students would talk to the professors, get the list of projects, start putting teams together, etc.
Once a project was accepted, the students would go from a basic "we want a system to do X" statement all the way through developing a finished project for a client. Students would have meetings with various faculty members to review their designs (we had 3 meetings with faculty, one to approve our database design, one meeting to approve our overall design, and one to check on our progress). Students were allowed to use any technologies and development methods they chose, as long as the client approved. After 15 weeks (or 30 if the students chose a 2 term project) students gave a final presentation. The total number of points given came mostly from the clients themselves, and the percent of those points given to the team members were decided by the team- so your grade relied on how happy the clients were with the project, and how your team members felt you contributed to the project.
On the whole, I think it worked pretty well, but there are a few caveats that need to be addressed when doing something like that. The biggest is that, in most cases, nobody gets to share in all of the experiences because work is delegated, so you still end up with people only really doing on part of a full project. In the worst case, you end up with one person who does all of the work, and other students just coast along (that's pretty much what happened to me during my project, I did 100% of the design, coding, testing, and implementation, and about 80% of the documentation, in a five person group). You also end up with groups taking on projects that are too large or too small, and clients who are uncooperative. It's a delicate balancing act to give students real world experience without essentially setting them up to fail.
The biggest benefit to it, and the reason why I think it's an excellent idea- even with the problems I mentioned above- is because it's almost impossible to fake your way through it. Students can try to coast through, but with honest teams they will be marked low and won't pass. Cheating isn't an option, since every project is unique and there isn't anything to copy. You will also find that there are some students who are completely lost on how to see a project through from start to finish, and others who can do it (relatively) easily. If you get a good mix, you end up with a good opportunity for less experienced students to learn from more experienced students, while at the same time giving the more experienced (as developers) students learning about working in groups and dealing with people who are not as good as them (something that the brighter students need to learn, because it is something that really good programmers are going to run into everywhere and need to be able to deal with- I'm glad I learned how to deal with that during my project, it helped me a lot when I got into the real world).
The last thing is that, as I mentioned, I was a CIS major. CS is an academic subject- your teaching people to be scientists who study computers and algorithms, not training analysts and code monkeys. Granted, a lot of CS students will go on to be developers- still something to keep in mind though.
Famous Last Words: "hmm...wikipedia says it's edible"
First of all, let me just state for the record that there are programs that specifically teach the student the entire software development process with final team projects. I graduate from the University of Detroit Mercy and they have the type of program that you spoke of. In this program I studied the entire software development process. We were taught to develop a software project managment plan which encompassed all of the necessary work products in software development. We learned and studied extensively all of the IEEE software development processes and standards and then appplied them to our group project. I took classes in compiler theory and design, advanced software architecture design, model based design using statemachines and autocode generation, I studied advanced software development with C/C++, Java and MYSQL. The program was co-hert, which meant you had the same team members for the entire 2 years of this particular Masters program.We also studies project management, CMM, SPICE and Trilliam. Quality Management Process Plan Schedule Review Requirements Review & Control (IEEE 830, 1233) Requirements Development Requirements Management Test Environment Consideration Quality Reviews & Audits Systems Design Review (IEEE 1233, 1471) Architecture Review Architecture Design Change Review Architectural Design Documentation Review & Audits Hardware Design Review Hardware Schematic Review PCB Review Hardware Design Change Review Hardware Design Documentation Review & Audits Software Design Review (IEEE 982.1, 1016, 1098, 1471) Low Level State Diagram Review Source Code Static Analysis Review (QAC) Software Design Change Review Software Design Documentation Review & Audits Test Plan Review (IEEE 829, 982.1, 1008, 1012a, 1044) Test Case Development Review Test Case Management Review & Audits Test Execution Process Review Unit Testing System Testing Documenting Test Anomalies Anomaly Review & Corrections Anomaly Re-testing Test Summary Report Review Quality Reporting and Communication (IEEE 730) Sr. Management Reports Metrics Quality (IEEE 1045, 1061) Defect Tracking Problem Areas Process Effeciency & Effectiveness Program Health Status Additional Metrics defined after organizational assessment Supporting Processes Configuration Management Independent Verification & Validation Documentation Problem Resolution Process Improvement Systems Engineering Process Group Systems Engineering Process Improvement Initiatives Process Model Methods, Tools and Techniques Process Training Process Measurables "Executed by Consultant" As, you can see the program was/is very comprehensive and I learned a lot. Since then, I have successfully gotten jobs as Sr. Software, Technical Specialist and now Software Supervisor. You just have to choose the right college or university. Good Luck!
... should be required.
At the University of Oregon, we had CIS422.
This included sections on project management, software lifecycle, requirements analysis and engineering, and development models. While I did not go into development or software engineering, I work with developers all the time and it's certainly helpful to speak the language. Also, project management skills are necessary in any kind of work in IT (and most other fields, too).
At UO the software methodology class was treated as a "capstone" type of class and we had to do some reasonably substantial projects that kept us working late hours.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
If I were a student looking at colleges, I'd look at the CVs of the professors with a very hairy eyeball and be very suspicious of any CS program that's staffed with academics.
The other thing to consider is forgoing the trade school (which so many engineering schools actually are, not colleges) and concentrating on the a more traditional education, rounded with humanities, history, and philosophy, whilst keeping up with the math and other core requirements. _then_ go to grad school and round out your education with a trade. Yes, it'll take longer but you'll end up being a more rounded individual for it and, I would observe, far better armed with perspective, critical thinking and social skills.
The latter will do you better stead in dealing with people and situations than a head full of algorithms and programming languages. And, given what I'm seeing with the latest generation of Web-ness (can anyone define "Web 2.0" for me) skills understanding the Greek and not the Geek are going to matter more and more.
A famous example of this is (or used to be) the Census Bureau of the US. They'd go for PhD philosophers, knowing they understood logic and critical thinking, could be provided a much better paying job than they otherwise might, and world-class lunchroom conversations :-)
In the CS program I attended and completed 'Software Engineering' was a year long final course that everyone had to take and pass to exit the program. The first week of class teams were formed and projects were picked from a list of things that would be helpful for the school. Teams met with their project sponsor and then worked on a year long project which culminated with a team presentation at the end. Last time I checked many of the projects that get built are still in use. Of course not all teams finished, and many learned a lot of valuable lessons the hard way about scope creep, communication issues, etc...
Class time during this year long class was spend learning about project methodologies and the history of software project management. Plus it touched on lots of accessory topics like defect management, testing, etc...
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.
Many CS programs have a "capstone" course -- a popular concept in Engineering colleges. Many capstone courses involve projects sponsored by industry which go through a development cycle (as much as can be done in a semester). For example, at my school (a midwestern USA "Big Ten" state (public) school) local and national companies (names you'd recognize such as automobile and airplane manufacturers) provide projects for teams to complete. A contact person from the company is the customer who provides the specifications and evaluates the product at the end. Teams of around five students in or near their final semester carry the project through from specification to delivery. Many, but not all, of the customers from companies are graduates within the last five to ten years so they are familiar with both the company and the capstone course. The projects they bring are usually projects, often exploratory, which companies would like to investigate. For example, an automobile manufacturer wanted an add on to a car audio system which tracked friends using cell-phone technology. In this case, a simulated demo system was built. For local and smaller companies a web presence has been developed and deployed, usually backed by a database. Some products are directly used by the company. Some teams are offered jobs as a group with the company. Most companies are repeat customers, and there are more companies than we have teams.
The set up I described is not unusual, and essentially every department in our Engineering college does something similar. I accredit CS programs and have visited many schools with similar setups.
If you Google for "capstone course" CS site:edu, you will get a lot of good hits.
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.
I am enrolled in Software Engineering in college right now in my 4th semester. Within some of my classes we have talked about the SDLC and in my final semester(6th) there is a big project in my schedule. I imagine that it will encompass the whole SDLC. I think that its a great idea.
My program is called Computing and Software Systems. Its a CS program but also puts some emphasis on project management and related skills. One problem with current CS curricula is that they are geared for computer scientists when most people in CS programs are there to become software engineers. Most schools don't make a distinction, and very few people learn how to engineer software. I think this is one of the biggest problems in our industry and is the cause for the large amount of buggy and insecure code. So, yes, I think teaching the software development life cycle is important. However, there are a few problems with programs like mine. The first problem comes from trying to implement a team based strategy. In the workplace, there is always a boss who can fire somebody, or a lead engineer who can make the final call on a design decision, but at school it is very hard to establish a real chain of command. Getting this to work in school is an entirely different matter. The other issue comes from trying to give one large assignment for the entire quarter to teach this. The problem with this is that the full importance of some stage, such as planning and prototyping, isn't realized until the later stages of the process. At this point its too late for students to go back and assess what they needed to improve in a previous stage. It would be much better to have 2 or 3 short projects due so the students can apply lessons learned from each project. If on the first project they realize that making a class diagram really does help but its too late to implement that, then they can at least practice this on the second project.
Perhaps if the degree was in Software Engineering, I'd say maybe. But with CS or CPIS it is much more important to learn structured and OO programming skills and best practices, some mathematics, UNIX, pattern matching, database and basic SQL, and so on. This needs to be the primary focus because *every job is different* and you may not know what to expect upon graduation. Besides, the software development cycle is quite different from job to job, as is practices for version management (some shops use CVS, some ClearCase, for example). That kind of stuff you learn on the job and is relatively easy. what I think should be taught are the basics of good software DESIGN (as opposed to development), which was something that was sorely lacking in my college. Stuff like learning to make class, sequence, and activity diagrams, as well as writing good Unit and Integration test plans are essential. But then again, I'd say these are more Software Engineering practices that I am not sure have much place in a traditional CS degree, especially since CS is supposed to be more mathematically inclined.
Its called Software Engineering and there is texts out there for such a course.
>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
Neumont University solves all this, just read below:
.NET and Open Source development environments.
.NET and other leading industry certifications
* A digital portfolio of projects
"Neumont University is educating the most sought-after software developers in the world. Located in Salt Lake City, Utah, the University offers accelerated two-year Bachelor of Science in Computer Science degrees and Master of Business Administration degrees in one-and two-year formats. Neumont University is accredited by the Accrediting Council for Independent Colleges and Schools (ACICS).
Neumont University's curriculum is project-based and focuses on the skills most valued by today's employers. Students are mentored by the industry's most distinguished faculty members, and receive advanced training in modeling, architecture, and business processes. In partnership with IBM and Microsoft, our program places emphasis on students gaining fluency in WebSphere,
The Neumont University program is accelerated. In about 24 months graduates can earn:
* A Bachelor of Science in Computer Science degree * IBM,
Neumont University is committed to preparing students for today's demanding technology careers. Some of the careers in software development include software engineer, systems architect, web development, systems analyst, data modeler, and programmer/analyst."
I went to The Evergreen State Collage in Olympia WA and my senior course in 95/96 was called Student Originated Software, which did exactly that from feasibility study to first beta.
We had a software engineering course in which we divided into groups to design a large software system. We didn't get into the development of it as the course's focus was on the design aspect of software engineering. There was a second course scheduled that would actually develop one of the systems that was designed, but it ended up being canceled due to a lack of enrollment (I would have taken it but I had another course I needed to take in that time slot). But it still ended up being one of the most useful courses I took. Then later I worked with a team in a undergrad research project, which was also very useful.
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
Didn't your CS programs have "software engineering" courses? Here are the courses from the two Universities that I've been a student at:
University of Manitoba: Description: 074.335 Software Engineering 1 (3)L
Introduction to software engineering. Software life cycle models, system and software requirements analysis, specifications, software design, testing and maintenance, software quality.
Course homepage here. The University of Alberta has a similar page here.
Is this unique? Doesn't every CS program have 1-2 courses that exactly focus on gathering requirements and building some code as a team? Maybe it doesn't work - in my experience the best/most motivated programmer in the group ends up doing 95% of the work... but the course exists.
No report on computing curriculum would be complete without the topic covered on page 2:
[This page intentionally left blank]
I'm just in the last week of finishing my Computer Science degree at RMIT university, Melbourne Australia.
:) )
I was generally quite surprised, but pretty much every subject we do, from the initial programming subjects, to the actual 'software engineering' intro subjects stress design processes. We end up doing UML diagrams, and planning, etc, as much as possible. We also get some introduction to development tools as well.
For instance, in second year, there were sections on the marking guide referring to our use of CVS for code versioning, etc for two projects we did in consecutive subjects, along with having to submit the usual requirements and design documents, plus test plans, etc.
That said, our course tends to avoid the use of many of the development tools (you won't run into VC++ or VS.net or whatnot, unless you do a subject specifically centered around it), except for Eclipse, which they've started teaching to the newbies for some reason (much to the annoyance of the old guard.
ash
At the North-West University of South-Africa we have a course "systems analysis and design methods". We are required to know the theory like parrots and to be able to apply it to create a project of our choice, following the steps outlined in the book. Last year our group of 5 students created an instant messenger, the documentation, design requirements and all that. If you contact me at iwan.pieterse@ "google email address.com" I will send you the email address of the lecturer who instructed us. The book we used is Systems analysis design methods - McGraw-Hill and ISBN 0-07-247417-3. The lecturer wrote a comprehensive study guide also, marking sheets, the works.
This is my sig.
Those "many markets" are the ones where Microsoft has a monopoly (desktop). Which explains whey Microsoft can change their design from Win2K to WinXP to WinVista and yet people will still be using it.
If the sale hinges on the colour scheme and logos, then save everyone some stress and take the client out for drinks and hire a hooker for him.
Yes I know it does everything we want and it's within our price range
In my experience, it is not "Darwinian" at all.
It's all about who you know, where you are and what the economy is like at that time.
Which is why when the economy turns down, so many companies fail. Anyone can captain the ship in calm weather.
Who is this "we"?
At times that is correct. But it is the exception, not the rule.
Again, at times that is correct. But it is the exception, not the rule.
Which is the reason you'll see management books written about cheese while others are written about fish.
I think you have your arks wrong.
Score 6 Hilarious! Dude, that was good man! I'm still in tears... Too true too.
I have a BSCS from a state university and it did *NOT* give me real world computing knowledge I needed for real world development environments. I learned it in large part on my own!! Most school bus employers are simply looking for cheap labor that can mold minds into a corporate culture of their development ideologies. Now that I have over 16 years of experience in various programming environments, I can say this. In general, Universities (overly rated) are institutions that give you the fundamentals, no more no less. Expect anymore than you fool yourself or you walked into the wrong learning institution. It is as simple as that.
At my Uni ( James Cook University ) we did this.
There were two courses, the first semester(6months) was basically documentation, choosing a project ( preferable a real one, with real life clients ) and getting everything ready for implementation. The second semester was performing the actual implementation. Throughout the entire thing we had a lecturer who was our sponsor who would make sure we stayed on track and did QA correctly, and we would also have 2 or 3 seminars to update the class on the progress so far. It was really fun actually and we learned alot about life cycles, risk assesment/analysis, Work Breakdown, time management, documentation and so forth.
I don't need to test my programs.. I have an error correcting modem.
Back 15 years ago, we had a class like that at the University of Maryland. It was elective, not mandatory
We had three teams and three stages to the project.
Each team did a requirements analysis. Then team A passed that on to team B to develop into a high-level design (while team A in turn got a requirements analysis from team C). In the third stage the design was passed along to the next team who then had to implement it.
Pretty much a straight waterfall model, which you wouldn't want to do on a larger project, but I think it was a good model of the process.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Search for "Computer Science" + "Senior Project" and you find many MANY universities already do this, and you can get their general curriculum and project ideas from their pages.
I went to the University of Colorado CS department and they solicit ideas from local companies who sponsor the projects/students. Less time for the professor, local companies like the projects even if they are only 1/2 usable, students get more 'real-world' experience than just a project, they actually get to work at a company, often get job offers, etc...
Space and Computers.
Rochester Institute of Technology has an entire Software Engineering department. Students who take the basic Software Engineering course learn about the software development cycle and work in a team to develop a basic program. I don't see how a Computer Science student could graduate without a little background that area. Maybe that's why there's always an abundance of code at The Daily WTF?
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
I'm surprised that there was no capstone course at your college. I've not heard of a college educating students, but not requiring them put the knowledge to use before being allowed to graduate. Its like teaching the students, but not testing them on the material.
The "Senior Project Course" at universities here (Louisiana) is one of the most anticipated courses. Projects are generally required to have real world clients, full project documentation and are to be accomplished in a single semester. Many go on to be the foundation of start-ups or provide jobs in the client companies at the end of the project.
For focus on teamwork, there are other courses offered at SELU Hammond and UL Lafayette that focus specifically on team work by having a class split into several different teams that each work on duplicate modules of a large scale application. The teams then make bids on the modules built by other teams and incorporate them into their application. The goal being for each team to construct the same functioning application using different pieces "purchased" from other teams or developed themselves, both on time and on budget.
It teaches all teamwork, many Leadership skills, and shows that software development in a team setting requires a higher level of organization that is not required when working alone.
The Computer Science programs at the universities above focus on problem solving and software development for research, rather than software production for businesses like ISDS or MIS degree programs found in many business departments. Teamwork and software development cycle are important parts of both curricula, but the Computer Science curriculum tends to shy away from teaching specific methods of team coordination while MIS and ISDS teaches students specific solutions to specific business problems and specific team work methodologies using specific software tools.
The people studying ECE/CS are there to learn how to think, and to learn the theoretical foundations that will enable them to drive technology into completely new, unforeseen places. Thats what engineering is all about. If need to be handheld into learning one language after another, then engineering is the wrong place for you entirely. Walk into any of the very best law schools in the U.S, and you'll discover that they teach their students HOW TO THINK, not how to regurgitate the laws of a specific state.
At the small private university I go to our CS department has a senior project we must complete before we graduate. Typically, the senior project has 2 classes for this. During your fall semester, the first class establishes your project, group, and introduces the planning process of the project as well talks about the moral parts of intellectual property. It mostly tries to create the role of a project manager for group members.
The second class, taken in the spring, takes all your project management artifacts you created (e.g. work breakdown schedule) and then implements them into creating the actual thing you've planned out. In the end you present your project to our CS faculty and your stakeholders. The projects we get are real world projects that we get from businesses which a lot of the times gets used in their organizations.
We've got a course like that. And Linus studied here as well so I reckon it's for the better ;)
I am a senior at a Liberal Arts institution that offers a Bachelor's of Science in Computer Information Systems -- I'm quite surprised you guys don't go through that in CS.
I would suggest the following
3 hours
Software Testing and Verification
Systems Analysis
Systems Design
Senior Project 1
Senior Project 2
(With SA SD, SP1, SP2 being taken as half semester courses (4 hours a week for 8 weeks - it equals a full semester) and taken in that order.
http://crusader.bac.edu/courses/CS309N
http://crusader.bac.edu/courses/CS310P
http://crusader.bac.edu/courses/CS414Q
The senior project is where you build an information system for a non-profit organization. My CIS courses
War isn't about who's right. It's about who's left.
Take the most poorly developed project from the first semester, and now each student must now fix all the bugs in the software without re-writing it. Make sure the variables are totally meaningless like "x", "y" and the like. Also make sure the program does lovely things like query a huge database table, and then loop through each record programatically and query another table within the loop instead of using those new confangled "JOIN" and "WHERE" SQL statements.
What you are describing is offered at community colleges in Canada. I attended Seneca College's 3 Year Computer Programming and Analysis program. On the last year of the program, students are exposed to the creation of a real life project from start to finish. Teams of students must find a real life company that is willing to allow these students to launch this system within the company (companies willing to accept a free system that solves a business problem are not hard to find even if the system is built by students). The whole process is split into two semesters having the design of the system on the first semester and the implementation on the second. During both parts, students are supervised by instructors who monitor the process. The whole process follows "the book" as close as possible. This means students are exposed to things such as project proposals, cost analysis, requirement analysis, project specification documents, legal requirements, design exercises (full blown UML design, screenshots, prototypes), project management using tools such as MS Project, and the implementation of a relative complex system. Aside from that, students also exposed to team dynamics, learn how to deal with real life clients while sticking to a plan and schedule.
I personally found it to be a valuable experience which not only looked great on the resume while I was trying to get my first programming job, but also enriched the technical knowledge I had already gotten through other courses. I'm surprised there aren't many "recognized" programs that try to to close the gap between the theory of a CS degree and pure programming/systems programs such as my old college's. This is part of the reason why I'm now working towards my CS degree at University, in order to see the field from both sides. However, 6+ years of post-secondary education (undergrad) may be something that not everyone can/wants to do.
[alk]
Yes, because no one learned to program before there was C++. And certainly every language guy I know loves it like their own mother.
I know at my school, all CS majors are required to take Software Engineering I which covers the entire software development life cycle. The problem is there is no emphasis on quality of project, and 100% emphasis on paperwork. My team got a C because some TPS reports were lacking in detail regardless of the fact that ours was the only project that actually achieved the goals.
Nullum magnum ingenium sine mixtura dementia (There is no great genius without a mixture of madness) - Aristotle
Computer science and software engineering are two different things. What is now called CS really needs to be separated into software engineering and pure CS. The CS people really don't care about software dev cycles and databases, and the SE people don't care much about Turing machines and information theory. The problem is that the CS department is clogged with students who just want to get into the industry, and the professors want to teach a more theoretical approach to CS.
My school (Rochester Institute of Technology) was actually one of the first in the nation to offer a degree in Software Engineering. As a CS student, I was required to take a SE course as part of my ciriculum. The course was only 10 weeks long, but it introduced me to the entire software development lifecycle. After graduating, I found a job as a software engineer at a small company. Having taken the course, really helped me in writing SRS docs, contributing in designing software, and testing. The company I worked for was very small, so I had the oppurtunity to participate in every phase of software development. I would also suggest a course in technical writing if one wants to persue a job in SE. Professional communications is an important skill IMO.
Head to a place like the University of Saskatchewan. In terms of group-work classes, you get:
CMPT 250 -- Introduction to software development.
CMPT 332 -- Operating system concepts.
CMPT 352 -- Computer security (can do an implementation project for your group project).
CMPT 355 -- Theory and application of databases.
CMPT 370 -- Intermediate software engineering.
CMPT 371 -- Software managemeng.
CMPT 432 -- Advanced operating systems concept.
CMPT 470 -- Advanced software engineering.
CMPT 481 -- Human-Computer interaction.
The 4 years honours software engineering degree requires most of those, the 4 year honours degree requires most of those, and the 4 year degree encourages you to take them.
The software engineering honours also requires CMPT 405 -- a full year-long individual project design and implementation course.
I thought such a curriculm was standard, since places like UBC, U Toronto, Waterloo, etc, seem to have equivalent classes. Perhaps instead of pitching such things to schools which don't have interest in them, you should shop around to other institutions which have the resources to offer a wider breadth of topics. Even as a non-Canadian citizen, you only pay a tuition of $1,000 per class, or about $10,000 a year if you take the absolute maximum course load allowed in the sciences department. How much did you pay per year at your US institution?
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
When I was at university we had a couple of group projects in "software engineering" papers. They were the absolute suckiest thing ever -- like working in a company where no one had the authority to make an actual decision, there were no experienced people who knew what they were doing, and where you had no possibility of firing the guy who implemented his part totally wrong, let alone the guy who did nothing at all.
... you get the idea. Those -- and the ability to talk intelligently about things -- are more important than grades. A+'s are great if they are found with the previously-mentioned things, but a guy with B's who has *done* stuff is better than a guy with A's who has never had the urge to create something outside of class.
From what I've heard, nothing much has changed. And how could it?
As someone now involved in hiring recent grads (e.g. one starting tomorrow and one starting in a week) the things I'm much more likely to look for are active involvement in Open Source projects, or having published a shareware or freeware program or interesting non-static web site, or having run the student network, or set up a mini ISP or VOIP PABX for their friends, or
This should be a mandatory requirement to graduate with a computing degree. Here's why (and I'll try to break this down in sequence of the things you would learn in a basic, real-world project):
You become accustomed to engaging with a client.
Prior to this kind of project, for most students, "client" could be substituted for "Mom & Dad" or equivalent. So when you actually start dealing with a client with real and strict(er) requirements, you begin to understand the importance of a) communicating effectively as to ensure that there's ambiguity, and; b) being extremely attentive to what the client is looking for. In other words, reading between the lines.
You begin to appreciate the need for organization (task assignment, delegation, etc.) within a group
Having a group of three-five+ members without any organization will obviously result in a mess. You will clearly recognize that the group needs structure, and this mimics real work environments. People will elect (or chose) duties as it aligns with their skills. And some things you just have to suck up and do. But in hindsight, you will see the importance of organizing yourselves properly.
You learn to write, design, and present technical information
So chances are your client will not be very technical. This isn't desirable from a requirements illicitation perspective, but it's very desirable from a 'speaking to a layperson' perspective. You will learn how to write, design, and present technical information to an audience that doesn't understand the keywords 'object', 'stored procedure', and 'web service'. The skills you pickup here will carry on with you and be used everywhere you go.
You learn the importance of/how to use a CVS
Odds are pretty good that in a group project you wil have more than one developer. So a CVS will pay dividends here.
You learn the importance of time management
This one is huge. You will be given a task that will take n amount of time. It will probably seem easy to do, but when you are one month from the delivery stage, it won't seem that way. You will probably be over your head in work and stressing that things are not being completed on time. This is where introducing a management system ahead of time (and this sort of ties in with my second point) will help mitigate time issues. Meeting with group members once a week (compared to every three weeks, for example) will help plenty in keeping the group on task and on time. You don't learn this when coding assignments that have a one week lifespan.
You learn that quality is of the essense
When you're handing off a deliverable to a client who is expecting to use and have a return on investment on this software, quality should become very important to you and the group. Programming assignments don't have this type of demand for quality.
You learn about development models/processes
Whether its waterfall, spiral, or extreme programming, you will gain an understanding of the advantages and disadvantages to development models. Plus when you really hit the job market, the development model a company is using probably won't seem so foreign. You'll also learn what Requirements Specification documents are, what it's like to write a User's Manual, and so forth.
Finally (and yes, there's a lot more...), you get the real-world experience
All combined you get to walk away with real work experience listed on your resume. This is very, very beneficial for someone coming out of University.
So a group project (at least eight months to a year in length) is beneficial in so many ways that it should be mandatory. Everyone heading into software development out of academia should be able to list this kind of experience on their resume when they graduate. Programming assignments just don't cut it.
For he today that sheds his blood with me shall be my brother.
I regret never being able to schedule this one when I was there, so can't comment on how it would have prepared me...
I went to a COmmunity College and no one returns my calls from resumes I submit.
The parent comment is really funny, and unfortunately completely accurate. And he didn't even mention the authoritarian micro-manager who holds *daily* meetings to go over the same 5 Sev-1 bugs, and asks you to work weekends and holidays because he botched the scheduling. You have been warned.
I'v been in the workplace for over 30 years with a BS (1974) and MS (1980) in Computer Science. One of my graduate classes (quarter based) was on this topic and was structured in the following manner.
The entire class (16) had a small subsystem to develop (5 to 8 modules - relatively simple). The course was based around the concept of dividing the class into a number of teams of 3 to 4 people.
Week 1 - Develop and document a specification (performance and functional)
At the beginning of every week, all teams traded work products (team 1's product went to team 2, team 2's went to team 3 etc. - it was setup such that no one team always received work products from the same team).
Week 2 - Develop and document a set of requirements
Week 4 - System design - a 5 minute System Design Presentation
Week 5 - Preliminary Software Design
Week 6 - Detailed Software Design - - a 10 minute Software Design Presentation
Week 7 - Code it
Week 8 - Software Test Plan/Procedures - Module testing
Week 9 - System Test Plan/Procedures - System Integration & Test
Week 10 - Installation Package and install into an existing system
What was interesting in particular to me was the degree that everyone else was unprepared for this development process. I had worked between my BS and MS for a couple of years for a military contractor and was used to the entire documentation life cycle. One of the items was each team was found that they had to develop a documentation model/standard. For the better or worse - I used MilStd 490 - not the best - but it was a structured practice that no other group had, thus my group blew past everyone else. Assuming a package from another group was an absolute disaster, especially since it was a different group each week. Some were ok, others were just terrible.
The focus of the course was not the item that was being developed, but the process and how information, ideas, technical approach and process is transferred from one group to another in such a way that the receiving group was able to continue to function with the input provided.
It was an eye opening experience.
As a former Director of Software, here are the things that colleges need to teach that folks I've had didn't know.
- Version Control is your friend. Know it, use it, love it.
- Backups rock! more than you know.
- Branching should be done in a minimalistic way
- If you haven't been programming for 3 years or more, you need to be a maintenance programmer.
- Code for maintainability first - speed last.
- Use long variable names
- Don't trust the compiler - you're probably smarter than the team that wrote it.
- Reuse other peoples' code - provided the license allows it.
- Learn about software licenses - know MS, GPL, LGPL, BSD, MIT, and understand how to read a license agreement
- Do a design on paper before you open an editor.
- Segment your files into something that can be grouped into a library and carefully manager dependencies. The data layer should never depend on the app layer. The app layer should never depend on the GUI layer.
- complex Web apps suck big balls - client server is best when you need a rich experience.
- write your code to help debug and locate errors by default.
- initialize all variables to known values at the beginning of every loop.
- Manage your pointers - when you free() a pointer, reset the variable to NULL. A null pointer error is easy to find vs. a wild pointer error. Not freeing memory is an error too!
- virtual destructors are your friend
- java, php, javascript and VB is for weenies. real programmers use languages that can wipe the OS by accident if the OS is stupid.
- Don't get addicted to caffeine
- Appreciate the QA team - they keep you from looking really stupid
- Programmers should begin as maintenance programmers, then up grade to testers/QA slime. Only after mastering these should they be allowed to wrote a module.
- purify rocks! Ok, it did last time i wrote code.
- bad news doesn't get better with age. Share problems that blow the schedule early so steps can be taken to avoid the late delivery.
- have fun, but get the work done.
- learn about control charts and apply it to your personal software process http://www.rbsc.com/pages/sixsig.html I worked at on the least "Defect Density" in this list.
If there was a single experience that you could arrange to have happen to a starting-out programmer that was going to really give them an opportunity to learn something, it would be code maintenance.
A lot of the problems in fresh graduates' code is based on the fact that they've never had deal with code for more than half a semester during an assignment and then it's forgotten. We can simply take the aphorism meant to get people to write neat code and comment "Use comments because in 6 months, your code might as well have been written by a stranger", and apply it to a course.
I personally learnt a great deal about what makes for good programming practice by going through a situation of my own making not unlike this. Fortunately it happened early on. While I think a course that actaully shows good techniques for dealing with all of this stuff is really important and probably useful, 75% of the students are going to ignore it as a waste of time unless you've arranged for them to go through an experience as that outlined above so that they'll actually realise what the point of it all is.
Nihil Illegitemi Carborvndvm
I graduated from UW-Madison in May with a degree in Computer Science and now work at a large corporation where the product I work on makes about three billion a year and has a very strict software development cycle. My part of the cycle is small in the grand scheme of things, but at the same time, I didn't feel fully prepared for it straight out of school. For one, there are eight releases a year (once a month when I started, now reduced to every other month and two special events each year), and the code goes through a dev, test, qa, beta, and production cycle. This of course made perfect sense to me when I started coding (90% Java, 10% PL/I), but it still took me some time to get used to it. Realizing changes I made three months ago are just this weekend making their way to the production servers feels really weird. Additionally, going through all the channels to make that change seems like overkill, but I'm only a small part of the process.
I really wish I would have had a class like this in school. Someday, when I'm rich, I'm going to donate loads of money to Madison on the terms that they have a class like this.
Reviewing just the first hour of video games.
I am a mature student completing an IT degree at an Australian University. This is exactly what I have just completed. This was split up into two courses, the first being Analysis and Specification, the second being Systems Implementation. Both had to be done as part of a team, trying to reflect "the real world" as best that can be done while a student.
The Analysis and Specification took the form of creating a specification document for a business changing the systems to a computer based system. The second was to complete the first as an implementation prototype and documentation.
I am wiser for the course/s! Knowing the SDLC and applying it to a real situation are completely different. I gained an understanding of how much time and effort is required to get the information needed just to design the system that the business wants, and the need for communication.
So to that end, my answer is yes! Simple knowledge of the process is all good and well, but until you actually do it, you have no idea of what actually has to be done.
Cheers
I recently graduated from a 4 year computer program at the local university. I now work as the lead developer on a small team. Our organization has a very strong internship program where we get college students for a summer, or part-time during the school year. The students coming in have pretty good problem solving skills, but college has not prepared them for making reusable and maintainable code.
The problem, based on my own experiences as well, is that the school focuses mostly on solving one very specific problem in the assignments. There weren't any large scale projects where you had to figure out the requirements and then break it down to the smallest parts and build your way up to a final product. My school had professors who covered concepts such as requirements gathering and modeling, but it seemed like an afterthought instead of a department-wide strategy.
I would like to see assignments where students have to fix and clean up bad code, so they know why it's bad and gain an appreciation for taking the time up front so future enhancements are easier to implement. This would be in addition to a senior project where a small team would have to go through the entire development process (requirements, planning, development, testing, bugfixes and enhancements, etc.) so that it's not all new to them when they start their first jobs. When I'm looking at a resume I do look at the curriculum of their school; If I see something along those lines I am much more excited to bring them in for an interview.
"back in the day" a 2-semester "project" course was part of any Computer Science Engineering program. It was an ABET requirement.
I don't know what the situation is today.
Of course, Computer Science sans Engineering didn't have to follow ABET rules.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I've been through such a course and I think it really taught me a lot. The class was around 25 or so kids, broken up into teams of 5-6. The professor went out to non-profit organizations and looked for software that needed to be developed. All of the non-profit organizations had a representative come to the class and pitch what they wanted developed. The teams would then place bids on three to four of the projects. The bids included a paragraph or so on information about why the team should get to work on the project. The teams would then have to co-ordinate the rest of the project by themselves and their customer. We had to go through 5 major stages and write up formal documentation for each. The stages included Project Plan, Software Requirements Specification, Software Requirement Design, Verification and Validation Plan, Verification and Validation Results. Some of the projects stretched over a few semesters so this would also give some teams experience in working with existing code and not trying to re-write everything. The best thing about the project was that it was actually used. A few projects included creating educational flash games for kids to be played on museums kiosks. I think I really got a lot out of it. You really learn to work in a team. Most will consist of the same set of people. A few will be really into it and will do most of the work. The rest will slack. We also get to fill out a mid-term and final team evaluation. Here's the link to the site, I thinks its been doing for 5 or 6 years now. http://www.cs.utexas.edu/users/s2s/
Two big truths here. First, all the really good people I've worked with in my short 1.5 years in the "real world" since getting a Bachelor's in CS, (you know, the 10% who do 90% of the real work) are all problem-solvers. They simply enjoy the challenge of solving a problem, and their work ethic doesn't hold them back. Second, "the degree is everything" applies to a few people I know who are uninterested in interesting problems, and basically seem to want to coast now that they're done with all the math homework, etc. of the CS degree. (I admit, to some extent that applies to myself, so I'm qualified to say so :)
While I'm a big fan of hands-on projects, there may not be enough time to code a representative project all the way from start to finish in a single semester.
However, there is plenty of time to model the application over its lifecycle, and, frankly, I'd rather have CS students learning how to model rather than spending a lot of time learning a specific language. Learning a language isn't all that difficult. I've had to pick up 5 or 6 languages during my career, and never found any of them to be spectacularly harder to use than any of the others.
Modeling, on the other hand, is something that is useful no matter what language you're writing in. Each step in the life of a software project uses a distinct set of information, and knowing how that informaton becomes transformed and refined as it moves down the pipeline is extremely useful.
As for a specific curriculum, I would take something like the Object Management Group's (www.omg.org) Model-Driven Architecture, and build a course around the whole process from a platform-independent statement of the business problem to the platform-specific implementation in a language of the professor's choice.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
CMSC 345 Software Design and Development. [3]
This course introduces the basic concepts of software engineering, including software life cycle, requirements analysis and software design methods. Professional ethics in computer science and the social impact of computing are discussed as an integral part of the software development process. Additional topics may include tools for software development, software testing, software metrics and software maintenance.
CMSC 445 Software Engineering. [3]
A continuation of the study of software engineering with emphasis on topics not fully covered in CMSC 345. Topics may include software maintenance; metrics; quality assurance; configuration management; deployment; project planning and management; and modern software development processes, techniques and tools. Students will be given multiple individual and cooperative hands-on assignments.
UMBC
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
I'm in my second year of Computer Science at the University of Virginia. One of my current CS classes is Software Development, and our final project is something just along these lines. Until now we've developed smaller programs under the guidance of our professor, like a simple photoeditor (Rhocasa, based off Picasa) and coded our own filters and the GUI. Our final project is an open-ended design in teams of 2-4, developed over the course of 5 weeks. We are using CVS and though the class has used Java primarily, we can choose any other language for development, provided we have a reason to deviate from Java (my partner and I are developing a Google gadget in C#, for instance).
I feel a project like this should absolutely be a part of a CS curriculum. It teaches critical team development skills, how to take advantage of modularity, and really get to delve into something that interests your team personally. My professor has done a stunning job of making our design problem sets interesting and challenging -- I don't feel like it's been the typical software class where the assignments are mundane, and you don't feel as if you've accomplished much upon completion of the work. The course site can be seen at http://www.cs.virginia.edu/cs205.
Any professor who doesn't believe at least one course of a CS curriculum should include a design project like this from start to finish (not necessarily open-ended as mine) is putting their students at a big disadvantage, in my opinion.
_miss rp
Last year (during my senior year), we had a class that did almost exactly this. We worked on one major project for basically a semester and a half. It started around November and we had to present our project in May. The general idea of the class was to come up with a project, or pick one of the projects the professor had come up with. After that, the whole class split into 4 groups (about 10 people per group). We went throughout the entire software development cycle from coming up with requirements documents, development plans, delivery dates, cost estimation, etc. By May we were supposed to have something that was ready to be delivered to the customer, along with any documentation or anything else that would be needed. I'd say all in all it was a rather interesting experience and I'd like to think it somewhat prepared us for the real world of software development.
For anyone that is curious, this was at Stevens Institute of Technology
Mark Loeser
When I did my undergrad in CS, we had a course that did exactly that called software engineering. Every CS major was required to take it. In it, you spent time covering every major step of the development cycle, as well as studying various different approaches to development. It also required a group project where you mimiced going through the development cycle.
Sunwalker Dezco for Warchief in 2016
I just finished High School in Australia, and i did the Software Design And Development course. This involved some programming, some hardware (hardware from the SD's perspective), etc, but about 65% of the course was the Software Development Cycle.
While it's boring as all hell, yes it is helpful. I am a part-time programmer and our company would definitely benefit from using the methods we learn in class.
Go back to school to take your senior design project(s). I didn't like school, never did. Struggled through all the prereq's for a CS degree, at the very end came two senior design courses. I learned more in those two courses than the rest of the theory they fill your brain with. Yes, the theory is important, and must be understood to pass courses like compiler design and os design (both of which I will leave to the professors, no true interest in the subjects). However I am one who really only identifies its importance with real world applications -- as such my business started while I was in my junior year, I was creating real life applcations, and when I got to the point when the class was on real life applications, a B- student led two very successful projects.
My advice to any CS student. Concentrate on real life applications. They will feed you theory, a lot of it. Don't focus on it. Unless you are shooting for the rank of "Professor".
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.
It was actually the largest course in our Computer Systems institute of Tampere University of Technology (and the whole uni). When I started the course I had no idea how much work it would require. Pretty soon it became very clear that the course would require hours and hours of work. And after couple of iterations of requirements and design documents themselves (not talking about programming yet) we started to panic that we could not graduate at all :)
It gave us excellent insight how software projects are sometimes larger than life and even pessimistic time estimates should be multiplied by some arbitrary large number.
That was hands down the best software engineering course I took. The entire course is a series of short, intense team projects to develop an escalating series of more complex software products- starting from a simple day planner and working up to a networked multiplayer game, with graphics and all. This was back in 2000, and it was really all about learning new concepts like MVC and other design patterns and applying them on the fly.
The most important aspects by far were the small teams and the fast pace, both of which are perfect training for doing anything fun when you get out- like starting software companies. Technologies and methodologies change, understanding design and how to work with people under intense deadlines is always useful.
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!
n/t
occultae nullus est respectus musicae - originally a Greek proverb
Sorry, I was lousy in French class.
.NET, SOA, etc). This stuff can be picked up from books, night classes, or professional seminars.
Comp sci at the university level should teach theory: the tough but fundamental stuff that you can't learn from a weeklong seminar. Architecture, assembly language, algorithms, compilers, operating systems, networking internals, DBMS, discrete math. Of course, some current practices such as using IDEs, shell scripts, and source code control systems, may be taught as a means of enabling productive lab work. But this isn't the real purpose of the curriculum, except at a college that bills itself as a trade school.
For students that decide to continue on with IT or software engineering as a career, there will be plenty of time (decades) to learn the practical aspects of software development, programming-in-the-large, currently fashionable languages and development environments (J2EE,
It was called system design it was a group project class. We had all the problems with people that didn't work with the group. The teacher gave out the lead roles to students who could be counted upon. Weekly every student had to submit grades for the students and how they were doing within their group. Everyone did a fair amount of work then cause their grade was at stake.
The first group project was to develop a simple game with specs that the teacher gave us. We did it and then afterward we spent 2 weeks writing a paper on our problems on how it worked out as a group, what we could have improved and stuff like that, then we spent a week of that time discussing that. We looked at software development lifecycles during this time also. Then we picked a style of cycle we linked and we were given the next project.
The next project was the largest to date and lasted till the end of the semester. It was to interpret the governments (tiger database) road data and build a piece of mapping software much like google maps, but it had to use their data, and we had to draw the maps and paths on them then. A group of 10 students tackled that in less then a month. It looked at algorithms, efficiency problems, gui design and also how to effectively use cvs solutions.
We completed everything on time. We spent alot of time in the lab and we were understanding of others outside commitments. But everyone had to carry their own load. It helped that our department is only 15 people 10 of which were in that class... So each of us knew the others well and how they worked or didn't.
As for being prepared outside I went into the work place with a semester of internship under my belt and was able to jump right in a be a productive member of the team. Others from the class had the same experience.
shameless plug... www.cs.moravian.edu it's class csci 334
There exists some positive integer N that you are the Nth person to read this signature.
You're talking about the difference between a computer science degree and a software engineering degree. At the Uni I went to, CS was billed as "research oriented", precisely because of the features you mentioned which are lacking from a CS degree.
The main differences between the degrees? An extra year in the SE degree, two year-long projects (5 person, then 13 person teams), and subjects on testing, requirements gathering, and management. Believe me, this stuff makes a big difference to your outlook on coding. Perhaps you should consider a postgrad masters in software engineering (they exist!), if you want a formal education in this area.
Bruce Sanders teaches a course at CU called "Software Engineering Project 1" (and "2") in which
students form teams that pick a project to work on over one year from gathering needs and
determining specs to coding, demoing and coding more.
The projects are submitted to Bruce from local businesses and represent a good selection
of things that companies actually *need* (although not very high priority.)
Bruce acts as the project manager and makes sure everything gets done, and done "right".
I took it in 1989/1990 and it was by far the best CS course I ever had. My team worked
on a tool to help deal with satellite image processing, although we made it more widely
functional than that because Bruce believes that limiting oneself or one's project
unnecessarily is not a good thing.
It was "real world" experience within the context of a senior level course. Extremely
valuable. His model is excellent - I'd recommend checking out the course at
http://www.cs.colorado.edu/ugrad/seniorproject/
Your success in college depends mostly on just being able to get all the work done. In the working world, your success depends much more on your people skills. There is NO correlation between school performance and work performance. The first study I am aware of on the subject was done by the US Navy. They were interested in finding out what kind of education produced the best officers. They could find no useful correlation. Good grades didn't help. Post-grad degrees didn't help. There was also no correlation between an officer's performance and his iq. What that means to you is this: the best you can hope for from your degree is to get yourself in the employer's door.
p aper21.pdf
One exception to the above dismal news is the final year project (often referred to as a 'capstone' project). It is designed to wrap up all the skills you have learned so far and develop the skills that are actually useful in the workplace. The problem is that your profs may have no more clue than you do about how to teach those skills or even know what they are. Just tossing groups of students together and hoping that things work out only works accidentlly. Here's a link that will give you a flavor of what's necessary: http://www.cdio.org/meetings/june05/05confpapers/
The employers who regularly hire our grads always ask about the final year project. How the student did with the final year project is a better indication of how they will work out on the job than anything else they did in school.
As a soon to be graduating senior for BSCS at the Georgia Institute of Technology, we are required to take at least two software development classes, CS2335 and CS2340. As you can see from the numbering, they are both sophomore level classes. The reasoning for this, which I highly agree with, is to start learning the process of software development early and correctly before bad habits begin.
For CS2335, we had 7 projects, six smaller projects, with the first three being individual, and the next three being group projects (2-4 man). Each of these previous projects received 1-2 weeks to finish depending on difficulty. These projects demonstrated various aspects of software development, which mirrored the curriculum of UML, extreme programming, debuging, errors, and so on. Finally, we had a six-week final project that brought together the many aspects of all previous projects. Below is a like to my final project. As you can see the entire project is outlined with all project requirements, much like a requirements doc in business (I co-oped for 2 years, so I do know spec and req documents, and have done a few myself). The best part of this project is we would lose points if there were any bugs in the project code from junit, checkstyle, and pmd, forcing us to actually test and debug our code properly.
I know that everyone who has taken that class, and the follow-up CS2340, has gained a better appreciation for the software development process, and has a better understanding before learning it the hard way in the real world.
CS2335 Final Project
We already do this in High School -_-
Throughout my time at University as a Computer Science Major, the larger cycle of software development was constantly reinforced and brought to bear. Since it was mentioned in all classes and we often have joint development projects, I don't think that another class is needed. Under different professors, perhaps....but not in my case.
As part of my CS degree, I did an "IT project" unit which was much like this. We had to do a real project for a real customer working as part of a group with some other people (there were several teams, each with a different project). We had to submit project plans, requirements documents (gathered based on customer feedback), design documents, code, HTML (this was a PHP web project in our case) etc.
:)
It was a pretty good unit and gave me some good experience (and it underscored my hatred for writing documentation of any kind
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.
... in continuing education there is such a course.
The program is setup such that each programming language has 4 levels (courses) for it. The first three are the standard "this is the language, do some assignments" type course. The 4th level is for the student to complete a project in that language.
Both the continuing education program and its counter part in the regular program have end projects. In the day program, this project is only taken if one can't find placement in the work option.
I opted for NOT doing the work option as I heard that some students were doing tech support and didn't program at all. When I asked about it, I also asked if I could define my own project, which ended up being accepted. Otherwise, this course was basically used for "slave labour" getting programs needed by the school itself done for free.
one of the required courses for CS majors at my school was a sophomore level Software Engineering course. the class was divided into three teams of roughly a dozen people each. each team worked with a client who met with us to provide requirements. by actually working as part of a development team, students were able to learn the process while also taking part in it. the interaction with a real client gave the whole class a "real" feel-- we were essentially participating in the kind of work many of us hoped to do after graduation.
for a more real-world experience, the programmer probably should not do his/her own QA. That is, unless the focus of the lesson is to emulate a one-person startup.
However, the designer/programmer could work more closely, and probably be one person. A student could QA another student's work, as part of the QA portion of the class.
For classroom coordination purposes, that would require strict adherence to design & development schedules...
This sounds not too different from what you might have a (small) group do to perform a project to complete their requirements for a Software Engineering curriculum (albeit over more than 1 semester).
If you've got 2 semesters or more to burn, after having all the fundamentals of languages and a course on basic software development, you could have a 2 semester SE project with multiple parties on the project. In order not to waste everyone's time, and create genuine risk for any of the student participants, each of the participants should have a solid CS background. Note that all students don't have to have all areas of expertise - but the combination of skill sets should cover the requirements for the project. Also, a two-stage system could be developed, where one team does (rigid, even formal) requirements and specifications, and the next group could schedule, control, and develop. This way a project could span 3-4 semesters with 2 teams. Further teams could do subsequent enhancements in much the same manner, and spirals, or incremental developments, and other models could be worked with.
A project doesn't have to be entirely in-house. An open-source project could be built upon. Sites like sourceforge might provide an excellent basis for ideas.
It's been 15 years since I graduated, but after a quick review of the catalog at my alma mater, it all seems to still hold true.
:)
The course(s) that you're suggesting is a great idea, and, in fact, it's offered in many universities as part of a different degree... Information Systems. With a degree in Information Systems, you learn project management, systems design lifecycle, RDBMS concepts, as well as programming. Plus a raft of other useful "real world" stuff like statistical modeling, networking, and a smattering of courses from the other business school depatments, like Finance and Accounting; so you can learn the language of the people you'll be coding for.
CS is for pure programmers. Information Systems is for applying computer-based solutions in the real world. It was frustrating how many of my colleagues seeking the same degree didn't know any computer languages when they entered... I was always a computer and math geek, and knew several languages before entering college. I was far better then my non-programming colleages in the programming courses, but they were typcially better communicators, which is more important when you get out of school.
Anyway, in my senior year, we actually did developed a real-world solution for a local hospital, sort of like you suggest. If I recall correctly, it was a real-time inventory tracking system. Using bar codes. Pretty good solution for a team of 4 working part time for 4 months. But we did it all, start to finish: interviewed the client, shared a prototype, developed and implemented the system. Looking back, I'm sure they abandoned it almost immediately; that it was more of an exercise for the students than a boon for the hospital, but it was still great experience for us.
At this point, consider coupling your CS degree with a Masters degree in Information Systems. (It would be an MBA.) Not immediately -- give it a few years in the real world. A BS in Computer Science with an MBA in Information Systems is a very powerful combination. You'll be someone who can do it all -- meet with top management and board members and understand their concerns, and also earn the respect of the programmers because he (or she) can speak their language.
Cheers! Good luck to you.
So what you're left with is not much of an idea of what is going on outside academia other than perhaps "really large programs." That is why everybody that I interviewed with coming out of school in the 90s asked if I had taken a projects class.
If I were to design a curriculum to get people ready for how things are after school, I'd make a two semester course requirement:
The first semester I would have the students go through a survey-type class where different types of methodologies were explained, along with the advantages and disadvantages of each, with an example of representative types of applications that used each method. Perhaps a telephone switch used with a Waterfall methodology. And go on from there. This would go up to whatever the latest fad was. This would also include the prerequisites for starting a project, which hopefully are common to all projects -- you would use something like the material from The Software Project Survival Guide. You'd also look at different maturity measurement methods, such as SEI CMMI levels. And then a dose of the real-world with mistakes that people make during software projects, such as excessive "tailoring" of the process, giving up the process during mid-iteration to code like mad, etc., and ways to get out of such software development mistakes.
You would also get taught concepts such as Configuration Management (with a survey of different tools, such as CVS, Subversion, ClearCase), unit- versus integration- versus system-testing and tools to perform each.
The second semester would be the actual project where you would use the appropriate methodology for the size, number of people, and time to work on the project. You would try to make it as realistic as possible, including requirements gathering with inadequate requirements, bad business contracts, interacting with QA for getting a test plan up and running, etc. Then halfway through the project you could have additional requirements added by the customer and see how to successfully manage such changes.
Another course or portion of a projects course would be doing what most of us end up doing anyway: modifying other people's code. This would also go over the different types of code modification: new features addition, optimizing code for better speed, user interface changes, etc. It would also survey different tools, such as debuggers and profilers. It would also look at the hows and whys of refactoring.
All of these are necessary to successful real-world software development, IMHO. Unless you go to an underfunded start-up ("OMG, why aren't you coding!!!), or you work at Google.
Without this, I think a lot of people are going into software development thinking it's all fun, with this rosy picture of working on original code, and thinking that testing what you do after it all works.
DT
Is this thing on? Hello?
We had a few courses that taught us the basics of designing a program from scratch, outline the problem, asking users from the basics, what is the objective in regards to the information flow that you want to have. UI Design. IP laws you may come across, marketing/advertising of your application, in other words the whole package. It was a project that had all kinds of students in it, all from different angels, some studied law other marketing, management, computer science and Business & Computer Science. Every team consisted of minimum 1 student of every department maximum of 2 per department, with a maximum of 8 persons per team. The project also covered different courses. I studied Business & Computer Science so for me it covered things like: choices for the database being used (course databases) , the support contract that had to be offered (course: service level management) , design decisions (course: Programming in C). The project lasted for an entire year and went along side other courses, the courses that had something to do with it would reserve time for the project (say:20% for the project and 80% for the general theory and practice). A great deal of the project was done after school hours because you had to cooperate with all the different students some of them where on different locations. And what i learned from the project is that the cooperation with your team members is a huge factor. If that fails you either try to solve it or get out. The first weeks when i started i had a confrontation with one of my team members which i disliked from the start. He actively made friends with the other team members and made sure he was the first one in all the time and the last one to leave. Which can be a good thing ofcourse, but only when the atmosphere is pleasant, not if is only being done to out preform someone use it against them every chance you get. All this is ofcourse seen from my perspective and i'm sure his side can have a different explanation but i doubt it. After 3 weeks the time bomb exploded and it ended, and indeed all the extra cm's (not miles) he put in the project where used against me, along with some made up things and things out of context, but at that point i realized that even if he was not telling the truth and i could defend myself it wasn't helping. The work enviroment was tense and shut to pieces, cooperation would have been impossible. So i said screw you then and went to the 'competition' another team knew what was going on and they asked me if i wanted to join them... So in every aspect it was a real life example. And it was worth every minute spent on it...
If you don't like my sig then don't read it.
While not a bad idea, I think the suggestion of a project that starts with design and ends with deployment omits the most important part of a real-world project. Maintenance. Fixing bugs, adding features.
It would be better to do the group project during the students' junior year, and then during the senior year introduce a series of new feature requests and require them to fix bugs.
Of, if there's not enough time for that, leave out the project and just start with the maintenance phase. It's a more realistic example of what new programmers will be doing in their first jobs, anyway. If you're concerned about not providing students with experience doing design, coding and deployment, give them a bunch of new features to add, require them to design -- with the design fitting into the existing project framework, of course, -- implement and deploy the updates. Be sure to include backward compatibility requirements, and have them engineer a deployment into a simulated live production environment without unduly interrupting production work.
One of the most important skills a professional developer can have is also one that software engineering curricula don't teach hardly at all: reading code. Requiring students to read and understand an existing codebase, with minimal documentation outside of the code, so that they can fix bugs and implement new features would do more to prepare them for the real world of software development than anything I can think of. If the codebase were well-chosen, it could also given them significant exposures to both good code and bad code; elegant use of appropriate patterns, massive piles of cut-n-paste barely-working cruft, etc. Much like most real-world software that has been touched by a long series of hands of varying capability over the course of years.
Anyway, if I were designing the curriculum, that would be my approach.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I am finishing my final semester at a University where there is semester long project in at least two courses per semester since the start of 3rd year. I have learned more about time management, writing, and software lifecycle because of those courses than I would had I just had isolated assignments. I've got a pretty sweet job waiting for me upon graduation and I like to think that is partly because of the experience my project work gave me. Knowing the syntax of a bunch of languages does not make you a software developer. You have to know how to work with and succeed as a team.
Oh, a lesson in history from Mr. I'm my own grandpa.
A good CS program should incorporate many of the concepts of software design into their program WITHOUT having to focus specifically on professional design in any one class. CS isn't about becoming a pro software developer, that just happens to be a possible result of graduating with the degree.
IMO you'll learn more about the software lifecycle by actively and progressively participating in it as a requirement of each course than by taking a single course where that's all they harp on, especially because each professor, like each employer, will have different specific requirements. Learning to be comfortable with the discipline will ultimately serve you better than memorizing a bunch of facts and figures.
The only way I see this being successful is if you had the entire class participate, and gave all of them roles with competing interests. You need to have Business Analysts, Software Engineers, Offshore Consultants (heh), Tech Leads, Architects, Project Managers, Product Managers, Owners and Customers. Preferably each role should be assigned a budget and one's grade should reflect on how well that budget is spent on an individual basis, how much the entire group spent, and the overall success of the project.
If the roles and budgets are setup correctly, the initial project will probably end up taking twice as long or more as much as the alloted for project work for the class. For example, if the class is a 3 credit class, then the initial project should be comparable to a project for a hypothetical 6 credit death march. This is because the owner sees the $$$, the product manager says yes to nearly every feature requested, and the goal of the customers is to get as many features while paying as little as possible.
Then pick a software methodology; it doesn't matter one bit if it's Waterfall, XP, Scrum, (E)UP, whatever, because it's my bet is that 19 times out of 20, the project will end in miserable failure. What will be exposed will be the politics of everybody, and how these competing politics completely destroyed the project. Have the final be a post-mortem analysis.
i beg you PLEASE teach these kids something about a real dev cycle. it wasn't included in my training and i still beg you, for the love of god, it's driving me crazy!
I generally agree, but your numbers are multiplied by two - do you have quarters instead of semesters? Once divided, it would nearly match pretty much what I took at RPI to obtain my CS degree:
Computer Science 1 and 2 (C++)
Data Structures & Algorithms
Computer Organization - some assembly, caching, memory management, performance
Models of Computation - grammars, syntax, lex/flex & yacc/bison
Programming Languages - lambda calculus, functional programming, etc
Operating Systems - processes, threads, paging, windows vs linux
Software Design & Documentation - the class this whole post is about
Network Programming (CS elective)
Database Systems (CS elective)
Except for the last two, all are required - in addition, you must take 2 or 3 (I forget) 400-level CS electives - the ones I mentioned are popular choices.
In addition there were these math requirements:
Calculus 1 and 2
Discrete Structures (Discrete Mathematics)
1 Math elective (typically Diff Eq or Linear Algebra)
The space unintentionally left unblank.
Hi, I just wanted to share the experience at Carnegie Mellon's Software Engineering master. This curse is specifically target toward your proposed scheme.
We currently have a Studio project, which in our case, is a real industry client that runs through 4 semesters. Whatever you learn during class is to be applied some way or the other to the Studio.
For example, this first semester you get courses (Managing Soft. Dev) that explore different software process (RUP, Agile varieties, and other); quality assurance techniques; risk management; planning using WBS, Gantt, Sprints; requirements management; estimation; change management; etc.
Then you go and apply what you think is useful (or not and just want to experiment) with the project. Professors get together every week with you or your team to see the progress and ask the difficult questions like: how do you know where the project is? What is the scope of the project? Have you done experiments to understand architectural concerns and others.
Other curses offered in the first are more related to req. (use cases, UI design, formal methods, etc). Second semester then goes on to explore architectural concerns and types, analysis of artifacts. In the summer, instead of an internship we get to code using whatever process framework we used, tailored or created ourselves, to drive testing and development.
Anyways, I think this can be tailored to a smaller project and course load, but it could be nice starting point to explore.
Just my 2 cents
-Roni Burd
At my school the BS students had to complete a final project. Typically they started it 2nd semester Junior year or summer prior to senior year. I was a BA student(I believe BA students now have to complete one as well), so I'm not sure of all details. Throughout senior year the BS students had to give presentations in suits and ties on their project with faculty and classmates asking questions. This wasn't a thesis, they had to go through each step of the process gantt charts and all. I know I wasn't well prepared with a BA, but most of the BAs werent looking for software development jobs anyway, and if I had taken the co-op/internship opportunities I would have been. I know the BS students found the final project to be a worthwhile experience even though they bitched and moaned their way through it.
Many technical schools have something similar to your idea. It's called a Cap Stone project which encompasses all you have learned combined and it is done when you are a senior.
When I was a CS student I watched the faculty have this conversation a number of times (I also worked for the department). Part of the discussion was around what a computer science education should contain. I guess you could sum it up as theory vs. vocational. There were the old school, mathematics based theorists and the new(er) school that wanted more software engineering. Of course this then led to the question of what would get cut to fit a new course(s) in. My program had a capstone class that was software development. The problem that we ran in to was that it was too short. The 15 weeks of the semester weren't enough to allow for a real development cycle. Along with that not all of the faculty had the kind of experience of managing simultaneous development groups that teaching a course like this requires. It's a hard problem to solve at the undergraduate level.
The CS curriculum had Software Engineering as a non-mandatory course that I feel (after graduating in 2003, and getting a job at a consulting company) should be part of the main curriculum. I didn't get a deer-in-headlights experience thanks to it.
I'm a Computer engineering senoir at WSU, and although it is not required I took a class on just that called Software Engineering which is mandatory for CS majors ( I switched to CE ). CE majors are required ( along with the EE majors) to take a class in senoir design where we have to go through the design cycle of a more physical product. I assumed this would be mandatory in all colleges by now even small ones.
if you need a curriculum advice you might try looking at what other colleges already offer in respect to this.
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.
We had this at my school and it was one of two useful classes I had in the CS program. You need to split it into two semesters, though. The first is for learning how the true SDLC would work. And the second is when you actually go through a severely stripped-down version of it for a small project. You need this because 15 weeks is not enough to go through a full SDLC for anything significant enough to work on in a team environment. You have to trim the process down significantly, and you still only end up with about 7 weeks for actual programming and development. But going through a smaller SDLC and learning about the full SDLC is sufficient to get across the idea that implementation is a small part of software development.
I went to a state school for a few years, then switched to DeVry's Computer Information Systems program for variety of reasons. Here is what I can tell you. I don't remember any final project at the state school's CS program (big school, nice school). I got great CS classes while I was there though (theory and such). At DeVry I didn't get the impression that they taught nearly as much theory and some of the stuff I learned (of course, I transfered in half-way through).
HOWEVER, DeVry was very business focused. Everything was about business. How to write business apps in VB (a basic into to VB course that most businesses degrees had to have). Building dynamic web sites (built a little storefront and shopping cart), the database classes (here is how to optimize, business cases you'll come across, when to put business logic into or rules into the DB, etc).
The final project was something that REALLY helped me. While we had had classes about the software life cycle (including a proposal project during that where we "designed" and pitched a system to a fake client). But the final project was the real deal.
Take a real client (they had companies that wanted things, I did mine for DeVry but that was not normal). The client has something they want done (or you can come up with an idea and pitch it to a company). You have to get accepted by the faculty teaching the course. In the 15 weeks you had to design and implement the application (or upgrades to existing application). The design had to be approved by the faculty (especially the DB). Various changed would need approval. There was a long list of requirements for projects. It HAD to be done in teams (2-5, almost ALWAYS 3-4). You had to gather the requirements yourself. You had to check in with the client numerous times on how your progress was going, to give them a demo of the system, etc. At the end of it all you gave a presentation to the professor, the class, and the client about what you did, how you designed it, how it turned out, problems you faced, etc.
We were basically consultants for credit.
All the degrees had something like this (the EE ones were often a ton of fun to watch, because they didn't have clients and came up with some neat gadgets some times, or one friend updated an old control system for a local astronomy telescope and added scheduling and such).
This REALLY helped me. Not only did it give me tons of experience (including even more with facing deadlines, partners not holding up their end, having to make design changes in the middle, etc) but it gave me GREAT stuff to talk about at job interviews. Half the questions they would ask ("When was a time", "Have you ever made a decision that you found out too late...") were perfectly suited to my project work. My particular project probably helped me get my job (because some of the elements are similar).
Plus there was just the accomplishment. I made a Java based app to help students figure out their possible schedules for each semester instead of doing it on paper. I know for a fact that now (it's been 2 semesters since I graduated I think) they ARE using it. I know that they were going to show it to corporate (I wrote it for my local DeVry, though there was nothing specific), but I don't know what will happen from them. They have only contacted me once about a problem which I fixed for them (I worked as a student aid there too so they knew me well). My little app was a Java applet that hit an SQL server for data. My job that I got is all Java with TONS of SQL, so my project ended up very relevant (and being able to pull it up for the interviewer straight off the real site and show it to them was a major plus too).
Now all that said, as I was leaving DeVry was shifting to MUCH more specific programs for CS and becoming even less general which I think was a terrible idea. I'll also say quite frankly that my time at the state school taught me thinks that I don't think I would have ever learned otherwise.
But some kind of big, real-world
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
CS ciriculum are like law degrees in that they teach the basic first principles of programming, and why and how we do things, at least in the courses I teach. As in a Law degree program, or an architectual program, much of the day to day courtroom and building code information is left up to an apprenticship in the industry. One reason for that is that the building codes and court room proceedures vary from State to State (city to city for the building codes).
...
The practices of project managment and software design vary from company to company and language environment to language envirionment. This is a big problem.
For an acedemic program to be relevant and successful it needs to have some software engineering in its curriculum for completeness, but not at the expense of other more important topics, such as data structures, networking, and touches on the various flavors of computing, business, engineering, operating systems, web, GUI
If you put a strong component of Software development in an undergraduate cirriculum it is at the sacrifice of more core first principle courses. How can you do software development if you don't know how to develop software. So any large dose of software development should be done as a product workshop, a professional training seminar, or possibly part of a software engineering Master degree track.
Certainly one size does not fit all. Look at all the different models of Software development. How do you choose? The methodology so strongly effects what you turn out, if you stick to a methodoloyg you may be generating very inappropriate code. This I have seen with Software Development methodologies being used by those that only new one methodology and sometimes were managaging projects when they could not program. Then the bureaucracies start to take over and common sense and appropriatness go out the window. Lets not talk about ISO9000.
Should the methodology wars be fought in the Universities or out in the Marketplace?
My school has a class for exactly this purpose, and I think most other self-respecting CS departments teach software engineering all the time. However, the execution is likely different between different schools and different professors.
The prof that teaches the software engineering class where I am has students split into various groups chosen by the professor at the beginning of the semester to complete a project. Every group works on the same project. The first half of the semester is devoted to formally developing a plan for the software. At midterms, every group presents their plan for the project, and each group bids points for the plan other than their own that they want to implement. The second half of the semester has the groups implementing the plan they received from the bidding.
I like the way my school does this class because not only does it force you to work with people you may not choose right off, but it forces you to make clear and concise plans for a program so that the group that gets your plan doesn't have to bug you every other day for how they're supposed to write a module, and it also requires you to learn how to write a program designed by somebody else. I'm not in the real world yet, but I'd guess that these are skills that could turn out to be very important.
if you have any input into this class make sure that it addresses the fact that development time lines are getting shorter and shorter and demand for features greater and greater. We have been told that when we are asked to give a 'swag' at a time line to keep in mind that if the business thinks we are going to take too long, one of two things will happen...either the project will not be approved or they will attempt to go and buy a product that they can install and customize. Now my experience has taught me that buying software still requires discipline and usually does take every bit as long as writing it from scratch but this is the thinking we find ourselves in these days.
The government's view of the economy could be summed up in a few short phrases: If it moves, tax it. If it keeps moving,
This should be a serious requirement (and I say this as a new graduate student in a top ten Computer Science school). The systems group that I am currently working in consists of guys who have excellent programming ability, but considering the scope of a project (its a joint research effort with another top-notch university), we're currently running into big bug issues because of two main problems with our project(IMHO)
a) Lack of a testing framework (this is not taught effectively in university level)
b) Lack of proper source control (again, only one very vague course in our university emphasizes this)...and its surprising to think how very few people at university level have a strong idea of source control
I feel that had proper attention and detail been given to these things, maybe we wouldnt run into these big bug issues...
Sorry if my English isn't very perfect!
This was our life cycle course: get an internship or do a "directed project." Well, being in mid-Illinois, there weren't a whole lot of internships available, and those that were available got snapped up by those who have the GPA but not the skill, because OBVIOUSLY those who do better in general education are more prepared to write code than those who ace the CS courses (no, no chip on my shoulder, move along).
So we had a "directed project" where we were told to find a real-world project. Pitch it, plan it, do it, demo it. Basically it was a huge joke, as most anyone can imagine how something so open could be abused.
After graduation, I know a good number of my interviews went nowhere because I couldn't say I knew the development cycle with a straight face. Small shops were the only ones willing to pull me on board.
Bottom line: Yes, the cycle is important. It is very important. It's not hard to pick up, so there really does need to be life cycle in a curriculum. So take a course in it at a community college if you need to, or be prepared to search for some time for those small shops willing to break you in, but who aren't going to relocate you.
Perception is the thin dividing line between reality and fiction.
...modify the previous year's final project with changed- and new-features, schema changes, enhanced performance/scaleability...
...and in the process discover what was good and bad about how they engineered/hacked it. Avoid these mistakes in your own code and prepare to go through this process repeatedly for the next forty years or so.
Oh, and every few years, throw in a platform/language change for good measure.
I'm procrastinating on a programming assignment for college right now. Considering that, I'd say a course like this would be very beneficial!
"This is a model of a model of iron, modelled in iron."
...when I was in college over 20 years ago. Development Life Cycle was big then, and it was good experience learning to program in a group setting, going from spec, to design, to coding, to the gradebook. There were some really cool programs that came from those classes, like Moria (CRT-based dungeon game).
Why aren't they teaching that stuff today?
Just call it Frustration 101. You get this nice course on the ideal development cycle and then go out into the business world and get to deal with rushed schedules, managers who don't understand programming who just want you to develop something rather than sit down and produce a good design. Or maybe you land in a situation where you're maintaining legacy code and instead of being able to fix design problems, you're just asked to make the new feature work or make the bug go away. So you continue making ad hoc changes and four years later someone wonders what the hell was wrong with you, but then after four months they understand that you're actually intelligent and that it's management's idiocy that causes the bad code. You might as well have a class about perfect relationships where you emulate a relationship without any trials or tribulations.
I did a CS degree and took a couple of software engineering subjects as part of the course which tought us about software lifecycles and we did a group project that went through the first few stages basically up to when programming begins. It taught me a lot about doing projects including project management. I chose to do that subject not because I had to but because I thought it would be useful in the real world. Now if I was doing a SE degree (which was also offered at my uni) my group would have then gone on into the next semester and actually implemented that project. The SE students also did an extra year after that where they did another 1 year project which went through the whole lifecycle (barring support).
My point is that those sorts of things are part of SE not CS. CS is a science and that is what the focus should be on. It teaches you algorithms, theoretical stuff, different programming approaches (functional, OO, procedural), and how low level stuff like how OSs and computers work. You just want to learn how to be a coding grunt then go do a 1 or 2 year course at a technical college. You want to go further and get into doing large projects and move up to software design and management then do SE. On the other hand if you want to study computers and do research into how computers work and into new programming languages and technologies etc, then do CS. Do the course which fits your needs!
The software development cycle happens to be one of the major syllabus points in the Software Design and Development course, an optional subject taught for the High School Certificate (similar to your SAT's) in NSW, Australia. Our major project was actually to develop a software solution while adhering to the steps of this cycle. http://www.boardofstudies.nsw.edu.au/syllabus_hsc/ pdf_doc/softwaredesign_syl.pdf
It would depend on the school whether the SDLC fell under the broad scope of 'Computer Science'. Was it an 'applied' or 'theoretical' curriculum? In my experience at Oregon institute of tech (which is more applied in its approach), I had classes that touched upon the cycle at varying degrees; in both the software program and the IT degree programs (I started in IT, then moved to software). If you are going to be actually developing software or in charge of people doing so, I'd say you should probably know at least SOMTHING about it.
I find this discussion to be a good summary of what's wrong with most of the CS program graduates who later go on to refer to themselves as "software engineers". Most of them have no clue how to take requirements and develop a final product using proper engineering principles. Yet, virtually every university incorporates some sort of senior design project as part of their engineering curriculum. It might even be required for ABET certification but I don't know.
If you want to develop a software solution, you need to determine the best tools, best language, and best hardware to satisfy the requirements which you determine the customer needs. All of this is quite a bit more in depth than CS programs usually incorporate.
I spent nearly 10 years as a software developer before returning to school to complete an engineering degree. I realized very quickly that there were a huge number of concepts and tools that I could've incorporated in software design that I had no clue existed.
Planetes
"One World, One Web, One Program" - Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitl
Software Engineering was a good course; it was my SE professor's speciality too. It taught me to never underestimate the value of the requirements gathering process and many approaches to designing and specifying software that were very valuable in my career as a software developer.
:-]
A pretty common criticism of CS schools is that they don't do enough to prepare you for the 'real world'.
A lot of CS academics argue that CS courses are there to teach people to become computer scientists, and not necessarily software engineers- but of course most people who do CS do not end up as computer scientists.
Even so - most undergrad CS schools have a Software Engineering course (or even a separate degree). If your school does not have this then i would say it is a bit unusual. This is where you learn about methodologies (RUP, XP etc) and usually involve a group project or work experience.
I think it is very difficult to teach real-world skills in an isolated setting. For a start, many - if not most of your professors would never have worked as professional software developers (and if they did - it was a long time ago).
I see the CS degree as a bit like a medical or legal degree, it's pretty essential theory, but there is still going to be a number of years after in that you will be learning how to apply the theory in a real world setting.
You can jump start this by getting a summer job, or to some extent working on an open source project (of course this will have slightly different challenges).
As a graduate with a BS in Computer Science from a university, I can definatey say that most classes focus on theory and the underlying and inner workings of programming languages and computers as a whole. However, many times and in many of my classes, we were required to work on projects in groups and even had classes concerning the life-cycle of a program from conception through implementation to supporting your programs. The CS department also required a final project course before graduation. In that course, I had to design, build, document, and present a major application to a group of my peers and the CS faculty. I would definately recommend such a course, as it not only sums up what you have learned, but is also a great tool to understand what really goes on for a group of programmers when they develop an application.
I'm a CS major at the University of Kansas. Here, in my Junior year, a required class was Software Engineering. In this class we were introduced to the development chain and exposed to two styles of programming methods (Unified Process and eXtreme Programming). We completed two projects in the semester (one per studied programming process) as well as learning about various tools available to software engineers. The best part was that the projects were small video games (a side-scrolling shooter and a 2D platformer) and so the class engaged the students like nothing I've ever seen otherwise.
While it's not as accurate as real world experience (our "client" was our TA), it did give a good idea for what was in store.
Support Liberty, Support Ron Paul
I'm a professional software developer with more than 25 years of experience. My experience with modern software development process is to be able to blame someone else or some other group for the problems.
Playing chicken is one good development process. Your group produces crappy code, but this is not a problem since you count on another group slipping the schedule before you have to. Therefore you claim success and blame the other group for the fact that the product schedule is slipped. This gives you time to complete you code without having to declare that you missed the schedule.
Also, if you are a manager "kiss up, kick down" is the best way to manage a project. Only pass good news up and make sure you able to blame developers for not meeting the schedule that you comitted to.
My experience:
The programming languages aren't something that should be taught. If you need that, switch to MIS. If you're CS you should be able to learn that on your own. Curriculum needs to focus on development process, design, algorithms and their analysis, operating system design (re: threading now more than ever before), networking. The curriculum needs only to set you in the directions, if you can't take initiative to learn the languages to fill in the gaps then you really shouldn't be in the field.
From the job:
I've experienced since I started working after graduating in May that (1) at least my company is ran by people that only have a slight clue (2) The other developers have even less of a clue on design (architecture of the code) (3) That I come from a *nix background, and companies all want M$ crap, so I had to take a job doing ASP classic and VB vs. the AJAX, Rails, C++, and Java that I had been doing up until 7 months ago. In fact I hadn't used VB since my sophomore or junior year in high school. At which time I could've done the job I do now.
Conclusion: Anyone can learn and use a language, the curriculum needs to stimulate the design, development, and principles behind good software.
It should be taught.
... a completed, or mostly completed project should be handed to the students. They then get to QA the project. The professor should grade them on how many bugs they FIND, not fix. There should be a couple of iterations of this project at different bug levels. Students should have to check the code out of source control, compile, test, and write a report about the bugs they found.
... A student should be assigned to fix a bug found by a different student. The team approach could then be used to merge their fixes perhaps... if you wanted teams.
How to teach it? Don't know that there is one good way. I would make it a non-coding class. Why? Because the code and the problem set would just get in the way of learning what you are trying to teach. What you are trying to teach is information organization.
1) Requirements. This is really an interview process followed by a technical writing process.
2) Project Plan. Critical thinking followed by a technical writing process. (Not code writing, paper writing)
3) Project
4) Bug Fixing
5) Product release. Following a set of instructions, build the package for delivery to the customer (professor)
42 - So long and thanks for all the fish.
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.
My guess is that splitting the degrees would just lengthen the degree for software engineers as they add on the extra courses to a full CS curriculum. I would hate to see core CS classes pulled from a 4 year software engineering degree in the name of expediency.
It could be included as an elective, but that's really more of a software engineering topic. Computer Science is a theoretical curriculum, not a technical or process-based one.
(%i1) factor(777353);
(%o1) 777353
What you're describing definitely needs to be taught for people in the area of software development/engineering. Computer Science, however, is an entirely different subject. Sadly, the vast majority of people studying Computer Science should not be. Computer Science is an academic discipline akin to physics or biology, and deals with theories and concepts more than development cycles and QA processes. That is the work real scientists leave to the engineer lackeys (no offence intended... [okay, maybe a little]).
:)
I should add that I am definitely -not- a computer scientists, I am in the latter category of mere "developer" that works in the field. I am, however, an aspiring physicist and I think it still applies.
It sounds like your school's computer science needs some work if it's teaching you VB as a serious (eek!) language, but it is correct in not requiring a course specifically on software development practices. Perhaps the real problem here was stated in your first sentence: "small private college".
I'd say yes. A lot of the classes focus on actual programming (and the theory thereof), but in none of those classes do you learn how to interact with a customer, be them someone contracting your skills or your own boss.
If you're lucky, you get out of college and are put as a junior member of a design team, and learn interaction by observing what works and doesn't work with the others. However, you can sometimes learn the wrong thing, or not get insight into something by just analyzing what others do. As well, if you try to go your own way after college, you won't know how to interact with the customer. Anyone who's worked long in IT knows that what a customer asks for insn't necessarily what they want.
Well, others may have a different idea, but I can at least tell you what I did in mine.
First, programming was the last thing that was on our minds. CS majors have loads of other courses involving programming. The course focused almost entirely on setting up requirements and delivering reports on specs to the customer.
Initially, we learned about the various development models (waterfall, fountain, etc.) in use. We then had a "meeting" with our professor, with him acting as a potential customer. Over an hour we hashed out various aspects of the program he wanted at one point in the term. An important change I would make is to have more of these meetings, each building on the last, because just that one hour was not enough for what was expected of us.
With what we had from that hour, we created and turned in an enumerated list specifying the detais of the program, and actions taken in response to other actions. (Our program was basically an eBay clone.) This involved a lot of extrapolation on what to do in certain situations, which normally would be brought back to the customer for approval.
After that, we set out to create a Class Diagram, with your usual assortment of methods, variables, and how they all interacted.
We then split up the workload and actually made the program after one or two other smaller assignments (including Scenario Cases, where we did a short step-by-step process of what happened for certain situations), which was actually only for 2 of the 11 weeks we had for the class.
The class was important for three reasons:
1) Learning how to expand a basic list of requirements given by the user, and creating a set of deadlines from it, as well as the main deadline (which we did miss, heh).
2) Being able to understand what the user truly wants, which can't always be explained by the user.
3) Dealing with a team of varying strengths. This is very important once you get out in life, because HR and managers will hire people who can somehow present themselves in a good light but have absolutely no place coding. In our case, we had a student from another university taking the class. It was an hour drive for him, and he had never done an OOP in his life (we were to write the program in Java). That was quite a pain, and he was given some of the easier tasks because of it.
I'd say that this kind of class has a true purpose in both a Computer Science and a Software Engineering degree. I disliked it (for various reasons), but the knowledge I gained from it is quite useful.
I've spoken with a few "CS Graduates" from the college. I must say that the first one was amazing as they really didn't have any personal computer use time. Talking with them about anything in detail revealed how flawed their personal absorbtion of the information had been. I believe that without hands on experience.... the majority of the retained information just doesn't have anything to relate to. You must experience computer use to put it all in context. http://tracker.honestwealthgroup.com/ Get a loved one the gift of financial wisdom this year ;)
Discover a Financial Lifeline Tracker.HonestWealthGroup.com
Full disclosure: I teach IT at a major research university and I hear this crap constantly--which is also why I am posting anonymously, even though it runs counter to everything I believe in (I didn't get as far as I have by being stupid).
I was quite surprised to learn that not all institutions seem to include this. City Uni usually rates fairly near the top in the UK for CS, but even so, it's not rocket science. Our course on testing was taught by the university's Centre for Software Reliability. Those guys have been involved in testing such mission-critical control software as Airbus, Concorde and the European Space Programme (IIRC) so they know what they're talking about (people die if their software screws up).
The Technion IIT (Closest thing to MIT we have in Israel) has a course which is essentially what was described: http://webcourse.cs.technion.ac.il/234321 (Much of the informaton will be in Hebrew) The course grade is 50% a project and 50% a final test. The project includes simulated 'client meetings' (with the TAs), building a requirements document (and meeting with the 'client' again to review these requirements), modeling the application in (eww) UML, and implementing it with tests - all of these are given approximately equal weight in grading. Project is submitted in parts, so if there's something wrong with the spec you've devised - you will be corrected so you don't get screwed later on. Project is done in groups of four. Note: I absolutely despised this course.
If it weren't for fog, the world would run at a really crappy framerate.
It might interest you that a course, using a very similar approach to what you are attempting, is offered at Université de Sherbrooke, in Québec. Its a degree in computer engineering that focuses on problem solving and project building (I just completed my degree).
Throughout the 4 years and a half we have a total of 7 major projects, that involve electrical and computer engineering, from robots to a range of software applications to develop. Furthermore, we have also 4 work-terms , each of 4 months, which is a great way of seeing real life experiences of what involves programming and developing software.
I teach software engineering courses at iAcademy (Information and Communications Technology Academy, Makati City, Philippines). We have an SE-specialized CS degree program, which includes the following courses: Object-Oriented Analysis and Design Software Engineering Software Architecture Quality Management Project Management Those are mostly junior level courses, and they lead to a two term SE Project, where the students work together in groups on small-scale industry projects. After completing their project, our students then take a two term internship (about 6 months) during their senior year. The program is new, with one class graduating last May and a second one graduating next year. The initial feedback has been encouraging, both on the graduates and on the interns.
Excuse me, wtf r u doin?
...because there's no better instruction in writing quality code than having to sift through some other idiots' poorly commented, unstructured mess on a deadline.
Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
Yes, there is. It is getting critical, in my opinion. Too many colleges/university totally omit teaching at least the basics of the development cycle and integration, thus, you end up with students that are skilled enough to code an operating system kernel, yet have no clue how to deal with a development flow.
If you know how, but you can't, how do you know if you know how?
I didn't have a "software dev cycle" as part of my degree (graduated 2000), but no, I don't think it was necessary. "How to use a word processor" isn't a required part of an English degree -- classes force you to learn that skill, on your own if necessary.
The best course I took was, by far, Compilers. Over one semester, we had to write a compiler from scratch. Doing so requires pretty much everything you've learned in almost every other CS class up to that point. This means it's a decent sized project, and usually done with multiple people (my team had 3). So over the course of this project, you figure out what works and what doesn't.
Now, I'm sure some people could go through this course without learning that, just as some people go through any course without figuring anything out by themselves. But making it *mandatory* seems one step shy of requiring typing classes for a CS degree.
Also remember that anything that's formalized as a required course is going to suck more.
Finally, it sounds like you're lumping "CS" and "engineering" into the same boat. My friends who studied physics didn't learn how to use ProE, but my friends who studied aerospace engineering did. If you want "software dev cycle" to be a course, go dump it in the engineering school, not in CS. In fact, all of the engineers I know, in all fields, have ended up writing code at some stage, and not all the CS people have, so it's more appropriate there, anyway.
Many colleges, Rutgers included (where I work), offer courses on the Software Engineering. The problem is that very few (if any) schools make the course required. Making the course required could go a long way to helping future software developers. I, myself, never took the course and was floored when I went into the software world when I realized I knew nothing about professional software development beyond the coding/theory.
Feel free to browse the course material
It's called an APT here in the University of Malta. There's no evaluation by other students though.
APT stands for Applied Practical Task and it's done in the third year usually. Students have one or two APT's to do depending on their course.
I'm a current student at the University of Queensland studying Engineering with a major in software. This degree is 4 years in duration.
UQ also offers an Information Technology degree which is 3 years in duration.
Whats the major difference? Engineering students have to do math, engineering principles and diverse team project subjects.
Engineering students must complete 2 team project subjects (aptly named Team Project 1 and Team Project 2) which each last a semester as well as a Thesis which lasts 2 semesters. The first team project I did was to construct a PC based oscilloscope (hardware in a wood book with a coax input for voltage and an rs-232 connection to a PC) and the second was an reminder keyring (programmable using flashes of light on a PC screen. Also needed to provide the software to set alarms at certain times). Both projects were completed between 4 students comprising of 2 software engineers, an electrical engineer and a computer systems engineer.
I have chosen to and am currently completing my thesis through the CEED project. CEED list projects on behalf of companies to be completed by students. Once a project is completed and documented appropriately the student can then submit the work as their thesis project. The company pays CEED for this service and retains all IP rights to the work. CEED then passes on a % of this money to student for their work.
This model seems to work well enough. My only criticism is the allocation of students to groups in team project. It isn't a rare occurrence that you get teamed with other students that either struggle to talk English or don't have a solid understanding of their discipline, thus making the completion of the projects rather difficult. But, only 50% of the subjects marks are on the final product while the other 50% is on documentation and planning (see the related link). I think this is a good enough compensation for group selection.
Coincidently, students of both IT and Software Engineering are required to complete 3 subjects related to the design and development strategies of software. See the course guided here (PDF).
The software development cycle is in the Australian software design and development course developed by the NSW Board of Studies for High Schools.. and the Information Processing and Technology course includes system analysis, process mapping, project management, project implementation plans etc. So, in short, here in Australia, it's already being taught.
we did this in my ECE courses, at least as an elective for 'Software Engineering'. Basically the course covered from the ground up. We started with a basic idea that 6 teams would have to produce this game. From there the students were free to do pretty much whatever they wanted. Any language they chose and layout etc. Documentation for the game was produced, QA was done, development cycles etc. It seemed a pretty good layout to me, the professor kept it very loosely defined as to what he wanted in terms of results, which angered some students were used to the rigorous structure of producing specific results for a grade, but I think it worked out for the best.
and that's about it.
I think the curriculum for Computer Science is best left being purely academic in nature. Teaching the software development cycle to CS students makes assumptions as to how the knowledge will be used, which I think is a mistake.
Information you learn in college should make few, if any, assumptions about how you intend to apply the knowledge. A course in nuclear engineering should not assume the student is going to be building nuclear weapons, they could just as well be entering the field of energy. It's only important that they understand the general principles, they can gather the skills for the specific application of their knowledge elsewhere.
It's funny cause it's true
From my 20 years of experience developing software, I can tell you that 50% of the time is spent debugging code that doesn't do what you expect/want it to do. Still, most people go through university without even learning how to operate a debugger. In my opininon this is by far the biggest problem with CS education, coupled with the inexperience in working on big (>1 MLOC) projects. A suggestion would be to pick out some low-hanging bugs on a high profile open source project (there are always some simple bugs that are not serious enough to get fixed) and get the students to debug them, develop a patch (might be only a few lines of code) and get it submitted to the project. This way everyone wins, your students learn how a big project is operated and they do some good in the process.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
All CS majors at New Mexico State University take a class in Software Development. Here's a link to my prof's page on it. We had to work together on a fairly complex program (using GUIs and junk in Java). My team did end up using CVS to manage everything since our program used a parse/lexer along with some fairly hacked up GUI code.
"Some fight for law. Some fight for justice. What will you fight for? One day, you will see."
A good software engineering program includes at least basic project management, software development lifecycles, QA / testing, and a lot of other skills that most computer science programs don't cover or cover only superficially. They are distinct disciplines that shares a common foundation - in both you need to know how to program, but beyond that there's a huge difference in preparing someone to do research or teach and in preparing someone for professional software engineering.
I'd definitely recommend some basic business courses, some economics and maybe even some basic accounting. That way, graduates who have been paying attention will understand the bigger picture. That, and some practical courses in customer relationship manangement and support. Trust me, after they've dealt with 50 people in a row, all complaining about the same lost-data bug, they'll learn PDQ how to program defensively! :)
remember to loot and pillage before you burn!
In college, it is better to concentrate on theory. Analaysis of algorightms, automata etc. It's enough to give a brief introduction on Software Engineering as these nuances can only be appreciated in a real project environment.
No, there is not. There is no more need for the software dev cycle than there is for basket-weaving or football. Why not make Statics (from the physics curriculum) part of the English Major track? Or Cryptography for philosophy majors?
Computer science is science that just happens to involve computers (and not even real computers, necessarily!). It is not, and should not continue to be mistaken for, software development.
... since (at least) 2000, at my university's informatics department.
Apart from all hardcore computer science, engineering, and math-related courses, we have courses on:
- Project Management (different software dev cycles, bug hunting, code metrics, cvs, developing a full working system, team of 6 to be managed)
- Contextual Design (requirements gathering, contextual inquiry, participatory design, lo-fi UI prototyping)
- Organizational Studies (sociology, human resources, industry relations, conflict management)
- Organizational Structures and Management (globalization issues, strategic planning, knowledge management, organizational dynamics)
- Innovation and Technology Transfer (innovation cycles, patents, trademarks, intellectual property)
So, it's doable. And the IT industry likes it.
var sig = function() { sig(); }
It's called "Software Engineering".
It's usually a year longer.
The comment that CS may or may not be seen as a branch of mathematics (and thus more academic in nature) is a valid one. However, there's a limit to the number of jobs out there that pay for people with that deep a mathematical understanding, and I'm willing to bet many (most?) students in a typical CS degree have no interest in jobs where they will be doing fourier transforms all day.
Perhaps the UK is a little different, but here people tend to study what they want to learn, and what they are good at, and they can be hired into a lot of jobs. Consultancies, banks, IT firms, the civil service and many other professions looks for diversity and transferrable skills more than they look at specific modules on the curriculum.
But honestly, even if your aspiration is to be sat in a CS lab for the rest of your life, you *need* those skills. Every single interview I went to before I got a job focused very strongly on teamwork experience, evidence of leadership skills and evidence that the applicant could demonstrate an understanding of how their skills and knowledge translated into the real world. Even in the small number of cases where students want a career that doesn't involve interaction with marketing people or consumers or teamwork, they will be better off for having worked as part of realistic projects - and for the other (majority) of people, these skills will be a vital part of their education.
During my BSc and MSc studies, we did numerous projects, some better than others. The ones that worked best were the ones that ensured teams were balanced (having all the uber-geeks in one team produces ego clashes, bad code and pitiful deliverables; having no technical people in another team can be a significant barrier, though those teams tend to do better regardless), gave a significant degree of autonomy to the teams (the whole point is to learn to think independently), gave enough time and scope for people to do interesting things and become commited to the project, and were graded on fair and well-understood criteria that went beyond the technical (software must meet narrow spec) to the practical (software must meet "customer" need, team should demonstrate that they reacted well to changes in specifications introduced as part of the project process, end deliverables, i.e. reports and presentations, are tailored to the right audience and delivered with confidence).
Certainly, none of the organisations I wanted to work for would have accepted students with no demonstrable teamwork skills and no experience approaching the real world.
Author of `Professional Plone Development`, available from Packt Publishing.
I'm surprised no one has mentioned Agile in the replies. This looks like a textbook example of waterfall project failure. Why do you need the specs on the color of the background image to start coding? The week 2-12, "Go through iterations of determining specifics." should include coding and testing in the iterations.
If the higher-ups claim to need the complete spec to make a decision on whether to go through with the project at all, tell them
a) they need to know what it does to make that decision, not what color it is and
b) coding and testing is done ten weeks after you start doing it, not after you were supposed to start.
Thanks to Richard Stallman, all past development methods are now obsolete.
What you do is, you write a language suited to the job at hand -- a "language" being a hi-falutin' word for a bunch of macros written in LISP, something anybody can learn to do in maybe 45 minutes flat.
So your project is making powered streets work? OK, you create a language full of macros like "IsLightRed" or "AvoidDogShit" or whatever you need, and you use this language to write all the stuff to make your system work.
Then you use GCC to compile your thingie into whatever machine code you need for your target machine.
Voila.
Thank you, Richard.
At Utrecht University I did a course exactly like this, and it was called Software Project. Students form teams and work on projects submitted by Dutch companies. It works both ways: the students learn how software development works in real life (instead of in a 'safe' environment like university), and the companies get to test their ideas, see how they work out, and get at least a beginning of the implementation. They usually don't submit business-critical projects.
Our team worked on a project called Cheetah, and we worked with SVN for version control/concurrent access, a development wiki for sharing and working out ideas, a bug tracking system, and agile software development (pair programming, big visible charts, user stories). Some of us had more technical insight and had experience running servers, building websites, etc. while others had knowledge of diabetes (which the project was about), or access to medical information because their mother worked in a hospital, and so on. All in all a very enjoyable course where I learnt a lot.
One of the problems we ran into was that agile software development doesn't work very smoothly if the team meets only one or two days a week; most of us did other courses or had part-time jobs.
I'm not sure about other colleges, but I attend William Penn University in Oskaloosa, IA, and a course like this already exists. It is technically two courses called "Software Engineering Project" and "System Implementation." When I went through it, we went through two cycles of the SDLC and created a dynamic website for the Marion County United Soccer Club using Visual Studio .Net.
I would say that it was a very good experience. Not only did we learn how to interact with our client, but we also had to learn about working together as a team.
Odd, I never considered application administration to be middleware. In fact I think a better definition of middleware is the software that resides in the middle of two other pieces of software that need to communicate.
When I came out of school I knew what ports were due to 2 semesters of networking, unless you mean porting code bases to other systems, at which point I have to question what you spent your time on in college. Deployment was a little sketchier, but the concept was fairly easy to pick-up, it's not rocket science. And apparently I have a better idea of middleware then CS grads from your school even after however many years of experience you have had.
I wish a couple business classes had been required. As a student I wasn't aware of any use of those classes and so didn't take them. As an experienced developer, having worked as both a full-time consultant and an IT developer/architect, I now recognize that a couple business classes would have helped out a great deal. Knowing the context of a system is very important, and rather than pick up all the business knowledge I need to design business systems, I would prefer to have already received a solid foundation and some of the same training as my users.
The toughest things I had to learn (and am still learning) are that good enough is generally better than perfect, buying is often better than writing from scratch, and project management skills appear to have even less time spent on them for other degrees.
Sorry, I react badly to "I'm experienced and know so much more then my young colleagues". Everyone knows something you don't, and nearly everyone knows something we do not and could learn from.
Whee signature.
I'd also throw in at least one major specification change for each team (without changing the schedule) and at least one plausible programming document on a necessary interface that contains important errors or omissions. In fact, you might get someone with a nasty sense of humor who is not a student in this class to conjure up one major (but surmountable) suprise for every team.
The class could be a lot of fun, and you just might persuade some people who shouldn't be in CS to begin with to consider whether they have made an appropriate career choice.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
I have often suggested that what is necessary is to have a "Software Developer Finishing School" of some sort -- a system perhaps like an apprenticeship system where students would work on real teams developing real products for real customers.
Let's face it -- if the profs were the best and brightest, they'd be working out in the real world making a pile more money than at the colleges. Often, students are given a lot of great 'theoretical' knowledge, but with no real-world skills to back it up.
(This, plus a healthy dose of arrogance is what seems to have students graduating these programs and expecting to instantly start earning $75K+ with no experience whatsoever.)
Instead of companies offshoring software development to India or China -- why not set up small development teams within the colleges and universities and make completion of real projects a mandatory part of the program?
If a student participated in 4 or 5 different projects -- assuming different primary roles on each project -- there would be a lot of benefits:
1. The student would learn how to work as part of a team.
2. The student would learn how to work with customers (clients) and their 'interesting' requirements and methods of communication.
3. The student would learn how to put together a complete software product -- from start to finish -- through every phase of the cycle.
4. The student would learn real-world trade-offs, compromises and how to make the hard choices necessary to get the product out the door on-time and on-budget.
5. The companies using the students would benefit by having their projects done on-shore, by native English speakers, and at little (or preferably NO cost).
The educational system in the US is so far behind other countries it is absolutely dismal. I don't see a lot of change happening. The programs adapt and change with the speed of a dinosaur -- teaching languages and techniques already obsolete. I believe that if business got more involved in funding and working with educational institutions -- the programs could adapt faster, and be more closely tailored to what the real world actually needs.
My university has exactly that as a requirement for graduation. The last course (which normally takes 1 whole year) is developing some software end to end. It's done at the last year of the career. They normally require that you develop something you have a client for. They've got contacts with busineses or non-for-profit organizations. For example, I remember one final project, it was developed for a public children's hospital (which had no resources available). It was some kind of management app for the health records. The most difficult thing about that proyect was that they didn't have any resources. So they had to develop something which would run on a pentium I or II, use Linux and other free stuff. The process of development is supervised by teachers, so the students must use proper procedures to get to the final result. This may not be what always happens in the real world, but it's what ideally should happen.
They've got this kind of requirement for other careers too. For example, in electronics engineering, the students developed an antenna for RFID tags which could be used at a distance plus some software to read what went through. The idea was to control cattle this way. My country is modernizing how we keep track of cattle, and now they're implating every cow/etc with a RFID tag. The idea of the antenna was to keep operators away from the cattle, so they would be safer. Other students developed a cheap (around 200USD) digital osciloscope for use with a PC.
I think it's a great idea, as you leave the university with some "work" experience already.
Hi! In my old CS course there were several projects in the final two years that were so called 'major projects'.
Perhaps the two that most fit what you are thinking of are the 'System Design Major Project' and the
Programming Methodology Major Project. Let me describe each one.
The programming methodology project involved the development of a calendar application. We had a small
team of about 5-6 people (to my shame I cannot remember the exact number). We had to decide what to develop
to satisfy the request and write lots of documents (which counted almost as much as the code we wrote)
The amusing part was that at the end we had to switch our code and documentation with a different group
and then use their code and documentation to add a new feature to their app. This brought lots of things
out of the woodwork. In particular I learned that literate programming can be a royal pain (with apologies
to D. Knuth). We thought we had the best and most detailed documentation for our product and the team
we swapped with thought it overwhelming and hard to use. Go figure.
Perhaps the most memorable project tho was the system design project. Again we were split into teams (again
5-8) people. We were given a vague scenario relating to security, a breadboard, wire-wrap tools and a small
camera on chip - as well as a PC running FreeBSD I think. We were then told to come up with a system in 4-6 weeks
This was in the last term of our degree course - which would have virtually no lectures to allow us to prepare
for exams - except for those of us with joint degrees that had to go to other classes anyway.We had to decide what
system to build, plan it, and 'make it happen'. We had to learn things (such as using ioctl()) to get results from the camera into the PC, we had to learn some X-windows programming, to make the images appear with a GUI.We had to
use/tweak algorithms - in our case for motion detection. We also had to prepare a 'sales presentation' and a 'technical presentation'.
We also fell afoul to many real life issues such as sleepless nights, stress of the deadline, mitigating things we couldn't finish etc. For example: We never got our own camera to work, but we could use another team's to pre-record some material, which we could use (reading from the disk) to demo the top layer of our system and we could also show that we wrote our interface so that we could use a 'video source' rather than just the camera.
Our university had a 'professional issues' course to which they invited various industry IT leaders (from Logica,
Lehman Brothers, Goldman Sachs etc) each to tell us about some software issue in their company. These ladies and
gentlemen returned to our university at the end of the project and we had to pitch the sales and technical presentations to them. So the day of the presentations, all of us students had to wear suits and ties and it looked like some formal affair in the department.
Anyway enough reminiscing. The system design project was probably one of the coolest - but also possibly
the most gruellying -- things we had to go through in our degree course- from bits of hardware and a computer - to a demoable working system presented to industry leaders.
I hope that this info helps.
Or... "Outsourcing 101?" Maybe "Navigating the Food Stamp Office A61?"
I've recently finished my CS studies at Aalborg University in Denmark. The education here is mostly based on doing projects in small groups, one project per semester. So I've been through this 10 times. The master's thesis is just another project.
I've worked on grid software, BDDs for finding optimal task graphs, a decentralised distributed file system, a neural network for recognizing handwritten letters on a PDA, etc. Great fun. Learned a lot too. Especially about designing and developing software with other people.
I'd say go for it.
At my small, private college, we the students made a solution. Compiler Design. It's a senior level course that is recommended only for CS or Computer Engineering students who are serious about programming. It's offered like once every four years simply because not that many people want to take it. So last spring, me and the boyfriend got together four other people, and now we have the class. My professor was going to run it like a normal class, and we were like, "uhh... there's 6 of us. So no. We're going to do a group project." It's working out really well. We've written an interpreter, and now we're well into making our compiler. I think we might be farther along because it's a group project. Plus, since everyone is at about the same skill level, we're all bringing equal amounts of work to the project. It's like we're killing two birds with one stone.
Middleware: we use the term for anything that runs services on it: e.g. tomcat is middleware, it runs on the OS, and apps run on it. Or MQ is middleware too: as you said it connect components and apps together. I do not thing we disagree on that.
... does not matter, at the end it is useful ... maybe ...
I am technically part of a hosting team, and the official name of the group is Middleware....
- Sorry, I react badly to "I'm experienced and know so much more then my young colleagues". -
Yes you react badly. When you are in IT production for 10+ years, you have a lot more experience than others who come out of school. There is nothing bad about saying that. That does not mean that you are superior, it only means that you have a much better understanding of different fields, and when problems occur you do a routine task and it is solved while the others are still searching runbooks and trying to find what could have caused the server to give a specific error, one that you saw 9999 times, but one that is completely new for them.
Business classes: yep, those whould have been good, but the amount of additional crap we had to learn sometimes got on my nerves. Don't get me wrong, I am talking about an european school when additional crap was outrageous thru colleges and highschools in the name of growing "generally highly educated" kids as opposed to professionals in one field.
Hello,
... and none of them, as far as I know, have been teached basics on software development cycle.
Here in France, we often have an additional layer between users and IT team that we may call "business owners" or "product owners". They represent users toward the developpers and are in charge of writing most of the specs, and run the User Acceptance Tests.
In my opinion, this is people doing this kind of job that should have had the kind of classes you are talking about.
But the thing is that people doing this job have very different academic background : from business schools to software engineering, including maths or Computer Science,
Conclude what you want. ^
"I may never prove what I know to be true, but I know that I'll still have to try" Dream Theater "The Spirit Carries on
My University had several project courses, and they were key.
The course content should be very simple. Pick one project and assign it to the whole class. Break out the class into teams and run them through the cycle.
This means an analysis/requirements, a design doc (internal/external), coding (with source control), testing plan (with test procedures) and a team presentation.
This can be completed in one semester and closely approximates a well-managed project. Some organization (DoD projects) will require way more docs and other projects will skip entire phases. This should provide a good average.
For teaching requirements and analysis, check out Ivy Hooks at compliance automation.
Upon graduation from a small state school, I got a job in a large process-heavy (formal requirements, design, integration, code+test, etc). For a long time, trying to understand the development process was a source of frustration and I could not understand why I couldn't just write the damn code. I actually have a friend who devoted his masters thesis to designing a CM course because of his frustration. I find the process an important part of creating good software now, and realize I could have been a much more valuable employee had I understood the process coming out of school.
Now I realize how rigorous our CS curriliculm is at Georgia Tech. Check out the classes- http://www.cc.gatech.edu./ We do at least 3 complete software project including CS 4911 [Senior Design Capston]. Currently I am taking a class where we are implementing a C Compiler. No wonder companies go crazy trying to recruit tech students..
Ok, so the traumatic form is above. But keep users in mind. Don't build it for yourself. Realize that when things aren't in the specifications, that this is your learning opportunity. App dev is 80% domain knowledge (all the peeps who focus on language get it wrong...). Know what it is your app is supposed to do, who it is that's going to use it, get inside their head, and then look at your ap again.
While this 'senior thesis' approach works well for engineering majors, I'd almost suggest that CS majors take the course as a case study. One semester does not allow for getting a handle on scope creep, and I'd guess that most projects end in utter failure. Learning from it may or may not be colored by whatever emotional crises happen during your semester. That said, the only way to learn how to work in a group, is to get practice working in a group. But this can be done on much smaller scale projects in other courses. That, and being a project manager/lead developer usually requires a level of experience/expertise not likely to be found among the undergraduates. So, that's another reason why your semester project will go up in flames.
While with honors theses, you can really only fail once, what makes a case study approach ideal is that you can see failure many, many, many times. And failure will/should run rampant. How many IT projects get scrapped before they get to production? 70%? With case studies, you might actually get a chance to do a few different tech-spec interviews. You might get a chance to interview some industry players. You'll get a chance to look at versioning: 1.01, 2.0, 3.0, etc, which you wouldn't even approach in a senior thesis class. You might actually play with different CVS platforms and get a feel for each, rather than just getting to know the one you end up using (which you will learn in the industry anyway.) Learn to demo, learn how to do mock-ups. Learn to interview. Learn how to get knee-deep into a differnet knowledge domain. Learn how to sell an idea to your manager.
Your senior thesis class will end up taking about 90% of your time coding, which you will think is important, and about 10% of your time learning what you should've done, which you won't realize is important until 2-3 years later. All said, I think the course, as you laid out, might be pretty disappointing.
Drexel University makes its soon-to-be Computer Science graduates complete a three term software engineering sequence. Assuming there is no reasonable argument against using the Waterfall model: the first term is devoted to gathering the requirements for the outside stakeholder; the second is producing a design; and, the last term is devoted to programming and testing the system.
So far (as I am currently going through this), it seems to be worth while. Nevertheless, it is time consuming to do correctly, as our stakeholder has the big-picture of what he wants but not much else. Such is most of life.
Regarding the comments that are to the effect that team school team projects are populated only by dolts and hangers-on, as most of the students that are going through this sequence are getting ready to graduate, most of them see this as a potential networking opportunity and do not want to blow it. Additionally, they want their work to reflect well on the major, as most people have only a vague idea of what the study of computer science entails.
I recently left acedemia and entered the real world. One thing that immediately blew my mind was Agile development techniques. My old software engineering text has about two paragraphs on iterative or evolutionary development, but that is the closest that it came. I had one professor who encouraged us to write tests for our software, but never really showed us how. Now I don't feel comfortable writing code without a failing test. Everything they taught us in school was about big design up front. This might be fine if you are writing code that you will never have to maintain for a quick school project. However, in the industry it seems to be a pretty risky approach.
I would suggest that anyone who is preparing to enter the industry should study up on Agile development processes. There is a major paradigm shift happening now. The time that you spend learning traditional software engineering will more than likely be wasted effort.
We don't teach Computer Science, but a 3 year Information Systems degree. 4 semesters programming; 3 semesters database design & programming; 3 semesters web programming (+ DB back end); 5 semesters OS and networking; 6 semesters systems deign, management and planning; 1 semester accounting. Then the students do an industry project (working with local industry) for 2 semesters and build a fully working system. IMHO, CS is a small sub-set of what's needed. Industry needs flexible and adaptable IS professionals, rather than computer scientists. And BTW, all our students have jobs.
"It is not a monopoly in the sense that people have no choice. People could choose Macintosh or Linux, but they choose to use Windows instead. My point stands."
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.
The word "monopoly" can be used in many distinctly different situations. While Microsoft may have been found to be engaging in monopolistic business practices, that is different than "a monopoly in the sense that people have no choice". Again, you are free to run Linux or Macintosh. Monopoly in the sense that "people have no choice" would be something like the historical situation where you could buy oil from Standard Oil or you could not buy oil. Again, a distinctly different situation that the one with Windows.
For my CS degree, we had a "Final Project" in our last semester where we found a business with a problem, and solved that problem with either a piece of software, database, network, webpage, etc. or all of the above. It was group work, and we took it right from scratch from the business objectives and rules, to the polished user manuals and code release. We created an online inventory management system in ASP.NET with MSQL backend. This gave us a lot of project management, collaboration, coding, technology integration, and tons more of SDLC-like experience. Invaluable in my opinion. It also rounded out everyone's skills, ie. the major coders learned how to set up a database, and the graphics designers got to see the nitty gritty of the code, etc. We were graded on how well we solved the business's problem, not how fancy we made the software, to make it an even playing field. This also gave students an "in" at the company who's problem they solved, and also gave them a few gold stars to put on their resume for finding that first job. It was a competition amongst the entire graduating class, and we invited industry professionals to come out and judge our projects. Also great networking experience. Overall it was one of the best experiences I had in school because we were able to showcase everything we learned and included more than just our technical skills, which often times is just as difficult to project.
Fortunately (unfortunately?) this is GREAT education because it prepares the students for the way the real world works.....
The sad fact of the matter is that CS classes are offered in quarters and semesters. It should take between a semester and a year to get a feeling for a full-scale design / development cycle. But that's only half the story. IMO, a good curriculum would include a year of design / development, followed by another year of support / extension of the code -- it would be good to develop utilities that other students could use, so that there would be a realistic "customer base".
You say that your college education focused on being able to learn "popular" languages, and then proceed to list a bunch of languages that I'd say is more commercial than anything else... My opinion is that a CS degree is useless without exposure to the major programming paradigms, including objected oriented programming, imperative programming, functional programming, logic programming, etc. Show me someone who only learned C++, Java, and VB, and there's no way I'd hire him to do anything but the most simple programming job. I don't actually care what languages a college grad has, but I do care that they know how to learn a new programming language.
I had a class like the one you describe when I was in school. The year I took it, I feel it was a completely useless class (and it ended up being one of my worst grades, incidentally...) My opinion is that the best way to teach this sort of thing is in an experiential way, which really has to be part of a project that takes longer than a single semester. At Harvey Mudd College, this was accomplished in the senior year of the CS Major through a clinic project; that basically puts ~4 students together for a year, working on a project from proposal to completion. I think the best educational experience that pertains to the real world is given to the student team leader on these projects, so I really wish that it was possible to give everyone that experience. (Alas, clinic is an expensive program to run, both in terms of financial resources and in the time given by faculty and students.)
If I was in charge of the curriculum, I'd say don't spend too much time on "the process". Spend enough time to give an outline of how it works so that students won't completely be stuck, but time is much better spent giving students skills that will improve their coding, thinking, and communication skills. There are too many programmers out there who don't have an idea of what run-time complexity their code has, or who can't write in grammatical complete sentences. And more math (especially classes where (gasp) you have to prove theorems) never hurts logical thinking skills.
Then again, perhaps my perspective is skewed as to what one should require of a programmer. I honestly believe that if more computer science programs trained programmers with a more complete theoretical background (the kind of programmer that looks attractive to the recruiters at Google, for example), then software would be generally more usable and less buggy.
I wish I could work somewhere where the requirements docs were only 50 pages. Where I work, we lose count of the pages and have to go by mass;-)
Dum spiro spero
I did a Bachelor of Information Systems degree (graduated in 2003) from Monash University. This degree was focussed on the software development life cycle. It was a three year degree, and each year had a year-long "studio" class which integrated all of the knowledge from the other classes. It had a very strong focus on teamwork.
:-P I've had two jobs since I graduated, one in the public service and one in a small private company, and I've not seen a DFD or normalisation anywhere :-P
1st year: covered introductory concepts, including web design, database design, software development life cycle etc. The studio class focussed on working in teams, and consisted mostly of independent exercises based on what had been covered in the other subjects.
2nd year: Further developed the concepts taught in the first year. Covered things like OO design, normalisation (ouch!), project management etc. Also had some elective subjects (I did basic Java - I'm not much of a coder but it dovetailed really well with the OO stuff I was learning). The studio class (about 20 students) broke into groups of 4-6 and over the course of the year developed a fictional information system. The first half was devoted to requirements gathering and analysis, the second half covered design, implementation and integration. The example system was for a group of stores and had to manage day-to-day transaction processing, inventory management and re-order for all stores, reporting and administration. Trying to coordinate 20 undergraduates developing the same system taught us a lot about the benefit of standards!
3rd year: Most of the subjects in the third year were electives, allowing students to determine which direction they wished to go, such as interface design, IT management, project management etc. In the studio class we were broken into groups of 4-6 and had to develop a real project for a real client. The project went for the whole year, and the grading was based on how well each individual performed in the team.
The main drawback of the course was that there was no coding involved - if you wanted to learn coding you had to do it through elective subjects. This meant it also attracted a whole lot of people who wanted to be in IT but couldn't/wouldn't do coding! The degree was very heavy on theory too, and of course in the real world, most of the theory is totally ignored
The degree kind of died not long after I graduated, and whole of Monash University's IT faculty kind of had a re-shuffle. The closest thing to my degree now seems to be the Bachelor of Information Technology and Systems (BITS) - Information systems major, which seems to be a bit better (it has networking, coding etc).
I like my coffee the way I like my women - roasted and ground up into little tiny pieces.
I just graduated (in May) from a software engineering/computer science school. You have a good point about learning the dev cycle. My schools focus was mainly on programming techniques with some dev lessons. I think that it prepared me better than just learning the techniques would have. The only thing that it was lacking was the deployment phases.... we covered conception, requirement, lifetime dev, coding and testing but no deployment.
In my last semester we did 2 units like this Minor Project and Major Project
Minor project was working solo on a program that you wanted. Basically you came up with the idea, Ok'ed it with the lecturer then designed and implememted.
Major project was a small (3-4) team project and the college actually organised for us to go and talk to local businesses about something that they needed.
I think these were both great especially the major project because of the outside involvement.
Things I think should be assessed/achieved as part of this kind of unit.
1. Reqirements gathering. Check how thourough they have been bonus marks for spotting and identifying problem areas.
2. Design. How well does the design cover the requirements that have been identified
3. Implementation. Appropriate choice of tool, Architecture
4. User Acceptance. Get the user to validate the software.
If you wanted to you could get the teams to act as the users for another team. Ie get them to think up an idea for someone else to do. Also if you wanted you could also add QA to the mix you could get teams to test each others work.
One problem we had was that the slow kids tended to drag the rest of the team down. All marks need to be scaled by the lecturer to allow for this.
When I took "Computer Systems Technology" at my local college (2yr diploma) we did a course that taught things from the different models of software deployment to the Software Development Life Cycle, and even project management - as far as things like managing human resources on the project, contingency plans, deliverables for different project phases etc.
At the end of the program, right before doing practicum work, we split into teams and did a "special projects" course where we put all of that to use and came up with an idea, then self-managed it to completion and handed in all the project artifacts like MS Project files, writeups, source code, etc. as applicable.
This exact course is a requirement of the California state university system. It goes by the name of "software engineering" at Humboldt State University.
The CS major is quite new there, and in the midst of terrible funding due to incompetent upper level administration (president richmond, I'm talking to you), the CS department is making an effort to prepare graduates.
The SE class involves a semester long project integrated with lectures covering basic topics regarding the development cycle. On thing I learned is that the classic waterfall cycle is unrealistic and never works, but still provides a decent model to follow loosely.
One major issue with the course was the chosen medium: a mysql database with a php interface, that supposedly could have served a real purpose for the CS department. It was a great idea, except that DB and web programming are not prerequisites for the course, nor are either requirements for the CS degree. Therefore, some students entered with existing knowledge of the subject, some with none. We also encountered numerous problems using the db and php software available on campus, and were not in control of our own servers. The result was some barely working prototypes but a hell of a lot learned.
I would say that software dev is an extremely important subject withing the CS curriculum. One suggestion I have is that the course may be more beneficial if taught in two semesters, the first devoted to theory, the second to practice. Or alternatively a concurrent lecture/lab. Caution must be taken with the chosen project and the capabilities of the students, but regardless, the course helps prepare students for the "real world," which is often lacking in CS degrees.
While I agree that some sort of true software project is a distinct and necessary part of a computer science education. My school actually has a project course over the course of two semesters that attempts to do that. The problem is that the courses leading up to the project do not prepare you for it. It's as if there is the effort to teach technical writing, project management, the software development and then also have a major project completed. Don't get me wrong, I think the idea is fantastic and is needed. However, there needs to be a base to build on instead of giving students below average grades for something that they have no idea how to do and then responding to criticism by simply saying "well that's how it's done in the real world". Sorry, when was I supposed to learn that? I was in the 'real' world developing software when?
Do respectable colleges and universities still lack a software engineering course in their CS curriculum in this day and age. It's a required, junior-year course here, and it seems like an obvious inclusion. It was definitely eye-opening to work with other people at the same level as yourself and go through an entire design process for a real product.
In all seriousness, I'd be surprised to see that many major colleges did not offer a senior project; I know every CS school I looked at had that built in.
The Software Engineering degree at Cal Poly (the SLO one) is a perfect example of what you are talking about. Its the CSC curriculum with some of the more archaic theory of computation classes exchanged for SE classes. In the last year, a series of 3 quarter classes prepare the student for a career in SE by allowing the class to develop software for a company. Last year it was Trimble GPS. This year it is Intuit. All of the source control of CVS and SVN that people have mentioned here are covered by the sophomore year. If you're looking at undergrad colleges in CS, give Cal Poly a good look. Especially Software Engineering. Not to mention the SE grads have been consistently starting at ~75K right out of school...
I'm a modestly well-doing software consultant ( http://www.cobaltsoftware.net/ ) and I've been working on all kinds of projects with all kinds of team sizes over the last few years as I've been trying to build my business. I did a Computer Science degree at an English university, and in the end all I felt like I got was a huge debt from my student loans and a small piece of paper.
What I've found is that what university (and most universities, at least here in the UK) teaches is so heavily steeped in favor of producing an academic that the only truly relevant modules to conducting modern business were found in the first half of the course (Basic Java, C, and linear algebra). Beyond that it was all heavy-grade theoretical math and largely inapplicable material for modern industry, unless you wanted to become a professor of computer science yourself. The department I attended puts statistics on the wall outside showing the percentage of people employed after graduation, and most of them don't go near programming and will only work with computers to do spreadsheets and email for the most part. Essentially the mathaticians aced the course, thats the kind of slant I found.
Another interesting fact is that the people who knew programming *before* they arrived comprised the majority of people who knew it when they left. I've given advice on final year courseworks to several people who had no idea about the role of interfaces, structs, the return statement in a program. Most people can draw a circle in Matlab, which is only a step above freaking RM-Logo, but they can't independantly write out a binary tree walk function without taking a day or two to do it.
Get yourself a useful degree, diversify your knowledge! Do something in Mechanical Engineering or another science that you are not as well versed in. You can teach yourself C, C++, C#, Java and any other language in a few weeks with a few purchases from Amazon.com and then simply join any open-source project you are interested in, and start becoming a minor contributor (even if it's just cleaning up and documenting), and you'll start to have a real-world appreciation of how collaborative software development works and the tools you'll need to be familiar with.
Regards,
-Steve Gray
Nowadays the students have to take the course twice, once in a developer/tester role and again as a project manager, architect or in another specialist role.
The course is actually one of the best in school and greatly benefits everyone: the students get real-world experience in long term project and the clients get a low-cost, good quality (usually) software solution. The course overview
Karma: Good! Napster: Baad!
I have been working in the Software Industry as a developer and team leader for the past 11 years. I have the following recommendations:
1. Team Dynamics
Communication is extremely important. Very few new recruits understand the concept of working in large teams. You have to inform people of actions that potentially can hamper their work.
Use email, the phone or get up and tell the person your are bringing a database down, checking in code , doing a build. I found that lots of problems occur due to bad or no communication between team members.
2. Tools
Teach people to use the proper tools to help facilitate proper communication in teams. Also, teach tool scenarios in which a real world team can be simulated. I currently work only on Microsoft platforms and can recommend the following tools that any new recruit should know or at least have an understanding off.
- Sharepoint Portal Services or other portal software allowing project documents to be accesible by all team members.
- Source control software such as Perforce or SourceSafe allowing code to be versioned and changes to be tracked.
- QA is crucial on large projects and and understanding of bug tracking software such as TeamTrack is a must.
- A project management tool such as MS Project. At least the ability to interpret a project plan that is posted on the portal site allowing all team members to see proper milestones and understand dependancies on deliverables, again helping communication between team members.
Other tools and concepts I found useful : - Virtual Machine software (VMware, Virtual PC) makes it easy to quickly setup a dev. / QA environment.
- Remote Connections (VNC, Remote Desktop Connection)
As you can see my recommendations are on a technical level but I feel any CS graduate interested in being a developer/team leader/project manager/DBA/IT manager should have a good grasp of all these tools to have the ability to integrate faster into the corporate environment.
I'm tired of dealing with engineer developers that don't know the tools and don't know standards.
.cshrc several time.
Their Unix startups stop working & they expect me to fix them.
They have a PATH that repeats itself until it fills up because they source
They get confused about group membership for sharing files.
I've found users that didn't check code into the revision control system (ClearCase here) in 2 *years* even though we'd had several product releases.
Networked systems that hard coded IP address instead of hostnames and DNS or table lookups.
Install scripts that depended on non standard system hardware or software.
Install scripts for Unix that assume only one person ever uses the system.
Users that insist they need to sit in front of the system to use it.
Lack of knowledge of what others are doing. ex people doing parallel programming but never heard of Beowulf.
Users insisting on using the $40 xyz product that emulates the free one.
Ordering and installing hardware/software without asking my advice. ex "We need a large disk storage" and buying a USB drive on a PC instead of a small raid server setup. And this is the 1st time they've done it while I do it as a profession.
I think I've written the program you're talking about a few times. I think those are the required code standards for any large organization. Though, I'm unfamiliar with this "maintenance" concept you speak of. Sure, that may work for free software where people do it for a reason other than short term profit, but in the outside world, forget it.
This is why I'm a consultant. I can know it's wrong and stupid and do it anyway, because it's what the client wants. Those fancy where and join clauses are nice and all, but the Big Ball of Mud design is the natural evolution of any project that has no direction at all when it's started. Would you believe that there was no indication until the project was done that there was a need for a where or join? It's hard to do more than keep going back with some code and asking "is this what you mean?" with a lot of people. Then, once you get something minimally passable through this kind of iterative process, you end up with no management support for actually doing the project since the prototype is the deliverable in their minds.
I've come to the conclusion that given the choice, business people will always chose the unmaintainable, pre-alpha kludge from hell. Sure, the horrible kludge will cost them a lot more in the long run, but a smart business person will have left and gone to another company before their short sighted decisions catch up with them. It's hard to get anyone in management for a publicly traded company to think past the current quarter. Of course, this is where being a consultant works in your favor. If they want to go back and fix it later, it's always more work to do it wrong, do it right, and do the conversion from the wrong to the right system than it is to just do it right the first time. I know a lot of people pull these scams for job security, but I actually recommend against doing something stupid. Sometimes, I wonder if other people are more concerned with keeping me around, so they want to ensure there is a neverending queue of work left to do.
This goes back to the whole identity crisis of computer science education at Universities. Programming is just a small part of computer science, and software engineering is really an entire field of study unto its own. The trouble is that A.) people study computer science to learn to be programmers, and B.) most universities don't have "software engineering" programs at the undergraduate level. So, on the one hand, while universities want to teach you theoretical academic computer science, they also understand the horrible truth -- that most people aren't really there to learn that. So, you end up with this mishmosh hybrid thing going on, where you're learning some theoretical stuff, and some programming stuff, and if you're REALLY LUCKY, some software engineering, but you're not learning any of them in much depth.
I think would be better if they broke out software engineering as its own major, that had heavy overlap with computer science (just as computer engineering does), but which focused primarily on the creation and architecture of good software. Alternatively, computer science programs could have a specialization track for software development, with more material than these programs currently cover.
My advice to people right now is: Get a job or internship. I had a programming job while I was studying computer science, and it was a great complement to my education.
From my experience: In the spring of 2001 I had the misfortune of taking software engineering from a professor who claimed that "SCHEME is the perfect language for teaching software engineering." While we did try to emulate "real" programming by meeting with "customers" and designing interfaces; most of the lessons were degraded because she was too busy promoting her husband's SCHEME development environment to us.
Thus, from what I can remember during my undergrad CS degree, this is what helped me learn real-world programming:
No, I will not work for your startup
I think it would be a good idea for your school to implement at least a senior project, but you really should focus on doing it in a team. I don't know of many software development shops that have lone coders. You will be amazed at how different and more challenging it is to really work with others to complete something that none of you could have done on your own.
I am about to graduate from a school called Neumont University. It's located in South Jordan, Utah. Most of you won't have heard of it, since it has been around for about 3 years now. The whole premise of the school is learning how to develop software, not just learn computer science. I had gone to West Point and studied computer science there. Unfortunately I got hurt and didn't graduate. Still, the program at Neumont is leagues more advanced than West Point's.
The school goes year round and we are in class for about 40 hours a week, so we finish all the credit hours of a 4 year degree in about 2 years. It feels a lot like a regular job. We focus on working in teams, and start building projects from about the first week of classes. Our course load is split between theory classes and project classes. In my theory classes I have learned C# and Java, how to create and maintain databases in MS SQL and DB2, and how to model business data and data structures. I have also had classes in project management as well as several design theories. In my project classes I have worked in teams that have had 5 to 12 people in them. When I first started my project classes we built some smaller things like a Point of Sale application. I have been part of a team that built a community building site that is similar to Facebook.com. My next project was to create an RSS aggregator sort of like Google reader, but a little more dynamic. The project I have been working on for the past 5 months is an implementation of BPMN (Business Process Modeling Notation) called GWEN (Graphical Workflow ENvironment). BPMN was recently bought by OMG (the organization that produced UML) they are going through the process of formalizing the language right now. What is really cool is that the project is going to be released on Source Forge in about 3 weeks. It will be picked up by future students and developed for the next couple of years.
Neumont isn't perfect. The stress of going to class every day for 8 or 9 hours a day is rough, but it has prepared me well for the real world. I don't know that I could have said the same for a "normal" school.
-Trip