Click on the image for source

We have reached the final of the semester, without doubt this class has been really interesting since it is difficult from all my classes. I really enjoyed that there where no exams instead the reflections made me actually understand the subject, some of us have scholarships and in order to keep them we must achieve an actual grade, to get it some times or must of the times we just memorize everything for an exam and in the next day we just totally forgot about what we studied, but in this course in order to make the proper reflections I really needed to take my time to read and deeply understand the topic before I wrote about it, so I feel that I learned a lot in the class.

As the previous reflections, I am going to talk about what we saw last and if you want to take a look to the previous reflections, you know what to do…just click the buttons

As usual I am going to star with the final topics, also I am going to talk about my final project and a link to the work in case you want to look at it.


Click on image for source

Agile and OO are intimately connected, and good OO structure is essential if you want true agility

The principles of object-oriented address the need to minimize the complexity and impact of change by minimizing dependencies through the use of classes, interfaces, and packages.

In an Agile world, following OO gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.

Again you don’t have to use OO in order to use Extreme Programming, but in the end you will have a code that implements something really similar to OO

And as an example, Extreme Programming (XP) is a process of Agile Development

The concepts of Extreme Programming:

  • Planning
  • Managing
  • Designing
  • Coding
  • Testing.

Basically as I said you need both to achieve a good code. But that doesn’t mean that is mandatory.

Recently I had a rare experience I have been coding for 3 year know and my teachers had insisted on OO programming, so as I wrote this topic I realized that I couldn’t image a code that wasn’t OO. As I worked with a friend who is not studying programming we just saw it a few year ago. It was hard for me to understand his code, I thought there was something wrong with me, after seeing the code for about two hours I realized that it was no OO that was why my head was about to explode. I was interesting to write the code as not OO, we did a great job and we got A+ on that work, but it was weird for me.

If you want to learn more…click on the button


Click on image for source

Test-driven development (TDD) is a software development process, it relies on testes that has constant repetitions, here the requirements become tests and the software must past this test, once it is done, you can develop another test for another requirement and so on.

With Test-driven development a developer would first write a single test, that tests a task or requirement for a piece of software. And only after the test is created, the code is written that actually performs the task that the test requires the software to do.

Every test should test a single task that the code is supposed to do.

Following steps define how to perform TDD test:

  1. Add a test.
  2. Run all tests and see if any new test fails.
  3. Write some code.
  4. Run tests and Refactor code.
  5. Repeat.

In my opinion if you finish your code, you compile it and you don’t have errors…you are wrong, I don’t know where or what, but you are wrong.

It is pretty useful to write test and try to do it by parts, I mean some people like that they write all the code at once and once they are finished (or they believe so ) then they start to test it and they get a 100000 of errors and they spend months trying to correct them.

If you are once of those, once in your life you need to try to write some functionality of your code, and then test it, once all the errors are corrected then you continue, believe me you are going to finish your code faster.

If you want to learn more…just click the button


Click on image for source

Every code once finish it must be tested to ensure that you cover what your client needs or wants, if it covers some standards, if it is optimized and so on.

Testing is a continuous activity during software development, meaning that you don’t have to wait till the end or once your code is completely finished to star doing testing, you should do it by testing some parts of your project in determined time and not once is completely done.

There are different types of testing, and which one you are going to use it will depend on the type of program and the requirements of your client.

UNIT TESTING -> The individual classes are tested and is the responsibility of the application engineer who implements the structure.

SUBSYSTEM TESTING -> This involves testing a particular module or a subsystem and is the responsibility of the subsystem lead.

SYSTEM TESTING -> Involves testing the system as a whole and is the responsibility of the quality-assurance team.

In an object-oriented system, all data is represented in objects, as it names says. Each object contains data as well as information about the executable file needed to interpret that data, and depending of your systems it can even contain its own data structure. An object-oriented system allows the user to focus completely on tasks rather than tools, since the tools are already involved in the object.

OO program should be tested at different levels to uncover all the errors. Obviously even if you are not doing OO you should test your program. I believe that there are some tested that can be apply in a general form, meaning that you could use some test designed for OO in a not OO program but in the other way (from a non OO to a OO) I am not sure.

So in my opinion yes the testing is different from a OO program, since it is structured differently form other programs then the testing needs to be oriented towards it.

And even if you are doing a HELLO WORLD kind of code you always need to test it, maybe not because it is necessary but in order to make sure that you are turning in something of great quality and that will make a total difference from the rest of the other codes.

If you want to learn more just click the button.


Click on image for source

VALIDATION is the process of checking whether the software product is up to the mark or in other words product has the right specifications from our customers.

Or in some The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements.

It’s objective is to ensure that the product actually meets the user’s needs and that the specifications were correct in the first place.

In the other hand VERIFICATION is the process of checking that a software achieves its goal without any bugs. The last part the part of ANY BUGS is the most important, that is the main difference between verification and validation.

Here is were you ensure that you are doing the right code without any bugs.

To ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements without any errors.

Both things are tested in a software review since they are as important as the code itself, while you are testing you are validating and doing verification of the code, just you are not aware, is better if you take into account these terms before you do your testing

If you want to learn more just click the button


Click on image for source

Code Review is a systematic examination, which can find and remove the vulnerabilities in the code such as memory leaks and buffer overflows. Also to find all the errors of your code and well fix them. Even if you follow all the steps we have already discussed in the past weeks you cannot dutch the probability of errors, you can make this probability less but…you can still have something.

This process consists on several activities in which one or more people check a program mainly by viewing and reading parts of its source code you can run in all since the beginning or run it by parts.

I prefer to run the code by parts since the begin because if I run it all and it turns out to have 20 errors I totally freak out and get stress, so I prefer to run the code by parts.

If you are checking the quality of the code it is better if at least one of the persons that are going to review the code must not be the code’s author.

Code review practices fall into three main categories: pair programming, formal code review and lightweight code review.

Just to recap the testing is part of the code review, also the validation and the verification are part of the code review, if you did a great job while doing the code and the agile process then this part shouldn’t be as stressful as usually but even if you do a wonderful part you are going to see yourself in these process how hard is going to be it will totally depend on you.

If you want to learn more just click on the button


Image created by Nicole Carrillo

During the realization of the project I understood the importance of the proper design, since we are on a class that is about that we made a terrible mistake that made us repeat a relative big amount of work, something that if we had made a better design we could have avoid it.

If you want to see the complete documentation just click the button

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s