Found it (includes chapter 15 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

System testing goes almost along construction, as you should make a system test before and after you are trying to integrate new code into the project. But, how can you test your project? If you have been following the guides from chapter to chapter, you should have a user interface and a user manual by now, and using those you can make test cases even before the code is implemented. The way you test the project is made by simply checking if it passes the test cases that you have developed.

With the approach followed on McConnell’s book you won’t find that many errors, this is because before passing by the system testing, everything has already passed by a review  during user-interface prototyping, User Manual/Requirements Specification review, architecture review, detailed design review, and code review. And everything will have been both unit tested and integration tested by its developer. Plus the daily smoke test. This will avoid entering a cycle of infinite errors.

At the start of each stage you should add new test cases, so the requirements in that stage are fulfilled. If a build doesn’t pass a test, it will go back to development. If an error is found, it should be corrected, not ignored, this sounds obvious, but it doesn’t always happen.

When many errors arise on a routine, don’t waste time on solving the errors separately, redesign that routine and reimplement it. Chances are you’ll waste less time and money.

As a developer, I both like and don’t like finding errors, it means more work, but it also means that the thing that I’m doing can improve, as a tip, I would recommend focusing on the “it can improve” part, when the error is gone, you’ll be happier, because you now know that your code won’t

Continue reading "Found it (includes chapter 15 Software Project | Survival Guide)"

Build it guys (includes chapter 14 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

Construction is the stage where software comes to life. If previous stages have been done well, this will go smoothly, as features are added incrementally, the team should be able to test them and track the progress of the project. The team should keep the focus on simplifying the software.

Constructing can either be fun or disgusting, it all depends on how you planned it, if you planned it poorly, you’ll be struggling just to save your building from falling apart, but if you made the necessary preparations, you’ll even be able to choose the color of the paint for your walls.

Use code standards, they’ll help you in the task of making a code understandable to many developers, not only one. Keep the standard from project to project, that way, developers won’t have to learn a new standard each project, and they’ll be able to reuse code.

In order to add more code to the main build, the book recommends following some steps:

  1. Developer develops a piece of code.
  2. Developer unit tests the code.
  3. Developer steps through every line of code, including all exception and error cases, in an interactive debugger.
  4. Developer integrates this preliminary code with a private version of the main build.
  5. Developer submits code for technical review.
  6. Developer informally turns code over to testing for test case preparation.
  7. Code is reviewed.
  8. Developer fixes any problems identified during the review.
  9. Fixes are reviewed.
  10. Developer integrates final code with the main build.
  11. Code is declared “complete.”

I, as a developer, agree with this steps, they reduce the number of errors, and when done right, you can be sure that the code submitted is done, and the feature it covers is complete. Continuously coding without revisions will lead you to a loop where you’ll always  be searching for

Continue reading "Build it guys (includes chapter 14 Software Project | Survival Guide)"

Just as a checklist (includes chapter 13 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

On this chapter, detailed design was discussed, it can affect the whole project and it extends design work done during the architecture stage. During stage 1, detailed design  requires verifying the quality of the architecture, if it has bad quality, it’s time to correct it.

Detailed design also uses a staged approach, at each stage developers design the features that’ll be delivered at the end of that stage. A good architecture will let you focus on the current stage. During detailed design is when developers check if they can reuse components.

At the start of each stage, requirements must be clear, if a requirement is not clear is either resolved during that stage, or resolved in a later one, but the leadership should be informed about this delay. Delaying a requirement is a bad idea, if you do it too often you’ll end up delaying the project. And remember, a project is delivered a year late one day at a time.

Requirements flow from requirements to architecture to detailed design to code and test cases. Developers must continue doing detailed design until they get miniature milestones for construction. But how much does that is? It depends on the experience of the developers and the difficulty of the project, the more experienced the team, and the easier the project, the less detailed design you’ll need. Still, more is safer.

After done, detailed design should be reviewed,  and it must have correctness (will it work?), completeness (for everything we intend it to work?) and understandability(is it clear how it works?). With detailed design reviews, more than one person knows each part of the project, so if someone goes missing, you’ll have at least a plan B.

Be sure to use detailed design on your projects, a little

Continue reading "Just as a checklist (includes chapter 13 Software Project | Survival Guide)"

The Finish Line

--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. 

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

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

Continue reading "The Finish Line"

A closer look into Stage Delivery (Part III)

--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. 

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

Continue reading "A closer look into Stage Delivery (Part III)"

A closer look into Stage Delivery (Part II)

--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. 


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

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

Continue reading "A closer look into Stage Delivery (Part II)"

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:

The Blue Prints of Software

--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 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

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:

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.

“Quality” flickr photo by Elizabeth Hahn

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!"