Right now, I’m about midway through a two-year master’s degree in software engineering. (Note: let’s not go into whether SE can truly be called engineering, or whether I"m allowed to utter the phrase “software engineering” in Texas. I don’t consider it such, but that’s the name of the program I’m in.)
With that said, I would say that the vast majority of my classwork has dealt in one way or another with process management. We’ve spent a lot of time on process capability and maturity assessment, approaches to measuring and tracking a process, estimating costs, and so on. This is interesting and should be useful, although I am consciously attempting to steer my degree project in a more technical direction.
So my question for the engineers here is this: In your education, did you also spend a good deal of time on process analysis? I ask because I couldn’t help but notice that the founding fathers of process and quality management all seem to have been engineers–I’m thinking of Deming, Shewhart, and Ishikawa mainly. It’s interesting to me because when it comes to electrical or civil engineers (or chemical or whatever), I thought you spent your four or more years of higher education learning how to do more and more advanced systems, using more and more advanced mathematics.
I didn’t have a mention of it at my research focused university (BS and MS in Mechanical Engineering). My first job out of school was in high volume manufacturing and I learned all about it. All new engineers were put through weeks of classes over their first year or two at the company.
I just graduated in January so everything is still pretty fresh. I never touched process management in my four years of undergrad and I graduated with a B.A.Sc in Environmental Engineering.
Having said that and having just read the (brief) wikipedia article where it states, “ISO 9000 mandates the process approach to managing an organization.”, I realize that I probably have learned a bit about it since we just had our ISO 9000 audit about a month and a half ago.
The subjects never came up during my engineering (Mechanical) education. However, that was 20 years ago.
On the subjects of process management and capability maturity, my answers are more worthy of the Pit than GQ. I’m not saying these are not worthwhile subjects, but I’ve been subjected to their misuse on more occasions than I care to remember.
My main question is on PM and CM is this: how do you gather all this data and organized it in a useful way, and still leave resources to do the actual software development? I am taking what I can get from my classes so I’ll understand the approach, and why some people want the kind of process information they want, but in terms of CMM/I and the five levels I see that as an idealization.
Management systems/quality manager checking in: apparently not in the UK. We take in new engineering and science graduates, post-graduates, and post-docs each year and I have not met one who has had any training in process management, which is a shame as once they do get the idea they take to it like ducks to water.
It is an aspect of “business” that seems to suit the engineering mindset :dubious:
Self-taught, so I have no idea what’s taught in school.
Software development depends a lot on the people involved. If you get a bunch of people who suck, the project plain off won’t get off the ground. If you get people who are impressive, then they’ll slap it out and then go to play ping pong. The problem is that most places have a few of the latter and a lot of the former, which makes management difficult because tracking progress for widely divergent groups of people who are all at the same level in the corporate hierarchy becomes a problem. Some of your team is playing ping pong and free to use except for that all the stuff remaining is still assigned to someone and it wouldn’t do to reassign it to one of the fasties.
So essentially, lots and lots of “methods for managing software development” have arisen to try and, essentially, get the guys playing ping pong to look like they’re working by making them sit in meetings for 60% of the work week.
Quality assurance is probably something that could handle getting touched upon in school, though. A lot of the problems you see in Microsoft products, old protocols like email which allow spam, and the Y2k bug are due to a general theory of programming that if it does what it’s meant to to do, that’s enough. So if your classes include things like looking for security holes like buffer overruns and stuff then good on them. If they’re teaching you things like Six Sigma then I fear that you’re spending money on schooling that is doing little more than teaching you how to BS your way through some of the sillier bits of modern corporate spiritualism. If that’s so, you might want to see if there’s any way to move your credits to a different school, or some way to change to different courses that are more tech centric.
EE here. It wasn’t part of my training at all (20+ years ago). I had friends in ME and it wasn’t part of their training either. I think it was part of the ChemE program, though.
BS in biomed, getting an MS in biomed now, and nope, nary a mention of it. The closest I’ve had is a couple courses where FDA regulations as they pertain to biomedical devices were mentioned and we went into PMA, 510(k), etc…
I think the industrial engineering and engineering management majors at my undergrad school (RPI) had courses like that, but I’m not sure (it would certainly makes sense for the latter…Hell, that’s pretty much all the latter is, right?)
EE here. I never had to take it as an undergrad. I’m now working on my MSEE, and I elected to take a class in it. I think it was called “Engineering Management” or something. I’m not sure why I took it.
Here here!
In the previous department I was employed in, my boss became a religious fanatic of ISO-9000 and eventually got us registered.
[Pit Rant]
It was the most useless system I’ve ever seen. Heck, it was *worse * than useless… it was a *complete * waste of time and money. Efficiency plummeted and I think we even lost customers over it. It also became apparent that my former boss was using ISO-9000 to control people. (He was always a control freak. After getting certified he would say, “It’s not that I want it this way! You see, we’re ISO now, and ISO says it must be this way.” Yea, right… :rolleyes: )
I recently changed departments. One of the primary reasons was because I couldn’t put up with the ISO !@#$% anymore. I am now in a non-ISO department, it is sooooooooo much better. What a relief. I can now go back to doing my job.
[/Pit Rant]
The place where I work (my division, at least) is ISO 9000. I agree with you that it’s a bunch of useless crap. We haven’t lost any customers over it, but it seems like all you need to do is baffle 'em with a pile of paperwork that says you have procedures for crap and they are happy. We also have a “quality statement” that we are supposed to memorize and be able to repeat to the auditors when they come in.
It’s all a great big exercise in bovine scatology if you ask me.
There was no process management when I was in engineering school (graduated 1987).
I agree to a point. ISO forces a company to document its processes, but even if you document how you make your crappy product, you still make a crappy product. I’ve never seen ISO as a “process improvement” model; perhaps the latest revisions have started incorporating this idea?
The previous company I worked for was using the Capability Maturity Model (CMM in the old days, nowadays, its CMMI–“I” stands for Integrated). I’d been previously exposed to half-assed process improvement schemes and remained skeptical for the first few months. Well, I had a change of heart when I saw that it could work, but required the following iron-laws of implementation:
Hiring competent QA people who know what and how CMM (or Six Sigma, etc.) works.
Management must be absolutely supportive of it from the top down, even it temporary affects the bottom line a few percentage points for a few years (ha!).
It takes years to implement process improvement, not minutes.
Ensure that you are managing the process and not the other way around.
Be willing believe the metrics.
(I joined up when the SW group I was assigned to had just won CMM Level II status. I was involved in the movement to win CMM Level III and then working on Level IV about four months before they closed the plant down.)
In a nutshell, I was pretty impressed. The software estimates (tracking, time, problems, and results) were accurate; within 5% or so. I was just so use to living with the shifting “date of completion” that I never thought it was possible to make a realistic prediction. The key was collecting enough metrics to show middle and upper management what was realistically possible. At first, they were not to happy about a project taking two to five times as long as had previous estimates (although they understood they were just as culpable for accepting an unrealistic bill of goods in the first place), but after we started meeting the target dates, they were sold on it.
Unfortunately, while make a serious attempt at completing Level IV we were closed down by management in Europe for competitive reasons (the technical term is called “outsourcing”). I joined up with my current company (non SW) which uses ISO and something I’d never heard of before: “Lean Management” as a method of process improvement. It comes across as more of a business fad, but it works for the most part. I just think CMMI would be a more to their liking if they were willing to give a chance, IMHO.
