The 7 Steps of Software Development Case Study - Chapter II

Previous Chapters

» Chapter I: Introduction

Chapter II: The Cast of Characters

Here is the cast of characters for this fictional account of the 7 steps of software development project gone bad. As they say on TV, this story is based on actual events, the following characters are entirely fictional and any resemblance to actual persons, living or dead, is entirely coincidental and the pictures are from clip art galleries.

The Company

‘EzSoftiMortgageCo’ is a vertical market software company in the secondary mortgage industry that’s been in business for about 12 years. During that time it has seen considerable growth both in terms of revenue, nearly $100M a year now, and employees, slightly over 200. When the company began it had almost a family entrepreneurial atmosphere but the growth has led to a lot of office politics, cliques, and the implementation of questionable policies.

Company Management

Phil - The CEO – Once a top salesman for a major national bank, he struck out on his own, started the company in his basement and now runs this rapidly growing enterprise. He’s a no-nonsense, show-me-the-figures, kind of guy. He likes to stay on top of trends both in mortgage industry and in company management principles in general. He also likes to play up the “family atmosphere” of the company although it is really a thing of the past. He’s often out of touch with the day-to-day operations of the company although he likes to practice “management by walking around”.

Stan - The Vice President of Sales and Marketing – Stan has been with the company from almost the start. He likes to tell stories about how he sold the company’s first product line from the trunk of this car during cross country road trips. He was the rush chairman for his fraternity in college and his general demeanor hasn’t changed much since.
.
.
.
Mary - The Director of Marketing – She was hired 2 1/2 years ago based on her extensive industry connections and promotional skills. She’s known as being rather demanding and difficult at times but can really lay on the charm if she needs to. She is often given credit for greatly increasing the sales of the company during her tenure. Other managers in the company hold her in high regard, particularly her boss, Stan.
.
.
.
Bob - National Sales Manager – A frat brother of Stan’s, he’ll do anything to make the sale. He’s a very friendly and outgoing guy but can be rather dense at times when the subject strays from sports.
.
.
.
.
.
Information Technologies

Brian - The Director of Software Development – He has an out-going, hard-charging and often mercurial temperament. He was hired about 6 months ago due to his social connections with other company executives at a local country club. His educational and management credentials are moderately impressive but his programming experience and skills are outdated and weak. He reports directly to Phil, the CEO, since the CIO position has been vacant for almost a year. He is hoping to land this job for himself.
.
.
.
Joe - A Development Team Lead – He has a non-confrontational introverted temperament. His programming skills are considered top notch and other programmers usually like working with him although he often fails to delegate tasks well when in a lead role. He has been the Lead on 2 successful projects for the company. Joe has been with the company nearly 6 years although few people outside of IT know him well since he usually keeps to himself. He had a good working relationship with this previous boss but has not really connected with Brian, his new boss.
.
.
.
Pat - The QA Manager – She’s known for being disorganized and often difficult to deal with but she plays a good office political game. She was one of the first software developers hired by the company and the only member of the original ‘crew’ who’s still around. Because of this she has a good relationship with Phil, the CEO, and often uses this to her advantage. She was promoted to this position several years ago when it became clear that her programming skills were substandard and likely to stay that way. She technically reports to Brian but operates her department rather independently.
.
.
.
Tim - A QA Tester – This job was his first right out of college and he’s been with the company almost 2 years. He did a great job on his first few assignments but has been resting on his laurels recently. He’s a sports fanatic and has won many friends in high places in the company with his spot-on predictions and wagering advice. Pat is his boss.
.
.
.
.
Now that you know everybody, let’s begin the fiasco by moving on to Chapter III: Preliminary Investigation or Analysis, the first step in the 7 step process.

Following Chapters

» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter I

Chapter I: Introduction

This is the story of a software development project gone bad based around the traditional 7 steps of software development. To get things started, we will begin by reviewing these steps that many computer science courses and textbooks describe. This outline usually consists of the following:

1.  Preliminary Investigation or Analysis - This is the task of extracting the requirements from users and gauging the feasibility of the project. Project sponsors usually know what they want but often have incomplete, ambiguous or contradictory requirements. It is the job of software developers and project managers to steer them in the right direction and to clarify the requirements. Upper management, both in IT and the sponsoring department, should determine if the project has business value to the organization and if there are sufficient resources to complete the project as requested.

2.  Specification and Requirement Analysis - This step can vary a lot depending on the formality, size, and scope of the project and the methodology used in an organization. In general, it involves taking the requirements and describing them in a way meaningful to programmers. In your average business application this usually is a mapping between the user requirements and a description of the functionality to be coded into a program, such as a screen that displays current inventory or a report that has this month’s sales figures.

3.  Design or Architecture - This step can also vary according to the project and organization. This step gets into more low level details than the previous step. For example, the specs say to develop a sales report while the design says to use VB.NET, Crystal Reports with an option to export to Excel and to query the data warehouse DB and not the main production DB.

4.  Development or Coding - This is pretty obvious, this is where the rubber meets the road and the program is built.

5.  Testing and Documentation - This is, of course, making sure the program functions as required and that the program’s functionality is described fully to allow for easier maintenance in the future. This is probably one of the least favorite areas among software developers.

6.  Implementation or Deployment - This is process of getting the program into the hands of users. This usually includes more than just the act of distributing the software but also providing training to users.

7.  Maintenance - This step is concerned with maintaining the existing program by fixing any bugs and enhancing the software. With a well written system most of the actual maintenance is for small, incremental, improvements rather than actual bug fixes.

These steps are what happen under ideal circumstances, but what happens in the real world of software development can be quite different. In this 10 part article/story, I’ll be describing a fictional development project that went wrong. It is based on my own experiences and that of other programmers. Some of it is drawn from the experiences I described in my earlier When Projects Go Wrong article.

We will begin with a look at the company and people involved

Following Chapters

» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Add comment May 22nd, 2007

The .NET Random Object

In VB6, and in MS-BASICs going back for probably 30 years, you would use the Rnd function to get a pseudo random number and you would use the Randomize statement before it to ’seed’ the values. This is replaced in VB.NET with the new Random object.

Using this object is simple. You create a new instance of the object, like so

Dim Dice As New Random

And use the Next function to get a random integer in a specified range.

Dim Result As Integer = Dice.Next(1,7)

Note that the lower bound is inclusive, the value given is the lowest value returned, while the upper boundary is exclusive, one integer higher than the highest value you want the function to return.

The Random object also provides functions for returning an array of random bytes or a double number between 0.0 and 1.0.

Unlike previous versions of MS-BASICs, the timer based seed value is the default so you no longer need a Randomize statement. However, you can use an integer value when creating the object instance to get the same value sequence all the time which can be valuable during testing.

One important trick you can use with the Random object is to create an instance at the module or application level, not the routine level. The standard rule when declaring a variable is to limit the scope but this is an exception to the rule. By creating it at a higher level, the seed does not need to be regenerated on each call, which improves performance and helps insure a more random sequence, particularly if many random numbers are being generated quickly in a loop.

Here’s a simple playing card class code example that you can experiment with by making your own poker or blackjack game. In additon to the Random object, this example also uses the generic dictionary and shared members that I’ll be covering in a later column.

Public Class PlayingCard

    Private Shared Suits As Dictionary(Of Integer, String)
    Private Shared Values As Dictionary(Of Integer, String)
    Private Shared CardSelect As New Random

    Private _suit As String
    Private _value As String

    Public Sub New()
        LoadDictionaries()
        _suit = Suits(CardSelect.Next(1, 5))
        _value = Values(CardSelect.Next(1, 14))
    End Sub

    Private Sub LoadDictionaries()
        If Suits Is Nothing Then
            Suits = New Dictionary(Of Integer, String)
            With Suits
                .Add(1, “Hearts”)
                .Add(2, “Diamonds”)
                .Add(3, “Clubs”)
                .Add(4, “Spades”)
            End With
        End If
        If Values Is Nothing Then
            Values = New Dictionary(Of Integer, String)
            With Values
                .Add(1, “Ace”)
                .Add(2, “Deuce”)
                .Add(3, “Three”)
                .Add(4, “Four”)
                .Add(5, “Five”)
                .Add(6, “Six”)
                .Add(7, “Seven”)
                .Add(8, “Eight”)
                .Add(9, “Nine”)
                .Add(10, “Ten”)
                .Add(11, “Jack”)
                .Add(12, “Queen”)
                .Add(13, “King”)
            End With
        End If
    End Sub

    Public ReadOnly Property Suit() As String
        Get
            Return _suit
        End Get
    End Property

    Public ReadOnly Property Value() As String
        Get
            Return _value
        End Get
    End Property

End Class

Add comment May 21st, 2007

Using the Using Statement

The .NET Framework 2.0 added the Using statement to VB.NET. Its purpose is to insure that objects using unmanaged resources, like file streams, database connections, and graphics, release their hold on resources as soon as possible. Using Using can simplify your code while insuring that critical resources are available for other processes as soon as possible.

Unmanaged objects in .NET always implement the IDisposable interface and provide a Dispose() method that you can call to release their resources immediately. However, it was common in earlier versions of VB.NET for programmers to forget to include the extra call to Dispose after using Close. This even creeped into some large code libraries that Microsoft and others released.

Now, in VS 2005, we can use a Using statement block to make our code cleaner looking and to avoid having unreleased objects causing errors.

Using is a block style structure. In the first line, you declare the object you want to work with, most often by declaring it with a New keyword, like so:

Using CurrentFile As New System.IO.StreamWriter("c:\docs\MyTextFile.txt")

After this would come your code that interacted with the disposible object. Finally, you end the block with End Using.

When execution leaves the block, the Dispose method of the object is called automatically, release the file or whatever object is associated with the block. Fortunately, .NET insures that the Dispose method is called no matter what. It even calls it if there is an unhandled exception (except for a StackOverflowException).

The Using block statement is a good way to enhance the stability of your application or component as well as making it easier to code and debug.

Add comment May 20th, 2007

Introduction To XML Comments

Maybe you’ve wanted to use a standard comment method but you couldn’t come up with a good method that everyone in your organization could agree on. Maybe you’ve wondered how to have your components display information in the object browser or in Visual Studio’s Intellisense engine. XML Comments are the way to do this and more.

Adding XML comments to your VB.NET application created in VS 2005 is easy, just type in three apostrophes - ”’ - just before a sub or function and the following template will appear:

    ''' <summary>
    '''
    ''' </summary>
    ''' <param name="param1"></param>
    ''' <param name="param2"></param>
    ''' <param name="param3"></param>
    ''' <returns></returns>
    ''' <remarks></remarks>

The <returns> section isn’t included with Sub comments.

Or you can type the ”’ before a property and get this result:

    ''' <summary>
    '''
    ''' </summary>
    ''' <value></value>
    ''' <returns></returns>
    ''' <remarks></remarks>

Or before a variable and get this result:

    ''' <summary>
    '''
    ''' </summary>
    ''' <remarks></remarks>

What if the XML comment template doesn’t appear? Don’t despair, go to the My Project|Compile section and check the box to “Generate XML Documentation File” and they’ll start working for you.

Using XML comments not only provides a standard way to communicate the purpose of a section of code or variable within the code itself but exposes it externally as well. The Summary section of the comment is what gets displayed in Intellisense popup, as shown here:

This helps you and others have a quick reference to what the particular item is supposed to do. This can be particularly useful for overloaded functions or other complex situations.

Beyond the simple Intellisense functionality, XML comments create an XML documentation file when you compile your project. This file can be used by documentation programs like NDoc and Microsoft’s new SandCastle tool to build professional looking documentation. Creating such documentation becomes easy with XML comments and not such a tedious chore like it often was in the past.

Add comment May 19th, 2007