Monthly Archives: February 2013

Software Engineering Project Take Two:

A lot of the costs for any software project are associated with post-delivery maintenance. This really shouldn’t come as a surprise. However, what might come as a surprise is just how much of the costs — seventy-five percent! So what’s the best way to mitigate the amount of post-delivery maintenance? How about we do things right from the start.

As Project GOOB continues to move forward I have been preparing our requirement/specification document for review. The more I work on it the more I come to realize how easy it is to think like a developer and not as a client without these documents.

The purpose of a requirements document is to provide a bridge between the client and the developer. Our goals are to understand the client’s business model, discern their needs versus wants, and express in a natural language what we as developers need to design to in order to integrate them. In short, we’re building a road map between our client’s business and the software that will help make it more productive.

Functional requirements are the things that our application must be able to do in the most simplistic terms possible. For example, with Project GOOB one of the functional requirement is to create a new alarm. Another functional requirement is to modify an existing alarm. We use these functional requirements to build use cases which graphically represent scenarios where agents (i.e.: users, databases, or even other systems) interact with the system and model behavior from the agents point of view.

Drawing some simple graphical representation to create a new alarm or modify an existing alarm should be simple right? Not exactly. Both of these functional requirements seem to have very similar use cases. Namely: set time, set date, set sound, and set challenge type. But, this is the beauty behind representing functional requirements as use cases. It allows us to spot and redesign potential pit falls, or redundancy, very early in the development process.

You might be thinking, so what. How important is identifying things like this early on? Well, look back up at the staggering statistic: 75% of all project costs are associated with post-delivery maintenance. So, let’s all take a moment, step back from the code we are all so eager to dive into, and think about exactly what it is our client really needs and how we can actually help them do so.

“Code and fix is bad, mmk.” — Some Professor


Software Engineering Project Take One:

This semester I will be participating in my first group software project. I think it’s going to be a lot of fun, a lot of work, and a great learning experience. My team, PBR Code, consists of two close friends I have worked with extensively over the past three semester and another peer who seems to have a solid work ethic.

After a few weeks analyzing and digesting various software development life cycles we were given a mission: Come up with a need for a specific application. After confirming that I had free creative reign, I came up with The Story of Bob.

  • From: S.M.D. Industries:
    To: PBR Code
  • Gentlemen, we have an issue with one of our employees, Bob, that we were hoping you would be able to help us with. Bob is a likeable character. He has a good work ethic, he is innovative, and is fun to talk to. In short, everyone likes Bob. However, Bob has one problem; he always arrives late to work in the morning.After several such occurrences we asked Bob why this was. “I just can’t seem to stop hitting my snooze button.” replied Bob. Of course each of was able to relate. The snooze button is about as tempting as a late night pizza and PBR. Regardless, this is an issue. We can’t just allow our employees to show up whenever they see fit to do so, right?As previously stated, we all like Bob very much. Therefore, we have decided to send out a request for a new alarm clock application that will help alleviate the issue. We believe that if Bob was required to complete some mental challenge in order to disable or snooze his alarm he would be alert enough to make the right decision and G.O.O.B. (get out of bed). We need this challenge to be something quick enough to not leave Bob irritated and upset before work but at the same time awake enough to make clear decisions.

    The ideal alarm clock would be able to be installed on Bob’s android phone so he can take with him on business trips. Additionally, making this alarm able to run on various versions of the android operating system would be nice. You see, we like Bob but he’s also our guinea pig. If the alarm clock application proves successful with Bob, we will be issuing it to the rest of our employees.

    PBR Code, can you help us with this? We would love to hear your thoughts and ideas on possible solutions. Be creative!


    Joseph Dirte
    CEO, S.M.D. Industries

Nothing is better than when you can mix a little humor into your work, right? The team as well as my professor had a good laugh when they read it. From this we will be building our requirements and specifications document for the alarm application. But, that will have to wait until Take Two.

“Choose a job you love, and you will never have to work a day in your life.” – Confucius


Tagged , ,