To Design Software, or to Design Software? The Comparison of Two Common Software Engineering Processes

Last week in my Software Systems Analysis class, we looked at two different perspectives on the Software Engineering process:  one proposed by our Satzinger textbook and one outlined in SWEBOK, the Software Engineering Body of Knowledge.  Below I have matched up the functional areas that I think are related with Satzinger being in red and SWEBOK being in blue.


Functional Areas that Line Up:

1. Satzinger's first step is to "Identify the problem or need and obtain approval."  I believe this loosely maps to SWEBOK's "Software Engineering Process" phase, which covers "the definition, implementation, assessment, measurement, management, change, and improvement of the software engineering process itself."
2. The next step in Satzinger's process is to "Plan and monitor the project", which I think binds closely to SWEBOK's "Software Engineering Management" that "addresses the management and measurement of the software engineering."
3. The next step is to "Discover and understand the details of the problem or need."  SWEBOK's "Software Requirement" maps nicely to this section. 
4. Satzinger has next to "Design the system components that solve the problem or satisfy the need," which can map to "Software Design" in SWEBOK.
5. The next step is to "Build, test, and integrate system components."  This lines up with SWEBOK's "Software Construction" phase.
6. The final phase that lines up between the two is to "Complete system tests and then deploy the solution."  This lines up with "Software Testing" in SWEBOK.

While these are very loose comparisons, there are some aspects of SWEBOK that are not covered by Satzinger or perhaps Satzinger combines them into other functional areas.  For example, SWEBOK details a section on "Software Maintenance."  This section covers what happens to the product after it has gone into production.  Another example is "Software Configuration Management."  This section defines each configuration change so that it can be traced throughout the lifetime of the product.  A third example is "Software Engineering Tools and Methods."  Satzinger does not really have a specific section on the tools and methods used but discussing both through out all his sections.  Finally, "Software Quality" is the last section not fully discussed in Satzinger's version, but just life with the tools and methods section, this too is discussed throughout each section of his process.


While this is a quick and dirty comparison, you should really review all methodologies before starting a project to verify that it will work in your environment with your team.

A Silver Bullet to the Demise of Moore's Law?

This week in my Systems Analysis class we discussed software engineering and the processes one might take in developing a software package based on the Agile fundamentals.  We also discussed briefly Moore's Law and how it's slowly coming to an end.  Although, I did find this article today announcing that IBM is still making leaps and bounds in terms of hardware development.  I guess someone did not tell IBM's techs that they should sit back and relax a while.


So, what do I foresee as being a possible "silver bullet" to combat the fatigue in Moore's Law?  The first thing we can do is to start a science and engineering education initiative in our public schools.  I didn't know anything about engineering before I went to college to become one.  I just knew that I was good at math and science and that computer engineering would be a good place to apply those skills.  But we really need to educate the next generation on what's possible and what real-life software engineers can accomplish.  We need to build momentum!

The next thing that could dramatically change the software development process is to gain buy-in from the community at large.  There are so many types of software development plans out there, and not all of them are applicable to certain situations.  So many companies get into ruts with their software development planning, if they have a plan at all, that they don't not see (or know) that there might be a better solution out there.  We need more places like TopCoder to really build momentum and educate the community around the cause.


The final item that could be a game changer is if a fundamentally new hardware product gets released on the market.  With the development of a new synthetic compound or with a change in how hardware and software interact, the bedrock of software development could essentially change or become obsolete.

In the immediate future though, I don't see there being a "silver bullet" to the werewolf of stalled innovation.  We will need to make significant changes to our culture to encourage and open doors to math and science for all ages, races, and genders.  Or another Steve Jobs.  Or a major break-through in hardware platforms.