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.
Whenever you are going to a trip, you always take in consideration some important details or even make some preparation ahead of time. You check the weather report of the place you are going, to know which type of clothing you are going to take. You even check the place you are going to stay in; or even, buy the plane tickets way ahead of time, if you are going to travel by plane. All of this activities are made before you are in your actual trip, so you can have a relaxing vacation. Can you imagine not having a place to stay and try to find one when you are already in your vacation? Sometimes it can be very exhausting and may take a bunch of your time, that you can spend having fun during your trip.
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.
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 to a project, specially because you need to take in consideration the consequences. He proposes to have a «change board», that will be in charge of taking care of this situations. this board need to be made of stockholders, project managers, marketing, user support, etc., because every area that is involve in the project needs to know about the changes and approve them. This is important because maybe for an area a change could be an insignificant change, but to another it could mean the complete change of the plan process.
With change control comes a very valuable benefit, which is versioning. Thanks to change control, the team can have access to previous versions of the project, and I am not talking only in the «code» aspect, but also in the documentation aspect. Is important to know which changes are important to make and in which parts of the project. There’s been situations where, I am on a project and all of the sudden the requirements change without any notification what so ever. This is something that is common when you are in a project; but when you have a good change control this can be prevent, or it can be perform in a better way.
Stay Safe
A.C.
References
McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.
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.
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 of the downstream activities are in a constant cycle, until the project is release. I have kind of work, with this method, because in the school projects every partial teachers ask you for your advance. The difference comes, when instead of release the software at the end of each phase, my team and I, we just showed what we have done.
McConnell list some of the most important benefits of stage delivery, which are:
Critical Functionality Is Available Earlier
Risks Are Reduced Early
Problems Become Evident Early
Status-Reporting Overhead Is Reduced
Staged Delivery Makes More Options Available
Staged Delivery Reduces the Possibility of Estimation Error
Staged Delivery Balances Flexibility and Efficiency
All of this advantages are great, but in my opinion one of the most valuable is that risks are reduced early. I say this, because I have been in situations where the planning wasn’t good enough and almost at the end of the project, there appears dozens of bugs and problems that could have been solve in the beginning of the project.
Take in consideration, that McConnell is just proposing one way out of other ways of doing a project. He mention this one because is the one that he observed that has more advantages in some cases. According to the situation you are in maybe stage delivery won’t be the best approach to make a project. So before you start your project organize yourself and your team, and try to select the best methodology according to the project.
Stay Safe
A.C.
References
McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.
Don't Trust Humans, Trust Computers 