The Finish Line

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. This is going to be a three-part post, where I talk about the stage delivery methodology. 

Like in every other things in life, what had a start, needs to come to an end. The project you and the team had been developing has ended, for good or bad. Many obstacles where in the way. Some of them could be easily remove, while others where a pain the knee. There were moments of stress and moment of relief. The good thing is that the project is done and now is time to take a break, before you can start you next project. The end of the a project brings a time of reflection to the whole team. The project managers, should be gathering data of the experience of the project. They should be asking for feedback from the team members. As a piece of advice, McConnell says to ask the feedback within the 15- to 30 of releasing the software. He said this because it is when the events are «fresher» in the head of the team.

«Finish Line» by jayneandd https://www.flickr.com/photos/jayneandd/4450623309

As part of gathering information, make a meeting with the whole team to evaluate how well or bad the project went. This meeting is important so can everyone can give their opinion on matters that they thing are important. The good and bad needs to be spoken during this meeting. To make sure that the meeting doesn’t evolve into a debate, make sure to have a moderator to control the meeting. Some people aren’t very outspoken, so you can also make an anonymous questionnaire, where you ask for the opinion of the project. You can make questions that can have an scale, or open question, like you wish. And lastly, make sure you have a project document history where you recorded all the project from start to finish, including the team’s opinion.

At the end McConnell, narrates an experience from the Software Engineering Laboratory at NASA, and he said how this laboratory has been making, excellent quality software for years. And he list 9 of the do’s and 8 of the don’ts of how to make successful software, according to the SEL.

DO’s

• Create and follow a software development plan.
• Empower project personnel.
• Minimize the bureaucracy.
• Define the requirements baseline, and manage changes to it.
• Take periodic snapshots of project health and progress, and replan when necessary.

• Reestimate system size, effort, and schedules periodically.

• Define and manage phase transitions.
• Foster a team spirit.

• Start the project with a small senior staff

DON’Ts

• Don’t let team members work in an unsystematic way.

• Don’t set unreasonable goals.

• Don’t implement changes without assessing their impact and obtaining approval of the change board.

• Don’t gold-plate.

• Don’t overstaff, especially early in the project.

• Don’t assume that a schedule slip in the middle of a phase will be made up later.

• Don’t relax standards in order to cut costs or shorten a schedule.

• Don’t assume that a large amount of documentation ensures success.

McConnell’s Software Project Survival Guide, is an excellent book to those out there that are looking to be project managers. In my opinion, I had always been interest in a PM position, and with this book I can get a clearer idea of how to make achieve it. McConnell gives some very good tips on this book. I know that if I ever become a PM, experience will be one of my helpers to become one and also this book.

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.

A closer look into Stage Delivery (Part III)

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. This is going to be a three-part post, where I talk about the stage delivery methodology. 

Software Release

So our software has been written and tested, now what? Well we can say that we are almost done with our stage, but there are just a few things we need to do before we can pass to the next stage. Is time to decide if we the code that was made can be release to the public, to the client, to the team, to whoever needs to be released. When we say that the code is in release state, not only we say that is done, but also that it has the expected level of quality (if all the correct things have been properly done, obviously). Sometimes this decision is make while the detail design of the next stage is being made, but if theres trouble deciding whether or not to release the team needs to help out in the decision. But when can we say with confidence release it? If you are a little insecure about it, there are several techniques that helps you detect how many defects are in the project, and base on that you can make a decision. The techniques that McConnell propose are:

• Defect Counts
• Statistics on effort per defect
• Defect density prediction
• Defect Pooling
• Defect Seeding

Each one of this techniques have different levels of complexity and time consumption. Some are more accurate than other and each one of them has their pros and cons. But I recommend that you do, at least, two of this techniques in your release stage. Beside this techniques, you also have other sources that can help you like the milestone list, or the code analytics, or the list of defect. You have to remember to make a checklist of things that need to be done, before the other stage begins. This are simple things that need to be done. Once we are ready to release it, we need that all parts involve agreed on the product and sign a document where it states that the product is accepted and you can move on to the next one.

End-of-Stage Wrap-Up

The stage has finally come to an end. All that hard work has been done is time to go to the next stage of the project, but before you go, take some time to look back and see how well the stage went. This phase is all about seeing what went wrong and how to improve for the next stage. It is very important to have a meeting where changes are discuss. This meeting is to see what changes need to made and why. Also, in this phase you can reevaluate your estimates. See how well the team is going, if you are behind schedule or ahead. If you are behind, there are some approaches you can do, like:

• Assuming that the delay was part of the estimate.
• Add the time lost to the estimate you had.
• Multiply the whole schedule by the magnitude of the slip.

You have to take in mind that reestimating is not a bad thing, it will be worst to not reestimate. By doing this is, showing that you care about the project and you want to deliver it correctly. Also reevaluating the estimates is part of a competent development team. Be sure to check that the team is following the plan and that they are ok with it. Remember to always have copies of everything you are doing. I have been in projects were I wanted to see a past version of the project, but we didn’t kept any copy. So it is very important to have back-ups of the code. And lastly, remember to update the software project log. This is very valuable for future references in the project or for future projects.

And with that, we came to a closure of how to make a successful stage delivery approach. Just remember, if you want to succeed in each stage, you need a well define plan.

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.

A closer look into Stage Delivery (Part II)

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. This is going to be a three-part post, where I talk about the stage delivery methodology. 

Construction

Now that we have check the first two important steps in stage delivery, let’s talk about something that every developer likes (well, almost everyone), coding. This part is all about bringing the project to life. Before we have only being making the preparations to make this step correctly. Writing good code is of vital importance in this phase, because good code can bring many benefits, and of course, when we talk about good code, we are also talking about quality. To be sure that the code that is going to be written has the quality level the team desires, is important to have a coding standard. I know, many of us have our own way of writing code and understand it, but when we are working in a team is important to have a certain standard of how to write code. I have been in teams were the code that my teammates wrote, were almost impossible to read and understand. Of course it did what it was suppose to do, but the rest of the team couldn’t understand it AT ALL. Other ways to maintain the quality of the code is to write code as simple as possible, don’t try to make thing very complex. There are some exceptions to this rule, but in general keep it simple.

«Coding» flick photo by Code Life https://www.flickr.com/photos/code_life/33473204734

When developers have finished their parts its time to integrate their codes with the main part. To make this in an organize and correct matter, McConnell recommends to follow a procedure to do this. In projects that I have been, a have follow a procedure to make sure that the part that I made was correct. If you have your project in a repository, like Github, this webpages helps you a lot in this moment. They even have the option to not incorporate your work until some else have check it and approve it. A recommendation that McConnell gives is that in the stage 1, try to implement the skeleton of the whole project. With this he means to write the low level tools first, so in the future stages there’s no problems of, I cannot do this because this core tool is not implement. The project manager should be in charge of checking the progress that the team is making each day and week. And also to be communicating with the client the progress that the team is making.

System Testing

The code for our stage has been written now it is time to test it. One very good practice is to make a daily build and smoke test. This test is about checking that the main source runs correctly without any defect. For this there’s also a procedure to make sure that the test is made correctly. With this test we get rid of the problem of combining code that was already approve, and at the moment of merging the code it causes problems. That’s why this test is made, so if a problem appears at the moment of merging, it is solve immediately. And also, with this test you can monitor your progress easily. When in testing, make sure to have test cases for when the requirements that where develop during that stage, and also to have test cases for past requirements that have already been done. Make sure that when a defect is detected to correct it at the moment. If you let pass all does defect to solve later, it can cause some problems. You can start making test cases at the same moment you are making code. 

This was the second part of a three-part post, to read part three click here.

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.

A closer look into Stage Delivery (Part I)

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. This is going to be a three-part post, where I talk about the stage delivery methodology. 

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.

• Risk management: review the risk list, that the team build at the beginning of the project and make changes if needed.

• Project tracking: keep track of how the project is going.

• Integration and release: The finishing touches have been made and it can be release.

• End~of-stage wrap-up: the team have a meeting about how the stage went and now they can see how well they have perform and see how to improve themselves in the next stage.

It is important that in every activity the team does, they have milestones. Actually there should be milestones since the beginning of the project, but now we are going to have miniature milestones that would help us to have a milestone. A milestone is an important achievement that has been made, and that can tell us about how the project is going. A miniature milestone is that little achievement that if you make tons of them, you can make a big milestone. Look at this as a snow ball. A snowball is made up of thousands of snowflakes, and if a snowflake was missing the snowball wouldn’t have its size. In software, miniature milestones are does activities that can be made in a couple of days and are either done or not done. It is very important to declare a list of miniature milestones at the beginning of each stage.

Detailed Design.

In this part of the methodology, the team focus on designing the specific parts for the stage they are in. If the architecture phase was done correctly, this part shouldn’t be so difficult. The team needs to check the architecture and see how to make the components needed for the current stage. They check that certain requirements are going to be met in the stage, and also, here a miniature milestone list needs to be done for the future activities. The level of detail in each particular design of each stage, depends on two factors: the developers expertise and the difficulty of the project. This factors are important, because they determine how much time you are going to spend in this part. So make sure to have a clear view of this two. 

After a design is made, of course, it needs to be review. The revision is made by two or three co-workers that are in the project. The same person that did the design can’t make de revision. This is do, to have a different point of view and see if there are any errors in the design. Sometimes, people can make very complex designs, when in reality it can be very simple. You have to take in mind to always try to make the design as simpler as it can be. Some of the errors that can be found during the review are: missing requirement and unrequired functionality. Remember that you have you have to document every single thing, even though if it is a napkin with sketches, it needs to go into the documentation. For the first stage try to put the more important functionalities first. And also see if there were any problems unresolved in the architecture.

This was the first part of a three-part post, to read part two click here.

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.

 

 

And the planning continues…

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:

• The estimation procedure must be written.
• Estimates should include time for all normal activities.
• The project plan should not assume the team will work overtime.

• Estimates should be created using estimation software.

• Estimates should be based on data from completed projects.

• Watch for estimates that developers don’t accept.

• The project team should plan to reestimate at several specific times during the project.

• Estimates should be placed under change control.

Now that you a clearer idea of how to get your estimates, let’s move on to how you are going to be working. In the book McConnell propose the stage delivery plan as a way of working, but you can choose any other you want. Stage delivery consist of giving the customer the vital functionality first. So for stage delivery to happen, it needs to have some solid background, and with this I mean that the requirements and the architecture need to be done correctly. In stage delivery you break the project into stages that are going to be release in order. You can arrange this stages in themes, like for example put together the functionalities that resemble and call that a theme and so on with others. In school projects, you kind of work this way. With the teacher telling you to deliver certain functionality for an specific date.

Ok, so the estimate and the stage delivery are done, now let’s review some plans that were made before so we can see how they are doing. In this step you check back the risk management activities, the project vision, the team, and of course you update the software development plan. This are simple activities that needs to be done, but that will bring you a lot of information about how the project is going, in both ways, technical and emotional (talking about the personnel.)

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.

The Blue Prints of Software

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 I was in my senior year, struggling through which university I was going to, I had a very important decision to make, and that was which major I was going to choose. My first option was architecture. I liked the way buildings look, and how you transform simple spaces into something great. But then, I changed my mind because I figured out that it wasn’t the major for me. Then I decided to choose a major in computer science, because is something that I felt very attracted to (and I chose right). Then I started my major, and I noticed that was going to have a class of software architecture. At first, I thought that software was as simple as one, two, three, but then I realized that it is more complicated that it seems. I came to a realization, that building software is something that needs to be thought, and that it needs an architecture to build it right, just like a good building.

«Blueprint» flickr photo by Will Scullin https://www.flickr.com/photos/wscullin/3770016707

In every software project, there needs to be a plan to be able to construct the architecture. Even if you have a small project, you need to take time to think about how the software is going to be made. After you have your requirements, well defined, is time to start building the architecture. There a some some characteristics that makes up a good architecture, like:

• System Overview: the developing team needs to have a broad idea of what the system is going to do. And in here, some discussion about which design is better for the system is made.
• Conceptual Integrity: the team needs to focus on what the system is going to do, as simple as that. Don’t try to make an architecture that will solve every possible problem. 
• Subsystems and Organization: In here, is define how the project is compose and how each of those components are going to work together in a coherent and harmonic way. Each components needs to have a description of what they do, and how are they constructed.
• Notation: the team needs to come into an agreement, of which notation they are going to use to sketch the architecture. The most common one is UML. 
• Change Scenarios and Change Strategy: it is very important, that in this phase, you locate the components that can have a change in the future. You need to point them out and see the future changes that it may have.
• Reuse Analysis and Buy vs. Build Decision: Sometimes, you are going to see that some components you want in your project, you have created before in another project. In here the team needs to make decisions, on whether use code that is already written and make some changes or buy software or create software from scratch.
• Approaches to Standard Functional Areas: the team needs to focus on the different aspects that involves the project, like the database, the UI, the security of the application, etc.
• Requirements Traceability: The architecture needs to fulfill the requirements that were given. Sometime you are so inmerge in the development of the architecture that you forgot the most important factor, which is the requirement list.

There is going to be a time that the teams knows when they are done with this phase. The team needs to agree that this is the best architecture they can build for the project and that it may suffer some changes depending on the client, but in general, declare that is a good and useful architecture.

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.

 

Quality Matters!

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.

«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 in the product. The activities to make are:

• Defect Tracking
• Unit Testing
• Source-code Tracing
• Technical Reviews
• Integration Testing
• System Testing

Each of this activities comes implicates some mini-activities to achieve this as a whole, It is important to take in mind that this steps are very important to have quality in the final product. 

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.