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.
A class like that would be very beneficial to students, even if it does not completely mimic actually working (nothing really can). So much of CS focuses on the technical end of things, and I don't think enough emphasis is placed on the human side of things, be that interaction with the user or interaction with management.
'Every story, if continued long enough, ends in death.' --Ernest Hemingway
I'm a big fan of this. We had essentially what you describe at my college, in the form of a Game Development Class run by a teacher in the design college. At the beginning of the semester people pitched projects that they thought would be interesting, the group voted on 2 or 3 to move forward with, and students joined the one they were interested in. Design, development, coding, art, all were created from scratch. We had to go through and decide what external libraries to use, how to manage our codebase, etc. The end goal was to submit the project to the GDC student competition, as well as demo to the class.
Not only was it the most fun I had in any class ever, but it was a great learning experience. Getting to work on the same codebase as 5 other programmers for a full semester is an experience that was very much missing in all the "core" classes. It really drives home the importance of APIs and modular design, as well as teaching you some interesting things about working with other people. I highly recommend the same type of approach to anyone in school who wants a taste of the real world.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
From my (albeit short) experience in human ressources for IT firms ( am a software developer, but I worked for several small companies, so I had to extend my reach a bit) is that this is the biggest reason why, when you're looking for a job, most places tend to require significant real world experience to even consider someone: They are used to the fact that, in general, a student fresh out of school is not very useful in a software development environment (where, unless the company deals a lot with R&D, most of the code is trivial, it is just a matter of integrating the ideas right).
1 or two classes dealing with it could give an incredible jump start for graduates on the job market, once the employers catch on on it.
I'm thinking about dropping my CS major. Why? Although they do teach you languages that are used today in the marketplace and tend toward an education that trains you as an effective software engineer, they don't care about teaching things that make people think about how everything is laid on top of each other and other ivory tower-esque stuff. I was talking to another peer in the CS department (who is similarly disenchanted with the CS program as well) about the various classes he took. "Programming Languages" used to be about, you know, the structure of programming languages. Now it's simply a glorified scripting language survey course. "Operating Systems" used to be about the operating system as a concept. Now it's a glorified Linux Programming course. etc. etc. I'd say that I'd be ready to tackle a project if I graduate with a CS degree from my current university. However, I think I'd simply be another cog in the machine, so to speak. That to me is a less desirable preparation than learning all about theory and finding out how to implement them in the real world by myself.
"Hegelians, who love a synthesis, will probably conclude that he wears a wig." - Bertrand Russell
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.
In Soviet Russia, software develops you. . .
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...
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
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.
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.
>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.
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.
they also need further education in business management and writing skil1z
This is my sig.
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
Uh, many of your suggestions are included under discrete mathematics.
Per Wikipedia: "Discrete mathematics has become popular in recent decades because of its applications to computer science"
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.
It's my understanding that a good CS graduate should be able to pick up whatever language you want in a couple of weeks provided you let him/her know ahead of time what areas you develop in. The purpose of a computer science degree is to give the graduate a diverse background in the constructs and procedures underlying programming. The CS graduate who can't figure out how to solve a simple problem is deficient in critical thinking. It's a failing of the program he went through, and sometimes of his work ethic, but certainly not of the degree as a whole.
Essentially, you're right that CS teaches algorithms, but what you should be looking for isn't dependant on degree. You should be looking for a portfolio of projects that the student has completed throughout his schooling, possibly even before he got into college. You should be looking for competence, and proof that the student is interested in solving problems and not just in the CS degree as a certificate of employability.
The degree is usually just the icing on the cake for a good computer scientist. For the crappy ones, the degree is everything.
SRSLY.
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
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.
Last time I checked, The Theory of Hilbert Spaces and Functional Analysis in general isn't considered discrete mathematics (rather, the continuous sort). Really, if one really wants to get a grasp on stuff with numerical analysis and other parts of Computer Science like artifical intelligence, computer graphics, signal processing, etc. you would need knowledge in continuous math as well. It is unwise to eschew that only for 'Discrete Mathematics', however it's defined at various institutions.
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]
"Consider how packaging (Windows) triumphs over design (Linux) in many markets."
... but I'm not really comfortable with that shade of blue.
;-)"
Those "many markets" are the ones where Microsoft has a monopoly (desktop).
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.
"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 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
You are conveniently ignoring competition. The competition may have something that is equivalent with respect to functionality and price. A better presentation will often make the difference.
"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." In my experience, it is not "Darwinian" at all.
The point above proves otherwise. Two equivalent product, the one with the stronger presentation wins, presentation skills therefore have value.
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.
That is a bit tangential, but you are essentially saying that in calm weather companies with poor presentations can still find customers. In stormier times every advantage is necessary, since presentations skills have value they are even more necessary.
"We are often quite ill-informed with respect to business."
At times that is correct. But it is the exception, not the rule.
"While PHB decisions absolutely do exist, we engineers falsely label some rational decisions as PHB due to our ignorance of issues outside of engineering."
Again, at times that is correct. But it is the exception, not the rule.
I beg to differ. Business, marketing, strategy, etc. are highly specialized skills and engineers generaly do not develop those skills. They are quite busy enough developing the skill necessary for engineering.
Which is the reason you'll see management books written about cheese while others are written about fish.
And we'll see some engineers designing products for cheese and some for fish.
"Learn from the mistake of the people of the "A" Ark.
I think you have your arks wrong.
I don't think so, those on the B Ark survived, those on the "A" Ark died.
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
If I have 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.
Indeed. Why should a student even consider bubble sort at all? Insertion sort is held in better regard for small sets than either quicksort or bubble sort.
But the more important question is, which organization teaches spelling?
I Browse at +4 Flamebait
Open Source Sysadmin
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...
You're a "professor" of "computer science" and you think all a "computer scientist" needs is "discrete mathematics" [whatever the hell that is]?
You consider yourself a computer professional and don't know what discrete math is? Good grief. It deals with math that involves discrete quantites, which is what you have to work with in CS. There are no real numbers in the computer, only approximations, and if you forget that, things will get weird when you can least afford it.
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 you could compare quicksort to insertion sort. No need for fourrier analysis for that. Of course, if you know discrete maths, you might (just maybe) know what a DFT is.
Good grief, and people wonder why the Chinese & Indians are cleaning our clocks...
They aren't. It just looks like that because all the incompetents stay in india and china. Wake me when more Chinese can read and actually think for themselves than US. I'd be happy to show them video of what happened in Tianemen square, thus assuring that a good portion never go back.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
I went to a COmmunity College and no one returns my calls from resumes I submit.
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 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/
As someone with a CS degree, I can state quite confidently that the correct answer is never bubble sort. That decision actually took me considerably less than two days. I hope I never have the misfortune of using any of the code written by your ITT code monkeys.
Best Slashdot comment ever
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
My experience is the complete opposite. Any reasonably competent CS degree holder would immediately be able to identify an appropriate sorting algorithm for most problems. I can't imagine anyone with that background agonizing for 2 seconds over the problem you mentioned.
The college programming course guy, on the other hand, would probably look for the nearest library, and grab the routine that was called sort. He would then use it without either knowing what "introsort" actually does, or realising that (for example) if you're starting with nearly-sorted data it isn't the best choice, or if you're working with data sets that might contain duplicate keys the algorithm isn't stable.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
In my experience, this is the norm, not the exception, at least for large-scale work. I work at a major telecommunications company and am smack in the center of our software development process. Large companies are notorious for being run like a military: the grunts know very little about overall strategy, and are only told what they need to do to do their jobs effectively. Sometimes this means we need to see the company's goals and strategies, but sometimes those goals and strategies are things the company wants to keep out of sight, because they know it's going to be unpopular. We routinely see decisions made by management that appear to be sheer idiocy, clearly run counter to technical recommendations, with no apparent plausible benefit to the business.
In reality, many of these decisions actually are made with business interests in mind. The technical side of the house just isn't aware of it. All they see is a bad decision that nobody wants to explain. This is still a problem, but it's one of communication and trust, not necessarily competency.
Of course, just because I'm considering this to be the "norm" doesn't mean exceptions aren't insignificant or uncommon. In my experience, these issues are less common in smaller businesses as well.
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
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.
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
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
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/
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
If you don't know what Discrete Math is, you have no valid voice in this conversation.
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.
If you're sorting a list with merely 10 or even 100 items, the choice between bubble sort, quicksort, insertion sort, etc, is not very important on an ordinary computer system -- the list is simply too small.
AND you are wasting development time by not merely utilizing the library call and moving on to work on the next thing.
--"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald E. Knuth
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 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.
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.
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.
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.
Can't come up with a logical answer, eh?
http://en.wikipedia.org/wiki/Appeal_to_authority
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 ancestors were on the B Ark, you insensitive clod!
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."
People could choose Macintosh or Linux, but they choose to use Windows instead.
I don't think people so much "choose" Windows so much as it has become the default choice for people who don't
know what they want, just like a car dealer will try to sell their most profitable unit to the customer who doesn't know what s/he wants, whether it's the best 'fit' for the customer or not.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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.
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
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).
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
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
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.
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.
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
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.
I think I've been taught the opposite by forcing me to draw a schema for all my "Hello world!"/"Let's add two numbers" projects. Teaching ADA basics would help :>
Of course... and we shouldn't do allnighters either, and everything should be done before the deadline, and the customer should be happy the first time they see a working app...
I really don't know what is covered in USA colleges. I'm from PUT and CS here covers a bit of everything: algorithmic/math skills(including continuous and discrete math, statistics and the probabilistic theory), computer basics (from basic RLC electronics through programming 8080's by hand to parallel programming and OS inner workings), database basics (mostly Oracle SQL + db theory), lots of different programming languages (asm,C,C++,Java,Prolog,Pascal/Delphi, LISP basics) and some other stuff including computer graphics(mostly OpenGL + how to write a basic software 3D engine), typography (how to properly format our documentation)...
And there's the final project for our BSc/engineer degree, which is not "like a real-life project" it is a real-life project (companies order some kind of software from PUT, and we cover everything from customer interaction to small scale deployment), thankfully the customers are usually already experienced so the specifications reflect the expectations.
We learn to use SVN/CVS, debuggers and other programming tools by the way, when writing our projects.
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.
... 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(); }
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.
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.
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.
real programmers use languages that can wipe the OS by accident if the OS is stupid.
Sorry? Besides maybe some early versions of Windows, and others in the 80s, are there still operating systems out there that don't have some form of memory protection? I agree with the point of using suitably powerful languages for the job, but I don't think that modern OSes are THAT primitive.
I agree with your points, but it should just be something that people learn on workterms or in a college/trade school. Universities are not the places you should expect to teach software maintenance stuff from your list, as has been pointed out by several others in the discussion.
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.
"People could choose Macintosh or Linux, but they choose to use Windows instead."
I don't think people so much "choose" Windows so much as it has become the default choice for people who don't know what they want.
I think they know what they want, they want a computer. They want the web, email, to type a letter to grandma, etc. I would say that these people have chosen to go with the "default" platform for convenience, network effect, software availability, etc. To many people Windows, Mac, and Linux are equivalent, the solve the basic needs mentioned above, so convenience and price become the deciding factors.
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 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?
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...
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 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
You're absolutely right about the small list, and I would expect anyone with a CS background and two brain cells to run together to appreciate that.
Incidentally, your premature optimization quotation is properly attributed to C. A. R. Hoare, the British computer scientist who invented the quicksort algorithm. Knuth borrowed it for his 1974 Turing Award lecture.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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