A closer look into Stage Delivery (Part I)

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnellThis is going to be a three-part post, where I talk about the stage delivery methodology. 
Screen Shot 2017-03-07 at 12.44.35 PM
Fig 5-2 from Steve McConnell book “Software Project Survival Guide”

In his book, McConnell recommended to use the stage delivery approach. This approach consist of dividing the project into smaller projects and deliver each mini project in a consecutive way until the project is complete as a whole. We have to take in mind that each stage needs to converge with the last one and so on. But each mini project or stage has to pass through 5 major steps that are the same in every stage. This steps are:

  • Detailed Design
  • Construction
  • System Testing
  • Software Release
  • End-of-Stage Wrap-Up

But before you start with the stage delivery approach, you need to plan how you are going to organize and make some preparations.

Planning Stage Delivery

To make the stage planning easier, here are the activities that need to be taking in consideration, when making the plan (according to McConnell):

  • Requirements updates: The team needs to check the requirements that are going to be implemented in the stage, and also, look if the requirements have change. 
  • Detailed design: Make the design, that will be use in the stage.
  • Construction: The team codes the stages. Usually the persons in charge of the design code the part.

  • Test case creation: Test the code that has been made.

  • User documentation updates: Update the documentation.

  • Technical reviews: check the design and the code.

  • Defect corrections: thanks to testing, the team can locate errors and correct them.

  • Technical coordination: make the schedule to coordinate the team.

And the planning continues…

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell

Being part of a project is difficult, if it hasn’t have a plan. So far we have describe some important steps when we are in a software project. Now, before we move to another major step in our software development plan, we need to make some work that will help us a lot in the future; And consist of three simple activities: 

  • Making Estimates.
  • Writing a Stage Delivery Plan.
  • Performing ongoing planning activities.

This activities, even though they seem simple, they are kind of tricky and need they respective time, so every thing can go right.

When we are ask about getting an estimate, it is pretty simple to just throw the first number that pop-ups in our head. But in reality, saying that number brings a lot of responsibility into the team. You just can’t say that the project is going to be finish in 3 months when is very complex, nor saying you are going to finish it in a year when is very simple. So what is the best way to give an accurate estimate? you may ask. Well first of all, you need to take your time to calculate it, and for that there are software out there that can help you with that calculation. Also, it will come in handy, that you have data from previous completed projects. And you need to take in mind that the estimates may be changing through out the project. When making an estimate make sure to follow this rules:

Quality Matters!

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

In Mexico, we have a saying that when you want to buy something it needs to have the three b’s, “bueno, bonito y barato”, which means good, pretty and cheap. Whenever you buy something, you want this characteristics, in whatever product or service you are getting. You want it to be functional and that it works correctly; you want it to be pleasant to the eye; and of course, if you don’t have to spend a lot for it, is a win-win situation. When we are developing software, we have to take in consideration this characteristics. You need a functional application, with a good user interface and with a good price. In this post, I am going to to focus in the first characteristics, which is the quality aspect.

17517769750_5e5e17d670_z
“Quality” flickr photo by Elizabeth Hahn https://www.flickr.com/photos/128185330@N03/17517769750

In the software environment, you want to make sure you are delivering a quality product; but, how do we know the level of quality in a software product? Well, according to McConnell, he implies that quality is “the degree to which the software satisfies both stated and implied requirements.” Making quality software is very important, sometimes we think that people won’t notice some errors in our programs, but they do. The cost of maintaining a low quality software can be expensive. Sometimes, because you are a little behind the schedule, you make things quick and you forgot about the quality aspect of the project. So to ensure that you are making a good quality product, you must have a quality plan. This plan consist of making certain activities that promotes to have quality

Continue reading "Quality Matters!"

Requirements Development

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

 

15851915765_55be93afdc_z
“Cake” flickr photo by Blondinrikard Froberg https://www.flickr.com/photos/blondinrikard/15851915765

For cooking a cake you only need: a list of ingredients, some basic cooking skills, cooking utensils, time and, of course, passion. You can make the cake all by yourself, but is way better to cook with some company. You may be wondering, what the heck does baking a cake have to do with making software? Well to some extend, is basically the same. To make software you need a list of requirements, some coding skills, tools to make the software, time and, as I mention earlier, passion (most of the times). Each of this activities have their our complexity, it’s not so simple to bake an excellent cake as it is to make a perfect software. Both of this activities could not be achieve, if one simple thing is missing and that is a: list. You can’t make a cake if you don’t know the ingredients, and you can’t start developing software if the list of requirements is missing. Requirements are of vital importance when starting a software project.

A key phase, when developing software is requirements development. The main focus of this phase is to have a clear idea of what the final product is going to do and to whom it is target. There are three main activities, in this phase, which are: 

  • Gathering candidates requirements.
  • Specifying requirements.
  • Analyzing requirements.

The first activity is mostly about identifying key users and seeing what they want. It is very important to know, who is going to be your main users. When you have identify them, you need to ask them what they

Continue reading "Requirements Development"

Ch-ch-changes

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

How many times, have been in the position where you are determine to have something or do something a certain way, but then all of the sudden you see another thing or another way of doing it and you change your original idea, to another one completely new.  Having a change of mind is something pretty common in humans. Changing our minds on vague decisions, won’t bring some drastic outcomes; but when we change our mind during a software project, well…think twice before you want that change to happen.

In this chapter, McConnell writes about the controlling changes and the best way to deal with them. Making changes to a project isn’t a bad thing to do, but you need to take in consideration the implications that making that change may cause; and also, checking if the change will bring a significant value to the project. McConnell explains in the most basic level, change control deals with changes in the requirements or in the source code. And in a more advance level, change control deals with changes in all the activities of the process. 

5994875062_c5330b5262_o
“change” flickr photo by Mark Deckers https://www.flickr.com/photos/27454036@N03/5994875062

McConnell lists a series of steps in which a correct change control procedure should be perform. This list consist of 5 steps, with the last one having some sub-steps. As McConnell explains, some people could see this as a very systematic or bureaucratic kind of situation, only to make a simple change in the source code or in the planning or in whatever part of the process; but in reality, is a very obvious way to make a changes

Continue reading "Ch-ch-changes"

Signed , sealed, deliver

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

There’s a moment, at the beginning of any project, where you start to organize how the process of making the project is going to be. It can be a little hard to think about “how to organize a software project”, because there are many elements involve. But when we are in this phase of organizing the project we need to have in mind, that a project consist of three mayor phases, which are: Discovery, Invention and Implementation. McConnell says that this phases or steps, are going to cross paths during the process of the project. In my personal experience, I can assure you that it is true. But also you have to take in consideration that each phase needs its own time and consideration. In the projects that I have been, we didn’t respect very much the “time” each phase needs and we just make a combination of the three at the same time, which can lead to make a lot of work in the future.

Returning to the topic of how to organize a software project, well, there are plenty of methodologies, one can follow. There is the waterfall development, spiral development, code and fix, and many more. McConnell in his book, proposed the “stage delivery” method. This method consist of creating the project in parts, rather than in a whole. For a better explanation, here is a picture of how stage delivery works.

 

Screen Shot 2017-03-07 at 12.44.35 PM
Fig 5-2 from Steve McConnell book “Software Project Survival Guide”

The picture above shows, how the stage delivery method needs to be develop. As you can see, the upstream activities are only realize one time, while some

Continue reading "Signed , sealed, deliver"

Planning DNA

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

In a previous post I have talked about the importance of having a process in a software project. And as a mention also in the post, planning is fundamental in a project for it to succeed. When we talk about planning we take in consideration many things, like: the software development plan, take estimates, review those estimates, having a quality assurance plan, etc. Planning goes beyond telling everybody what to do, how to do it and when it needs to be deliver. Planning is about checking if the project could really be made, checking risk that can appear, having control of the project.

McConnell mentions in his book that the success or failure of the project can be determine as early as the 10 percent of the way of the project. This is a very important fact for project that needs some kind of funding. For the projects that need some money to continue or to even start, McConnell proposed a two-phase funding approach. Basically, what this approach is about, is to go and find some one that can fund you for a exploratory phase, which could be the 10 percent of the project life; and after that, have a meeting to check the feasibility of the project. McConnell called this meeting: the planning checkpoint review.

Before going to the planning checkpoint review, there are some things that need to be ready so they can be shown, like:

  • Vision statement.
  • Business case for the software.
  • Top 10 risk list.
  • UI prototype.
  • Detailed software development plan.

This were just some material needed before the meeting, but there are more things to add to the

Continue reading "Planning DNA"

How to avoid the avoidable

--Originally published at Don't Trust Humans, Trust Computers

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

When we work in a project, we are always under pressure of delivering the work on time. We are so concern that the project goes the way it’s suppose to go. We sometimes start by looking at the general plain, instead of looking at the details that compose that plain. With all this, I mean that in a software project we start by seeing only the requirements and we define other things and then we start coding right away. This is a very bad practice if you are in a medium or large project. In this example, is lacking a very important component that every project should have and that is a: process.

A process is a key factor so a project can succeed. But what do I mean when I say the word process? According to McConnell a process can have different meanings in a software project, like for example:

  • Checking that the requirements are written and well-define.
  • Developing a quality assurance plan.
  • Making a plan on how the software is going to be develop.

Having a process in your project can bring you many benefits, however there are people that doesn’t look at it in that way. They think that making a process, is going to take away some of the precious time of the “real” tasks. By my short experience in the computer science department, I can say that I know plenty of people that think that way. That once they know the requirements, they want to start coding right away. And this people have the idea that because they are “engineers”, they don’t need to plan; but they are

Continue reading "How to avoid the avoidable"