The Software Engineering Life Cycle

A guest post for Handshake 2.0 by Ryan Hagan.

In Mobile App Programming vs. Mobile App Engineering, Dr. Balci presented a diagram which he referred to as the "Software Engineering Life Cycle." There are many possible life cycles, and the Waterfall model, which he proposes, is generally regarded as outdated.  Unfortunately, colleges and universities often teach Waterfall as the only software engineering life cycle, and students enter the world thinking that's the only way to develop software. 

Let us travel to the land of make believe, and imagine a developer following this model.  Steps 1 and 2 are the requirements-gathering phase.  Once that's done, the developer does steps 3, 4, and 5 in relative isolation.  The client gets its first look at the finished product at step 6.  What happens if a developer misunderstood some of the requirements in step 2?  Well, then, what the developer delivers is not what the client wanted, although it may have been what the client asked for.  Any number of communication failures can lead to this situation.

That's not to say that the Waterfall method is useless.  It's not.  NASA follows this model with great success.* However, other models may be a better fit for a business or a style.  Other models popped up alongside Waterfall, including Incremental, Spiral, and Agile.  In today's fast-moving business environment, the Agile model** has become popular. 

Unfortunately, any and all of these processes can be inappropriately blamed or praised for the failure or success of a project. A development model simply doesn't have that much power.  If a building collapses, is the scaffolding to blame?  Of course not.  The choice of development model is usually left up to the developer, and should include the client's desired level of exposure to the project.  If a client simply wants to order software and see a finished project sometime in the future, great, use the Waterfall model.  However, most clients want to watch the software mature, and appreciate frequent communication with the developers, in which case the client would probably want an Agile model.

In the interest of full disclosure, I fall squarely in the Agile camp.  I've had the most success with Agile models, but I try to be open-minded when someone wants to try one of the other, broken models.***

*What Mars Lander?
**Even this is a misnomer, as there are several different Agile models, Scrum, XP, Kanban, Continuous, etc.
***That was a joke.

Ryan Hagan has kindly written several guest posts for Handshake 2.0:
Programmers and Engineers
The Really Interesting Conversations in the Technology Sector
Creating Peer Groups for Technology Industry Specialties.

Top 10 of 2010 on Handshake 2.0
3 Reasons to Stop Marketing to the General Public


  1. That clients and programmers learn during programming has been my experience.”Modern software development techniques are largely unknown to ecologists” seems unfounded. The 5 authors who said this offer a solution to the claim in Frontiers in Ecology and the Environment 2010;8(5):253-260,doi:10.1890.080141. Perhaps this is another life (or death) cycle?

  2. “That clients and programmers learn during programming has been my experience.”

    Hear, hear! That’s been my experience, too.

  3. I rarely hear anyone discuss budget in relation to the SDLC. Vendor management is also a crucial factor in deciding how to organize your project.

Speak Your Mind