I am curious to know how people define the following terms:
My explainations are below, but please give you own response prior to reading mine or anyone elses. After posting your answer, feel free to debate the defintions of others, I just want an unbiased answer from people. --Mark
Joined: Dec 04, 2000
(Software) Process: A serious of steps designed to produce software. (Software) Methodology:The combination (or set) of philosophy, process, customs, and culture, used to produce software. Lifecycle: I have seen multiple definitions. They both basically say: "The series of stages/steps of a software project from inception until completion." The differ on "inception" and "completion." "Inception" can be anywhere form "I've got an idea for a new product" to "engineering takes charge of creating it;" and "completion" can be anywhere from "release" to "not only is the product no longer supported, we don't even support the migration tools, anymore." --Mark
Software Process - something most projects spend a half-life documenting, ignoring it the rest of the time because of "deadline pressure". After the project fails, it gets pegged as being flawed or insufficient by the next batch of consultants. Alternative view: Something imposed by management upon developers on the pretext of "getting things under control". Ironically, it is often the case that the more "process" management imposes, the more out of control projects tend to become. Methodology: something you document during the analysis phase of the software development lifecycle (see below). Software LifeCycle: The different phases that a software development effort goes through. It's called a cycle because like history, developers never seem to learn from it and are doomed to repeat it.
Sarcastic as these views may seem, I'm betting a number of you will be chuckling (isn't that a depressing thought?).
I definately laughed. :-) So the reason I asked is because chapter 2 of my book gives an overview and I wanted to confirm my definitions. However I think you illustrate a very valid point. Mind if I quote you in the book? --Mark
Mark, just out of curiosity: where are you trying to go with this? As you can probably tell from my views, I have had a lot of experience with "Projects Gone Bad" type productions. But if the statistics I've heard about are true, a lot of folks should be able to relate to those definitions. My question is, why do things seem to get FUBAR all the time, despite our best efforts? Or am I just becoming a grumpy, disenchanted old man?
Sure you can quote me. And I'm really sorry I haven't been actively reviewing the book. To be honest, it just kind of got pushed to the back of my mind. But if you're discussing things like this then I think I'll crack that zip file open again. What stage are you in now? BTW, why the heck are you still up at this hour? I'm getting old so I only need a few hours of sleep. What's your excuse?
Joined: Dec 04, 2000
Don't worry about the review. I played the numbers game, and got about 5 reviews out of 30 people. I then got sidelined by personal issues: my new job, loss of my computer, other responsibilities, and the weight of the world. The reviews were supposed to go from Sept to Oct. No one did it by the deadline, so I pusshed it back to Nov. The day I was supposed to incorporate the feedback was the day I destroyed my laptop, and it took until the end of the year to get a new one. I kinda lost momemtum and haven't touched it in the last few weeks. So tonight, since the dance club I go to was dead, I decided to come home early, and try to make the most of a lost night by being productive. Sadly, I've found my most productive hours (for school, work, book, whatever) are from about 10pm-2am Fri and Sat night. As for where I'm going with this? We'll, I want to point out why all other methodologies suck, but that if people do exacvtly what I say, and buy my books, software, training, plush toys, anti-rust coating, etc, they can produce good software. :-) Seriously, as you may know, my book is about what developing software is really entails. In some sense, the book is about software methodology. However, I stay methodology agnostic, instead describing the fact that they all do the same thing, just different ways. The point of the book is to illuminate what the steps are, not how to do them. Chapter 2 gives an overview of methodologies and lifecycles, because if you were punting class the day they covered it in college you're going to walk into a job and be lost. ("Don't we just write code until one day we're done writing code?"*) Invest 5 minutes and look at the outline. --Mark *I've got a great sotyr about this in chapter 1. :-)