Code revision

--Originally published at Hackerman's house

Code review (also called peer review) is a software quality assurance activity in which one or more developers check a program by reviewing and reading parts of its source code. At least one of the reviewers must not be the code’s author, the purpose of this is to have another point of view, and different ideas to judge the code in a more objective way. The people performing the checking (except for the author of the code) are called reviewers.

Resultado de imagen para peer programming

The main objective of this process is to detect quality problems, although it can be used to reach more goals. Better code quality: improve the readability, maintainability and understandability. Finding defects: finding performance problems, security vulnerabilities among other flaws. There are many more goals that can be achieved through this process, but the general idea is to create better software and to avoid errors.

Types of review processes

Formal inspection

This is the traditional method of review. Software developers attend a series of meetings where the code is reviewed line by line. This method has been proven to be very effective in finding defects in the code.

Regular change-based code review

This is a more lightweight type of code review. This type uses something called Version Control, it is basically a system that records changes to a file or a set of files over the time. Github is one of the most popular applications that does this; the developers are constantly checking the changes made by every member of the team. They can see who is the responsible for the code and they can check it, but they do not dedicate the time to read it line by line.

Resultado de imagen para git


OO and Agile

--Originally published at Hackerman's house

There are lot of agile methodologies, each one has its own practices and characteristics, but in general they share the same philosophy. These ideas were expressed in the Manifesto for Agile Software Development.

Resultado de imagen para agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The origin of these methodologies arises in 1990s in a world shaped by two major influences: Object-Oriented programming replacing procedural programming as the programming paradigm favored by the industry; the other influence was the rise of the internet. This situation made that the requirements started to rapidly change and shorter product life-cycles were required; this was incompatible with the traditional methods of software development. There was a need for new methodologies that could adapt to this new world.

Extreme programming

Extreme programming is a methodology which is intended to improve software quality. It advocates frequent releases in short development cycles; it uses checkpoints at which new customer requirements may be added. Other main elements of this methodology is pair programming, extensive code review, unit testing of all the code, avoiding to develop features until they are actually needed, and one of the most important ones is constant communication between the client and the programmers to assure all the requirements are being fulfilled. The origin of the name is that traditional software engineering practices are taken to extreme levels, such as pair programming that is basically extreme code review.

Resultado de imagen para extreme programming


Test Driven Development

--Originally published at Hackerman's house

Test Driven Development is a software development process that repeats very short development cycles, the requirements are turned into specific test cases, and the software is improved in order to pass these new tests. This way all the software is proven to meet the requirements set. One of the main responsibles for this methodology is Kent Beck who rediscovered the technique.

A Test Driven Development cycle consists of a series of steps. According to the book Test-Driven Development by Example these are the steps.

Add a test

Each new feature begins writing a test. The test defines a function or the improvement of an existing function. The developer must start by fully understanding the feature and its requirements. Some of the tests can be updates of an existing test. The use of tests before starting to write code lets the developer to focus on the requirements while writing code.

Run all tests and see if the new test fails

In this step the existing code is proven to see if the new test is passed. If the existing code passes the new test it means that the test is useless or flawed. The new test should always fail because there should not be code that fulfills the requirements yet.

Resultado de imagen para tests

Write the code

The next step is to write the code to pass the test. It is not that important that the code is elegant or really well written. The most important thing is to pass the test. One thing you should consider is that the code must only fulfill the test and not add more functionality beyond that.

Run tests

If all test cases now pass, then the new code meets the test requirements and doesn’t break any existing features.

Refactor code

The last step in the cycle is to

Resultado de imagen para code
Continue reading "Test Driven Development"

Verification and validation

--Originally published at Hackerman's house

These are two different processes utilized to test if the software we are producing satisfies certain characteristics. Both are directly related with what the client wants to build. Let’s see the differences between them and why both or them are important in the process of building great software.


Verification is the process of evaluating work-products of a development phase, this doesn’t evaluate the final product. The evaluation done decides if the software satisfies the specified requirements of that phase.

Are we building the product right?

Verification is done trough reviews, walkthroughs and inspections. These check if the software satisfies each of the requirements it should.

Resultado de imagen para verify


Validation is the process of evaluating software at the end of the development process to determine if it satisfies specified business requirements. It basically evaluates if the software does what the client needs, it is directly related to the specifications done at the beginning of the project, if these were wrong in the first place then the software won’t be validated.

Are we building the right product?

There are two ways to perform software validation, internal and external. In the internal way it is assumed that the goals of the stakeholders were correctly understood, and if the software meets the requirement specification then it is internally validated. External validation happens when you ask the stakeholders if the software meets their needs.

Resultado de imagen para validation


Classes to code

--Originally published at Hackerman's house

If you have read my blog up until now, you should know the basics about software design, and specifically about the use of UML in this area. Let’s see how to take advantage of all the analysis and design we have done. The class design that we already know how to do can be converted into code that will be the actual implementation of the system.

Resultado de imagen para class diagram

The quality of the diagrams used has a direct implication on how to translate it into code. Diagram classes are object oriented, so it may be convenient for you to convert these diagrams into a object oriented language; this will allow you to keep the identity and functionality of the system you design; if you consider that using a non-object oriented language is more appropriate in your own case feel free to do so.

It is important for you to have a profound understanding of your system and your diagrams before starting to code. You will be able to see that the class diagrams offer you a lot of information to that you can take advantage of; the first example is the attributes you will need to initialize in your code. The method’s name gives you a basic understanding of what you have to program. Even the inheritance is specified within the diagrams, all you have to do is implement all the design you already have. Just take your time and select a language you are familiarized with.

Resultado de imagen para coding

As we can see, the hard part is already done when the analysis and design is finished. The implementation is just a translation of what we already know about the system.

Classes to tables

--Originally published at Hackerman's house

When you have to map objects to relational databases, the place where you have to start is with the data attributes of the class. It is important to define in how many columns these attributes will be mapped, it can be from zero columns to many more. Not all attributes are persistent, this means that they are used for some temporal calculation in the application, this has a direct impact in the way the database is designed because it’s possible that this attribute is not necessary in your database. In the case that an attribute is an object in their own, the attribute will map into several columns in the database.

The easiest mapping is when each attribute goes into a single column. In this case the class model and the physical data model can be very similar; the main differences will be that the data model needs at least one primary key, and in case there are more classes interrelated you need to add the foreign keys for the occasion.


Inheritance is a big deal when mapping a class into a table. The issue is figuring out how to organize the inherited attributes in your model. There are three fundamental solutions for this.

This class hierarchy will be modified using the three approaches.

Figure 1. A UML class diagram of a simple class hierarchy

Using one data entity for an entire class hierarchy.

This means that you will map an entire class hierarchy into just one data entity that contains all the attributes of all the class in the hierarchy. It is important to add the primary key to the data entity. The advantage of this approach is that you have all the information available in just one table; this supports polymorphism in an easy way. The cons are that has a high level of coupling and an error

Figure 2. Mapping the class hierarchy to one single data entity.
Figure 3. Mapping each concrete class to a single data entity.
Figure 4. Mapping each class to its own data entity.
Continue reading "Classes to tables"

Modeling Languages and Tools

--Originally published at Hackerman's house

A modeling language is a graphical or textual computer language that is used to design models of new software or system.

Graphical modeling

Graphical modeling languages use diagrams, symbols and arrows to represent relations, real life concepts or even steps.

The most popular is the Unified Modeling Language (UML) this is also the most popular modeling language in general. Thanks to its popularity there is a lot of software that supports this language.

Another one is the flowchart, is a diagram used to represent an algorithm, workflow or process.

Both of these languages are supported by 

Textual modeling

The textual modeling languages are formalized natural languages. TMLs have the ability to describe whole software. The language has to be readable, this is really important because is common that the programmer needs feedback from the user, the model needs to be easy to understand. It is also important that it is unambiguous.

Some examples of these languages are, PlantUML that is an adaptation of UML into a text only format. TextUML does not suppose the user knos UML concepts, it requieres a large amount of information about classes and relations. Umple is model-oriented programming, it is integrated in Eclipse IDE.


Photo by Chris Campbell


Martin, M; Macek, O (2012) On General-purpose Textual Modeling Languages, recovered from:

Use Cases

--Originally published at Hackerman's house

Use cases is a methodology used to identify, clarify and organize system requirements. Use cases describe the step by step process a user goes to complete a goal using a software system, each use case has an specific goal and it has to consider the things that can go wrong, creating this way not only one path for the user but many paths.

Main characteristics of a use case:

  • Organizes functional requirements
  • Models the goal of the user
  • One main flow of events, and other possible ones (alternate courses of action)
  • Multi-level, this means one use case can use the functionality of another one

21 Steps to Success

Photo by Bernard Goldbach

How to write a use case

You need to have a clear actor, and describe the scope of the use case.

Describe the set of steps the actors take to accomplish the goal of the use case. In case there are alternate flows you have to describe it as well. There is another type of flow, exception flows are the things that prevent the user from achieving their goal, this steps should also be in the use case. The alternate and exception flows must be marked as not part of the main path.
Path less travelled

Photo by Kate Rusell


Brandenburg, L (2018) How to write a use case. Bridging the gap. Retrieved from:

Unified Software Process

--Originally published at Hackerman's house

The Unified Process is a iterative and incremental software development framework, from which a customized process can be defined. The most popular variation is the Rational Unified Process (RUP), there are others like the Open Unified Process (OpenUP).

There are some key characteristics in the Unified Process;

  • Iterative and incremental development framework
  • Architecture-centric
  • Risk focused
  • Highest risk factors should be adressed as early as possible
  • Use case and UML driven

Each cycle is broken into four different phases, this can have multiple iterations within the phase.

Inception Phase

In this phase you have to establish the goals of the project. The core requirements and features are defined here, as well as the main risks. This phase also includes the initial project plan and early use cases.

Photo by Mike Cohen

Elaboration Phase

The architecture foundation of the system is established. In this part is taken a more detailed analisys and planning. The architecture must consider the most important requirements and risks.

Construction Phase

This is the phase where the software is built, integrated and tested. The user manuals are created and details of the software are ready to be provided to the user.
Day 2 | "The Claw" | 20 December 2007

Photo by Dan Simpson

Transition Phase

Is where the software is deployed to end users, it has a beta testing stage to ensure the software is ready for the user, retroalimentation from the user is really important in this phase.


David Olson (2014) Unified Process, recovered from:

Life cycle

--Originally published at Hackerman's house

The Software Development Lyfe Cycle is a sequence of stages to develop a software product. Some of these stages are:

  • Planning
  • Analysis
  • Design
  • Building
  • Testing
  • Deployment
  • Maintenance

A diagram of the SDLC life cycle.

The main point of Life Cycle is to detect errors in software creation before they are discovered later in the development of the project, this way you can save time and money, this also can improve the quality of the software.

There are many different lifecycle methodologies with different approaches.


The agile model is relatively new, but in the present is one of the main methodologies used by many software organizations. The agile model is used to satisfy the rapidly changing demands of the clients, being flexible and delivering faster. The projects are divided into short manageable segments, with shorter deadlines and more basic requirements, each segment follows the basic stages managed in short sprints.

Resultado de imagen para agile lifecycle


The waterfall model is the oldest of the methodologies, it is very straightforward, you have a sequence of stages, when you finish one you move on to the next one, you don’t go back and every stage relies on what has been done before. This model is very rigid, which is why it has many cons, an early delay can carry huge loses, and the problems can’t be fixed until you get to the maintenance stage, this can be very expensive as one problem may have caused others in the way.

Other examples of SDLC methodologies

  • Lean
  • Spiral
  • Iterative
  • DevOps


Arkasoftwares (w.d) Agile model software development lifecycle, Recovered from

Robert Half (2017) 6 basic sdlc methodologies: Which one is best?, Recovered from