All those things College Have Done

--Originally published at Project Management & Evaluation Cave

giphy-3

Let’s forget about the McConell Book just for this post, Imagine coming back to your school 15 years after you graduated to give a chat to students that are studying the same career as you, imagine returning to your school in 2031, what will it change? Maybe there will be VR classes and a lot of screens everywhere, google may own us all and we may even have full holograms like Star Wars to communicate, you will see things very different, but the most different thing that you’ll see, will be what your school did for you. All those years that made what you are now, all those filler classes and subjects like financial administration and citizenship that did not make any sense, there is no filler classes, like Steve Jobs says (I know he is kinda over quoted but he have a great point) it is all about connecting the dots! We are not machines, we are not code manufactures, everything that we learn is useful, I mean, as a System Engineer, you can fit everywhere, any place that there is a computer,  a job is waiting for you (if you have what it is needed), but we need to learn to take advantage of all what we learn.

Working and studying is the pillar of success, but it is a double knife trap too, we need to have a balance between the amount of work without losing the focus in our studies, work will teach you more than any class of course, but do not let greed for money consume you, studies are still important.

giphy-2

Sometimes we live in the basic, not by choice, but because we have to develop in the most common tools, since they’re easy to use for the user, we have to adapt to our clients (without trying to innovate in what we can), and

Continue reading "All those things College Have Done"

Software Project Survival Guide chapters 10-11

--Originally published at Jose Ramon Romano

Chapter 10

In this school period im also cursing a class about software architecture and if there is something i have learnt is that the architecture can always improve, i think that completing a software architecture is one of the hardest partas about the software, you can always refactor, people always find a way to improve the software and that depends only on the creativity and the open mind people has, when you think you software is ready someone can always come and improve it, maybe he isn’t better than you but i really think everything can improve, nothing is perfect, we just try to get closer to it, and the closest we get the better it is.

Resultado de imagen para software architecture icon

This is the reason why I liked the part of the book that talks about how to tell when architecture is complete, because the books says what i think, the architecture will never be perfect, what you have to do is to ask your architecture team if they are willinf to consider their architecture “frozen”, you can always continue it but at that point you can start the project.

 

Chapter 11

I like a lot that this chapter talks about estimations I find it pretty hard to make an estimation of my time, now imagine an estimation of a teams time, creating schedules and all those sort of things, the book says that for you to have a better estimation is if you have completed some projects before you could use that as a baseline to make your estimations, but to be honest ¿What about the first project you have to do? or the second one? or if you have a completly different project? I obviosly agree that if you have done something before you can always be more accurate but

Resultado de imagen para Time
Continue reading "Software Project Survival Guide chapters 10-11"

Surviving at the Software Industry (11) – Let’s Go To Paradise Falls!

--Originally published at ISC de día, intento de cinéfilo de noche.


We are on the last stage of preparation of our project! Isn't that exciting? I think it is. We just have to make our last preparations so we can roll. We will be talking about a movie that is none other than the second animated movie nominated for Best Picture in all history: Up. 

Carl and Ellie wanted to travel to Paradise falls to meet their hero. From the moment they got married, they had a can where they put all the extra money they had every day. When Ellie was a kid, she had planned how the travel would have been and she added some pictures and stamps to her book so she wouldn't forget anything. Of course, life happened and they had to postpone their trip for ever. 


I'm gonna skip the saddest part of the movie by talking about our last stage. As of right now we just have to estimate. We have to calculate how much time are we gonna take on every stage, our milestones the costs, everything. We already have everything planned and this is adding like a cherry to our milkshake. Everything has to look great on paper. I remember Ken told us once on our TI2011 course that if we wanted to estimate right we had to multiply our first estimate by two and then work on the next time unit. So if we would be taking 3 weeks on the project, we would actually be working on it 6 months. Crazy, right? Maybe just as crazy as making a house flying with balloons.


We also have to consider that we can't just escape on a flying property of the real work. We have to take in consideration other factors such as marketers, tendencies and sudden / unexpected changes. The
Continue reading "Surviving at the Software Industry (11) – Let’s Go To Paradise Falls!"

Software Project Survival Guide chapters 8-9

--Originally published at Jose Ramon Romano

This two chapters talk about things that have been very present in myself when we are talking about creating a project, this two chapters mainly discuss requirements development and the quality, I think that one depends on the other one, I think it will be pretty hard to have a quality project without a requirements development, maybe someone can do it or has achieved it but I’m pretty sure that if someone tries to do the same thing plus a good requirement development it will be better.

A big problem I found with this two chapters is that they teach you how to do things, how to think and I dont have to much to talk about, i can tell you that if you want to learn more about this two chapters go and read the book, in here im just going to point at some things I found interesting, but besides that you should read them to learn a bit more.

Chapter 8

Something I liked a lot about chapter 8 is when it talks about the usage of paper storyboards, I personally think this is a great idea because you can make your end user participate in the design and he can be watching while you change, you can do a brainstorming instead of hearing those guys, going back to your office, do the design, take it back to them, no, in this way you can have a real interaction with your client and you can start to develop those Soft Skills we have been told that are cool and also you are increasing the quality of your software because the client will be recieving something he liked a lot.

Resultado de imagen para web design in paper

Chapter 9

About the chapter 9 it talks about quality, and i think this is the most important

Resultado de imagen para mouth to mouth marketing
Continue reading "Software Project Survival Guide chapters 8-9"

Planning before planing, for real (includes chapter 7 Software Project | Survival Guide)

--Originally published at Alfonso reviews…

I’ve stated many times that planning is something importaant, but, how soon shall we start planning? the answer is simple, as soon as you can, from the beginning, even before getting your project requirements you can plan something.

You should define the vision of your project, set a clear objective and set a mission that challenges the team. All this is purely motivational, a motivated team works better, but don’t set the scope too high, if it’s nearly impossible instead of motivating it’ll demotivate. And state clearly what is part of the project and what is not, unnecessary stuff will slow down any project and will lead to a higher budget.

In order to keep that last point well, you’ll need an executive sponsor, he is the one that  will be reviewing the project, its features, and the one making decisions about what should continue and what must be stopped.

With a good executive sponsor you will be able to set targets for the project scope, remember, what matters most on a software project is to deliver, so adjust features to budgets or budgets to features if necessary, but deliver in time.

A part of planning is taking into account risks, for sure you can’t consider all of the possible risks that may appear, but you can handle some of them, and there is no need to expose a project to unnecessary risks. Plan to avoid as many risks as you can, the earlier a risk is detected, the better, as you can select a better approach.

Long story short, you shoul set objectives, get someone to review that those objectives are being followed, remove as many risks as you can, and get a good team, so the work can goo smoothly.


Can we already start the project?

--Originally published at #ti2011 – Project Administration and Evaluation

I know how you feel believe me, “11 chapters and we still don’t code anything? OMG I’m going to die, I can’t handle this book anymore. Why Ken? Why you make me do this?”, (slap to the face) enough of that, be strong and don’t exagerate we are almost there and this stufff is really useful.

Resultado de imagen para memes coding

Okay, now that we got that stuff out of the way, we can start to talk about the chapter. One thing that I didn’t like about the chapter it’s that it compressed vital informarion in one chapter, I would’ve preferred it treated the estimations and the staged delivery plan in separate chapters. But anyway, for me the estimations is the worst thing you can ask me about because I don’t take in consideration a lot of things, hell I’m that bad that I can estimate my times for some homeworks, but well, I will the the book’s word that estimation is try and error. One thing I also do that the book says is a bad idea is estimations with over time, I’m always like: “Well I know I can finish this If I wirk until 4:00 am and continue at 7:00 am” which is really bad.

Resultado de imagen para memes estimatios

Now, for the part of stage delivery, I really use this approach for everything because it helps arrange stuff of the project and give it relevance or priority over other things, I agree with the book that you can define the whole project with this, but that doesn’t mean it can’t help.

The last part of this chapter talks about revisiting plans and important points like the vision, risk management, etc., beacuse all of that can change with the estimations. In the end, the chapter, for me, wasn’t that good because it compresses important information

Continue reading "Can we already start the project?"

Regresión lineal

--Originally published at conzmr.wordpress.com

En quince casas de la ciudad se observó durante un período de tiempo la diferencia de temperatura promedio (en grados centígrados) entre la temperatura en la calle y la temperatura en casa, y el consumo de electricidad diario en kWh.

Graficas de datos

temp_diff_vs_kWh

Podemos percibir que entre más sube la diferencia de temperatura entre la casa y la calle
suele haber más consumo de energía eléctrica.

Aplique regresión lineal y obtenga la función lineal que se ajusta a estas mediciones.

corriendo el siguiente código con los datos proporcionados obtenemos los resuldatos de a1 = 3.39553 a0 = 37.1618, lo que quiere decir que el y = 37.1618 + 3.39553 * x es un modelo lineal que se ajusta apropiadamente a estos datos.

#include 
#include 
#include 

using namespace std;

double *linear_regression(unsigned n, string x_file, string y_file) {
  double s_x, s_y, s_x2, s_p, mu_x, mu_y, std_x, std_y, std_xy, a0, a1;

  double *xs = (double *) calloc(n, sizeof(double));
  double *ys = (double *) calloc(n, sizeof(double));

  ifstream x_stream(x_file);
  ifstream y_stream(y_file);

  cout << "X" << "\t" << "y" << endl;
  cout << "----" << "\t" << "----" << endl;
  for (size_t i = 0; x_stream && y_stream && i < n; i++) {     double x, y;     x_stream >> x;
    y_stream >> y;

    xs[i] = x;
    ys[i] = y;

    s_x += x;
    s_y += y;
    s_x2 += x * x;
    s_p += x * y;

    cout << x << "\t" << y << endl;
  }

  x_stream.close();
  y_stream.close();

  mu_x = s_x / n;
  mu_y = s_y / n;

  for (size_t i = 0; i < n; i++) {
    std_x += pow(xs[i] - mu_x, 2);
    std_y += pow(ys[i] - mu_y, 2);
    std_xy += (xs[i] - mu_x) * (ys[i] - mu_y);
  }

  // standard deviation
  std_x = sqrt(std_x/n);
  std_x = sqrt(std_y/n);
  std_xy /= 
correlacion
linear_regression_plot
Continue reading "Regresión lineal"

The puzzle.

--Originally published at Rudy&#039;s Corner

Now that all the preparations are ready, it’s time to jump at the stages. At the start of each staged delivery cycle there needs to be a plan, a map of the detailed course of action that will be followed through that cycle only. Imagine breaking the big project into miniature projects, doing that, it can be easier to actually complete the project in a well manner.

Don’t think that because those are mini project, the Software Development Plan just gets abandoned. It’s the complete opposite, the SDP helps guiding all the mini projects through the craziness, that way each mini project will achieve its purpose and when everyone is finished we have a complete project. Imagine it like this, you’re creating a puzzle. The SDP is the picture you’re creating, for example a bridge. Then we have 9 teams, each one of them will make one of the nine parts that are the puzzle. So you have the global guideline, being the picture, and the mini projects, each part of the puzzle. Here the tricky part is when everyone finishes their parts need to match. I am sure that everyone has solved a puzzle before, so just picture yourself trying to put the puzzle together and realizing that the parts don’t match, there’s chaos, the puzzle doesn’t work. With software projects it’s the same thing, that’s why it’s very important to follow the SDP when making the plan for the individual stage cycles.

The stage planning consists of, and putting it on the example of a part of the puzzle:

  • Requirements updates: my part is the top left corner of the picture.
  • Detailed design: it will have this color, this space will be left open, and so on.
  • Construction: the actual creation of the part.
  • Test case creation: how it looks,
    puzzle-23135590
    Continue reading "The puzzle."

Project quality and architecture.

--Originally published at #ti2011 – Project Administration and Evaluation

The chapter about quality was really cool, the other one I didn’t like it that much but made me realize that I’m usually the one focus on defining the project’s architecture.

First, I really hate to talk about the quality of a software because it really is a delicate topic, even the book has trouble defining what “quality” means. Also, I really hate that people who doesn’t know about software thinks that you can do software without errors and really fast and that, if you don’t do any of those two things, the software is trash. I know it’s important, but that doesn’t make it less painful.

Resultado de imagen para memes software quality

Okay enough rant, the chapter was good and I enjoyed the importance it gives on how to deal with quality. All the tools like the tests for every important aspect of the software, quality assurance plans, reviews from the users, defects tracking, etc. I have used some of this tools in school’s projects and in “Taller Vertical”, and believe me, they are really useful and sometimes, at least for me, I didn’t even notice that I was using them.

The thing the book says about the betas, I think is really pesimistic. I mean, in projects like videogames or other systems, the betas are really good because of the amount of feedback, yeah you need the users to be really compromise on giving good feedback, but that doesn’t mean betas are bad or a waste of time, it’s just that they are really good in specific scenarios.

 


The end is coming.

--Originally published at Rudy&#039;s Corner

The final preparations are around the corner, in this period you should build and extend the preliminary planning. Now that you actually know the requirements, and the architecture is underway you can change some things that planned earlier, remember, it is always better to make changes upstream, that it is doing them downstream.

In this final part of the preparations, the estimations are set. The funny thing about estimations is that no one knows how to. One time a project manager told us how she does things when a programmer gives an estimation on how long he/she will take with a certain thing. She said: “I take the estimation, multiply it by 2 and bump it to the next unit”. For example if someone tells you that it would take 2 days, you should expect: 2*2, that gives 4 days, bumping it up gives 4 weeks. So that would be what the time it would really take that person to finish it. I know, it sound weird, but I mean, are you good giving an estimation? Using that method at least you’ll give yourself some wiggling room.

Another fundamental thing about preparations is NEVER assuming, anything. Like, at all. I mean you shouldn’t assume anything about anyone (assumptions are biases that will just make you judge a book by its cover), but on the topic of assuming on a project it’s also a no-go. We are very bad at guessing, just think of the problems that have been created because an assumption is made. Just go and ask, it won’t cost anything, and it will definitely save you a lot of problems down the road.

Along with the estimations, there has to be a stage delivery plane. In order to do this properly, imagine this. A client gives you a

4f30cbe54d4c9c24d31bff4a4a9fcd21.jpg
if2080_l_22.png
e100_prod_rd-400x470.jpg
Bicicleta-bueno-salud.jpg
carros-screen2.png
good-lesson.png
Continue reading "The end is coming."