SWEBOK vs. Core Processes of the SDLC

Below are two different methods that outline the process for building software applications.


Method 1:  Core Processes of the SDLC

1. Identify the problem or need and obtain approval to proceed
2. Plan and monitor the project--what to do, how to do it, and who does it
3. Discover and understand the details of the problem or the need
4. Design the system components that solve the problem or satisfy the need
5. Build, test, and integrate system components
6. Complete system tests and then deploy the solution

Method 2:  SWEBOK Knowledge Areas

1. Requirements
2. Design
3. Construction
4. Testing
5. Maintenance
6. Configuration Management
7. Engineering Management
8. Engineering Process
9. Engineering Tools & Methods
10. Quality

The six core processes tend to focus on a lot of effort on the pre-processes such as Identifying, Planning, and Discovery.  These steps are seen later in the SWEBOK KA's.  SWEBOK goes right into Requirements as the first step whereas the core processes don't get to this until the 3rd step.  Many would argue that these pre-processes are the most critical of steps as it allows you to create a scope around your project and really define what you are wanting to accomplish with the project.  It also defines the Who, the What, and the How of the project...all very critical components.  What good are the best requirements if you haven't really done the pre-work.

The Knowledge Areas are further broken down into sub areas.  For instance with Requirements you actually have 7 subareas:

1. Requirements fundamentals
2. Requirements process
3. Requirements elicitation
4. Requirements analysis
5. Requirements specification
6. Requirements validation
7. Practical considerations

So really we have a very granular Knowledge Area that really breaks up requirements into all of these different sub areas.  With the six core processes we merely have one step (3) of gathering requirements and there is no significant detail around creating those requirements. 

Another thing to note about the KA's is that they are broken up into two separate groups.  The first five KA's represent something similar to a standard waterfall methodology (though that is not implied).  The last 5 (with the exception of Quality) are not really present when talking about the six core processes.  These 4 KAs are:

1. Configuration Management - the discipline of identifying the configuration of software at distinct points in time.  
2. Engineering Management - deals with the management and measurement of software engineering.  also deals with much of the pre-work of a project such as planning, scope, initiation, etc.
3. Process Management - managing the process itself through implementation, assessment, measurement, change, etc.
4. Tools and Methods - the tools involved as they relate to the other KA's

Both of the methods above have their similarities and differences.  I am probably more familiar with the 6 core processes than I am with the SWEBOK KA's.  When utilized they will both help to manage the project of building application software, though like with any type of project they will not magically solve all of your problems.

3 Possible "Silver Bullets" to Software Development

How can we make the software development process better?  Many things seems obvious, but little has been done to thwart this age-old dilemma.  I don't really think I have any "silver bullets" to this problem, but I do offer three possibilities below:

Silver Bullet 1:  Change Things Up!!  Incentives??

Too many times I have been on a typical project (typical for my organization) and before it even begins the programmers (and most of the others on the project) are already digging their heels in for months of work.  Why does it have to be this way?  Why does this project really need to take 3 months?  I'm sure if we analyzed the actual amount of work that needs to be done, it will usually be less than that, but in actuality it will probably take longer than that.  I think there needs to be a shift in thinking.  I think too many people are complacent and even "lazy" if you will.  If they can get by with doing as little work as possible during a day, but still get enough done to progress the project forward, then that's what most would do (heck, I'm guilty of it).  Maybe if there was more of a "financial incentive" people could shift attitudes and really go that extra mile to get the project done.  If I keep my job whether I get this project done on-time and on-budget (or not) what is the incentive for me?  I will just do my part of the project and let someone else worry about the rest.  If someone was going to give me $1000 bonus to finish my part in 4 weeks instead of 6, perhaps I would consider doing that.

Silver Bullet 2:  Hold programmers more accountable (more design docs)

I think that many programmers get away with high estimates because not a whole lot of people can understand what they do.  The business folks don't want to worry themselves with all the technical jargon, so they usually take the programmer's word for it and don't question first, second, or third level estimates.  I know in my organization the programmers do not (and really aren't even required) to create design docs on what they build.  They just build programs that nobody understands but them.  And when it comes down to makes changes later on, the effort is costly and time consuming because no one knows how the program works to begin with (and what if the original programmer is no longer with the company)?  Design docs could help all to better understand the program, and allow for more realistic changes and upgrades later.

Silver Bullet 3:  Bring back coding on-shore!!!

I think the author of the article had it right, experienced and knowledgeable programmers are really worth their weight.  I can't tell you how many times that I have worked with offshore programmers that don't understand a thing about software development.  They have usually never coded before and just don't understand our businesses enough to be successful.  I'm not knocking the whole model  (I know that some organizations have had success with it), but how long did it take before that success was reached?  Do these organizations go back and analyze the cost differences in the two models to see if there really was a savings?  Or do they just look at the bottom line (i.e. paying US person $100/hour and paying offshore $50...no brainer).  There are so many other things to consider.  Are your projects taking twice as long to complete?  Is the code being churned out more buggy?  Are there corners being cut in other places?  Testing?  Design?  You have to look at the whole package. 

Like the author said, there really is no silver bullet.  But trying new things to find a method that actually works for your organization is better than just sticking with the same old method that has been losing your company money year after year.  Maybe adapting/changing is the silver bullet, or as close to one as we can expect.