Build the software

--Originally published at TI2011 – Project Evaluation and Management

Chapter Fourteen – Software Project Survival Guide by Steve McConell

Resultado de imagen para build software

When we are planing a project, we try to visualize how is going to work, which tools we will need, how many time do we need and other questions that we are talking about in the previous post. So, in this post I am going to talk about Construction stage during a project.

Construction is the stage where we create and bring to life the project. If you made the necessary plans, then you will even be able to make more “fancy” your project, perhaps add something that you believe it is not on the requirements but it will help a lot the user.

So, this chapter give us some recommendations in order to add more to the construction:

  1. Develops a piece of code.
  2. Unit tests the code.
  3. Interactive debugger.
  4. Integrates preliminary code with a private version of the main build.
  5. Submits code for technical review.
  6. Test case preparation.
  7. Code is reviewed.
  8. Fix any problems identified during the review.
  9. Fixes are reviewed.
  10. Integrate final code with the main build.
  11. Code is “complete.”

This recommendations are very useful because those help us to reduce errors, make us sure that we submitted the code and it covers all the features that it was proposed.

For this stage we should have an order, start building the skeleton of the project, keep in mind the previous recommendations, documenting all changes and test and fix according with the previous list.


Detailed Plan

--Originally published at TI2011 – Project Evaluation and Management

Chapter Thirteen – Software Project Survival Guide by Steve McConell

It is important to make a detailed design and it is what this chapter talks about. A detailed design can affect the project. It uses a staged approach, at each stage the developers design milestones that will be delivered at the end of each one. So, having a good architecture will help us to focus and get the plan for the current stage that we are working for.

Also in this stage is when developers check and reuse components and code for others projects, sometimes it could happen that when you reuse a lot of components you make this into a library that you can use for any project that will need those.

Every detail is important during this stage, because the requirements must be clear, if not it must be resilved during another stage but it should be informed about this delay (that is a bad idea). You must consider that developers must continue doing detailed design until they get milestone for the construction.

If many persons know each part of the project with the detailed design, then you will have at least another plan to continue with the project.

Resultado de imagen para flow project toon

Finally, if you make a perfect detailed design, but no one cannot read it, then you’re doing something wrong. Be sure to use detailed design on your projects, it will help to deliver your project during the delopment process.

 


Es consistente mi PROYECTO?

--Originally published at TI2011 – Project Evaluation and Management

Como saber si nuestro proyecto, requerimientos, diseños, entre otros son adecuados, consistentes y bien diseñados, quizás no lo son y podríamos afectar todo el desarrollo del proyecto en si.

Recientemente en un proyecto en el que estoy trabajando actualmente, se definieron 20 brechas o requerimientos para todo el desarrollo del proyecto. Pero ¿en realidad son suficientes para el diseño, planeación y desarrollo de tal? Realmente me cuestione esto, y dentro de unas de mis conclusiones fue, depende el tamaño del proyecto, porque si es un proyecto que en realidad solo va a tomar a lo mucho un mes quizás eran las adecuadas, pero luego vino otra cuestión en realidad el proyecto esta contemplado para desarrollarse en tres – cuatro meses a lo mucho, entonces es ahí cuando realmente surgió el problema, no estaba bien definido el proyecto, lo que se iba a realizar no solo era un simple proyecto, sino un desarrollo para una empresa, el cual sus transacciones y operaciones de la misma dependían del mismo desarrollo de este proyecto.

Entonces ¿cuál es el error aquí? Realmente los requerimientos si estaban bien, lo que no estaba era la definición de cada uno, quizás uno englobaba mucho desarrollo o procesos, el cual se podría partir en diferentes brechas o partes para desarrollarlo completamente. Es aquí cuando realmente entendemos que el diseño o la planeación de un proyecto no es un simple a va a hacer esto y aquello, sino la base o esqueleto que le va a dar forma a todo el proyecto. Es como si construyéramos una casa, la cual sin poner cimientos, y al ver que se deshace con cada cosa que agregamos a la casa, hay que estar parchando para que no se venga abajo.

Por ello, les dejo en mente esta pregunta ¿como sabemos que definimos

Continue reading "Es consistente mi PROYECTO?"

Requirements | Prototypes

--Originally published at TI2011 – Project Evaluation and Management

Chapter 9 (Software Project | Survival Guide)

Chapter 9 talks about requirements and how can we transform its into specifications to develop a project. Firstable, we need to understand that with one meeting with the customer we are not able to get and retrieve every requirements, also it may happen (mostly of the times) that the requirement it is not specific to us, because the customer used to explain sometimes in an ambiguous way that we have to define what does the customer want. So that it is important to have in mind this three main activies to get requirements:

  • Gathering / Retrieving
  • Specifying
  • Analyzing

Thus, we need to identify keys, interview some main users, build a basic prototype to define what is what they wants or what are they visualizing, keep getting feedback and start over again until they and you have a basic and consist prototype in which both sides can work.

But check it out, it is a PROTOTYPE, some things can change in order the requirements, but it is more important that the customers knows that it is possibly that the project can’t be at the end as it was defined at the beggining. It is a guide, not a final work to reach!

This reminds me something that in our class TI2011 – Project Evaluation and Management (Ken class), Ricardo Rodriguez Férnandez said to us, that a Succesful Project/Software is a Used Software. So, we may have a prototype but it does not mean that it will be the end result project, there will be a lot of changes in order to be a USED software in which the final users will use.

In conclusion, DEFINE REQUIREMENTS into SPECIFICATIONS to develop, build PROTOTYPES as a GUIDE but have in mind that it will not be the

Continue reading "Requirements | Prototypes"