I want this post to be the last one in this category. I will try to sum everything up in this blog post, at least the most important things I learned. Like a closure to myself. What I like the most about this course were the guest speakers. I don’t thing anyone could have taught us that much things, no matter the experience. I think that, the fact of them being several people leaved me a complete perspective of the management world and the industry in general, rather than staying with just one point of view, regardless of the incredible experience the teacher could have had.
One of the biggest concerns I had starting the semester was my professional future. I am speccing to graduate this December. Starting this semester it hit me really really hard. I didn’t know what I wanted to my future self, specially between becoming a young entrepreneur or making my way into the industry. It did hit me. There’s something personal about me I want to share. I am that kind of person that worries about this things in an unhealthy way. It becomes part of my day. I don’t feel special or anything; I think a lot of students my age tend to have the same problem, but it was like that at least the first two or three months. It was really frustrating to see that there are super successful people in silicon valley that are my age, or even younger. Having this guest speakers let me see their perspectives when they were my age and when they were having the same problems I have and how did they manage them.
This semester was in general hard for me. It was an amazing semester. I had incredible experiences and I had the chance of
¡Hola a todos! Ahora, contrario a la costumbre, haré un paréntesis y hablaré de otro libro también relacionado a la Evaluación y administración de proyectos. Este libro lleva por nombre "The Deadline: A Novel about Project Management" y fue escrito por Tom DeMarco. Contrario a lo que he estado haciendo con el libro de McConnell, aquí … Seguir leyendo Deadline→
Today’s spotlight turn is for Europa Universalis 4, one of my favorite strategy games. In short, you manage a country in between 1444 and 1820, with all the fun of colonizing and reformations. The beauty of this game is its strategic depth. You can’t just be a warmonger and conquer everything. You must fit the pieces in place before any move. Lets assume we are France and want to conquer some english foothold on the mainland. Befare you actually declare war, you need to check some things:
Does England have any allies that would honor the defensive call? Or any of your allies rally with you?
Do we have enough troops, reserves, money or weapons to withstand a war?
Can we win it before it goes too long and our country gets exhausted from fighting?
Are any rebels causing trouble to our provinces?
After all this analysis, you still think you can declare on England, and win? Go ahead, show them the might of the Valois to the british. And while you are showing them who rules those lands, you still have duties to attend:
How are the colonies in the new world doing.
Do Austria agrees to bind our dynasties and form an alliance?
What news do our spies in Spain bring?
If you manage this risks correctly and appease the catholic authority, the Pope, the project of making a big and glorious French empire is achievable.
¡Hola a todos! Continuamos hablando del libro de Software Project Survival Guide, de Steve McConnell. Ahora toca hablar del último tema referente a las preparaciones de un proyecto, precisamente el capítulo se llama "Preparaciones finales". Vamos a ver un poco de qué trata. Muchos de los temas que aquí se abordarán ya fueron vistos en otras … Seguir leyendo Preparaciones finales→
¡Hola a todos! Bienvenidos a otro de mis posts sobre Evaluación y administración de proyectos. En esta oportunidad, les estaré escribiendo un poco sobre la fase de arquitectura del proyecto. En pocas palabras, una arquitectura provee la estructura técnica para un proyecto. Hace el proyecto más sencillo, es donde se plasma cómo se integrará todo … Seguir leyendo Arquitectos del software→
So now we’re done with the boring part. We designed all our plays, and got the best team we could get. Now… it’s
Quality content right here 10/10, best blog according to ign.
Ok, enough delirious jokes for the moment. We’ve reached the point in which we’re finally talking about coding. We get to talk about bringing the software to life, the whole point of all the other activities. Without this everything done before has no purpose, and while you could have a hard time not doing the stuff mentioned before in the book, something would at least come out. Even if it’s a blob-ject. (I already posted that comic so if you’ve seen the comics so far, don’t bother checking the link)
Source Code Quality
The code must readable, therefore a standard has to be agreed upon. Coding standards talk about:
layout of classes, modules, routines, and code withing routines
commenting of the stuff mentioned above
maximum length of a outine in lines of source code
maximum number of routines within a class
degree of complexity allowed
code-level enforcements of architectural standards
versions of tools and libraries to be used
conventions for use of tools and libraries
naming conventions for files
source code directory structure
source code file contents
ways to indicate incomplete code
The code should be made in a way to optimize the project goals during constuction. It must be simple, this will help debugging since it will be easier to understand even if you weren’t the one who wrote it.
The following is an integration procedure recommended by the book
This is the plan for integrating newly developed code into the main build. With this, you can be sure a piece of code is truly done, after all it works with the
Remember how in the architecture stage we didn’t go all out and predict every possible thing? Well why would we, it would be a waste of time because there’s so much that could change that there’s simply no point in doing that. But now that we’re in one of the stages, the foundations are more solid and we can work on making something more detailed.
I’ll how the architecture is in detailed desgin.
Program organization: before it was at system level, now it’s at class and routine level
reuse analysis check for anything that can be reused but now in a more selective way. Maybe a particular class or routine.
Requirements resolution requirements needed for the stage must be resolved.
Requirements traceability, the design must be responsive to all relevant requirements.
Construction plan: devs must build a plan and the list of miniature milestones.
Correction of defects in architecture: fix the defects from the architecture phase.
So how much detail is needed? This graph summs it up pretty well.
Once the design is done, it must be reviewed. A meeting with 2 or 3 people other than the designer is an adequate size.
Each component should be reviewed for these characteristics: correctness (will it work), completeness (adequate for all intended uses) and understandability (self explanatory).
This phase of the stage should help find parts of the design that don’t meet any requirement so you can cutout the extra fat, missing requirements to be attended, unrequired functionality, check if the vision is still the main goal, cross training (the other reviewers will be familiar with each other’s wok), and finally reviews and productivity by not postponing the detection of defects saving time for the future.
Each stage has to attend a certain functionality of the software. Since the plan is to have multiple stages, a plan for each stage must be made. Why? Well read further and you’ll learn why.
Well it can help damage control the shaky estimates made throughout the project. This will most likely be with the project owner though the developers have a concern as well since those estimations will most likely be used as deadlines. Deadlines they have to meet.
Another benefit from stage delivery is the team has to deliver before the final product, therefore they have to focus on making releaseable software thus giving visibility to the project owner and the team.
So that’s why, let’s go ahead and talk about how to do it. The whole plan will be added onto the software development plan so like everything on the internet, it should stay out there.
Milestoned, schedules and task assignments should be described for the following activities:
requirement updates (change board meeting)
test case creation
user documentation updates
technical coordination (talking with the QA team and technical writers to talk about changes to be made)
project tracking (this is wy you make the miniature milestones)
integration and release
end of stage wrap up (here the team looks back to the stage to find the progress made and the kind of practices that helped smooth out the process.)
I mentioned miniature milestones. This will be the groundwork for tracking progress. This milestones are targets that the team has to be hitting regularly and they must be binary like the number in the title. That means they’re either done or not, there can’t be an arbitrary percentage. They’re basically a breakdown of the bigger milestones. So if the target
Designing the architecture is the start of working on implementing in some way the requirements made earlier in the process. A good architecture will make things easier, a bad architecture will send the project to development hell or kill it. The software is mapped out through the use of design diagrams like UML and prototypes.
This part is described in a document known as the Software Architecture document, easy enough to remember. Here the system is broken into major subsystems, the interactions among them are specified and it documents the software’s top level technical plans.
Here some standards are decided. This could be error handling, memory management, string storage and other stuff. On small projects architecture and design go hand to hand, but usually it’s best if it’s treated separately.
Anyway, the phase should start when you have the requirements about 80% complete. This should give enough vision of the project to start working on it, Of course, this should only be done if the project has been approved, otherwise you’re wasting resources.
So that’s when, now let’s talk about stuff that makes a good architecture.
System overview. This means that the architecture must be able to describe the system in broad terms otherwise the devs will probably get lost.
Conceptual integrity which is making the objectives clear. It has to be clear enough for someone to think it’s obvious because there’s no other logical way to do it. Just like nowadays simplicity is your friend with UI design, it is your friend when making the architecture.
Subsystems and organization talks about having the majoor subsystems well defined and not going into every possible module. It also talks about the communication between said subsystems and this shouldn’t be happening often.
Notation must be specified. UML like I mentioned above is
As the discipline evolved we started considering more things besides “it compiles and doesn’t crash” as quality though what I mentioned is a pretty low bar to settle for. Here we’ll talk about how to ensure quality with the specifications you make of it.
The most common general definition of quality would be the the degree to which the software satisfies both stated and implied requirements. Basically how well you lived up to your promises. This is what we’ll be working so keep it in mind.
With that definition, we can see that quality matters because otherwise we won’t have the full fledged product and in the case of some reqquirements, not completing them as they should can bring upstream trouble which can end up killing the project. Even if it doesn’t kill the project, it will keep making it more expensive because the team would be building over low quality software. This is how spaghetti code is made. the spaghetti will last for a while. An example for how long it can last could be MediaMolecule with LittleBigPlanet. The code they made for a prototype is still in use up until LittleBigPlanet 3.
Giving a year between that prototype and the release of the original one which was in 2008 you’d have that the code has lasted for 7 years since LBP3 was released on 2014. So yeah, it can last quite a few years.
Ken Bauer also mentioned that his code from 10-15 years ago (I think) is still in use.
The QA plan
The organization must commit to survival and if that’s going to happen they must commit to QA, which involves:
software QA activities must be planned
The plan for the software QA activities must be written
The activities must begin during the requirement activities or