Final Delivery

Final Delivery

What did you learn about the process of design in this course/project?

Besides learning many types of design patterns and models, new techniques were discovered throughout the process of this project. The design of use cases was something that we had done before, but with these practices we discovered new ways to express use cases and other patterns like class diagrams. When doing research about different types of diagrams we discovered some of them to be very useful like the components diagrams.

Mapping classes and tables became key important to the development of the project and design of it because of how powerful it can be if used correctly. With the class tables we discovered new relations between objects and tables that we hadn’t seen before, that is why this step was important and effective.

We learned a lot about use cases, requirements and a lots of things that’s reflect the real life of a Software Engineer. It’s not the same that in a project school we hare the client, the user and the company because maybe all this thing we use to make it easy that’s we liked this project a lot.

OO and Agile

One of the most difficult tasks in software development is to put all the pieces together, because sometimes you aren’t working alone, and each programmer has a different style of programming. Thus, it could be a problem if you don’t know what to do with all the parts of the software.

So there’s why know we have a lot of methodologies to work with examples like, Agile, Jira, Scrum etc… So let me share this video about agile.

Until this moment the problem is solved, and the solution is implemented in code. Before continuing remember the principles of OOA

  1. The software does what the customer wants it to do.
  2. The principles of OO are well applied.
  3. Strive for a maintainable and reusable design.

Let’s review the process to build good software.

First you need to understand what the software is supposed to do. (Use cases diagrams are a good option here).

Be sure that you include all the system is going to need to work correctly in the use cases. The nouns are the classes and the verbs the methods. Avoid the features that doesn’t have a close impact to the solution (include only the features that are needed or that one’s specified in the requirements).

Then break up he problem into smaller pieces. Once you have the use cases diagrams this is going to be easy. Because that is one of the purposes of the use cases.

Before continuing in the process be sure that the team understand the problem and its components.

Now is time to get the requirements of the system, modify the use cases and the requirements list as you need. Is important in this step to gather the correct requirements, the code is not done yet and is better to add or remove things at this time. Making a good analysis and design is one way to know that your requirements are well covered.

Before starting to implement the solution of the design think about possible situations that you aren’t including now, this will make easy the work then.

At this point is time to start to implement the solution by coding and coding. Remember all the principles to assure flexibility in the code.

Finally, is the testing part and before this part I am almost sure that a problem come, if not congratulations you learned very well the concepts. If something goes wrong with the system you should get back to the requirements step and change the things that need to be changed. And continue with the cycle. If another problem is presented repeat the process until the system work well.


  • Brett D. McLaughlin, Gary Pollice, and David West. (2007). Head First Object-Oriented Analysis and Design. United States of America: O’Reilly Media.

Test Driven Development

A lot of methodologies are used in software development but one of that I really use in my work and sometimes in the school is the Test Driven development, and one great thing that this semester happened to my is met to Kent Beck the creator of this test. So let me pass some of my knowledge to you with this blog.

This process consist of the repetition of a short development cycle where requirements are turned into specific test cases then the software is able to pass to the other iteration.

So first, like all my blogs let me recommends a video that will help you to understand more about this.

There are 5 steps on each iteration and are:

  1. Add a test – Each component of the system is a test. The test describes the function or improvements of a function. The test needs to be clear and understandable.
  2. Run the test – In this step you prove the code of the test to see if works correctly, if it doesn’t work as it should be edit the necessary code.
  3. Write more code – The next step is to write some code that causes the test to be accepted.
  4. Run again – If all the pest pass the new code accomplish the requirements proposed in the beginning .
  5. Refactor code – This part is to purify the existing code by removing the necessary code or adding new more code that is needed for the system.

Then the process is repeated until the system is done.

the benefits of this process are that the programmers are more efficient and more scenarios of failure are considered.

Some limitations are that this process is low for big systems because the necessity of create lots of test takes a lot of time, but it guarantee a system more robust.


Testing in OO

One of today’s topic is object-oriented testing. Testing OO is a group of techniques to verify and validate object-oriented software.

Testing is one of the last steps of the software development cycle. Then, in each system it should be accurate to solve all the possible mistakes made.

This part is very important because you can see at any level of the system if it works as it should do.

When you have big systems always is a hard task to test all the parts. But there is a concept where you divide the system and analyze the components. This way is more retrievable because it guarantee that the part is good.

There are some techniques to evaluate the components of a system but again sorry but I’m really like a visual person so videos help me a lot, so check out this video first

Method Testing: Each individual method of the OO software has to be tested by the programmer.

Class Testing: Class testing is performed on the smallest testable unit in the encapsulated class. Each operation as part of a class hierarchy has to be tested because its class hierarchy defines its context of use.

Integration testing can be applied in three different incremental strategies: Thread-based testing, which integrates classes required to respond to one input or event. Use-based testing, which integrates classes required by one use case. Cluster testing, which integrates classes required to demonstrate one collaboration.

System Testing: All rules and methods of traditional systems testing are also applicable to object-oriented systems.

Regression Testing: Regression testing is performed similar to traditional systems to make sure previous functionality still works after new functionality is added.

Vats, Prashant. (2002). Object Oriented Testing Techniques: Survey and Challenges. ,Int.J.Computer Technology & Applications. 3. 746.

In the majority of the cases inheritance, polymorphism and encapsulation are the areas where could be more problems.

If you are in the testing step be careful to analyse correctly the system to cover all the possible troubles.


Vats, Prashant. (2002). Object Oriented Testing Techniques: Survey and Challenges. ,Int.J.Computer Technology & Applications. 3. 746.

Verification and Validation

Today I am going to talk about two concepts that sound very similar but are totally different.

Every single project involves a series of methodologies that result in the solution for problem. I talked on past post about the process of developing software and I include some advises that can be helpful to you.

Also I talked about the different types of projects that can result in a problem, today’s topic can be applied to all kind of projects and also to all methodologies and standards like ISO 9000 that apply in a lot of engineers.

Before to start talking about this topic maybe you want to check this video it’s really short but efficiently.


When you are talking about validation you can start with this question

Is the right product?

Validation is the process of evaluating software to determine whether it satisfies the business requirements.

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


Also in verification there is a question that can be fundamental to know what is be doing.

Is the current product right?

Verification is the process of evaluating the products of a development phase to determine whether they meet the specified requirements for that phase.

The objective is to ensure that the product is being built according to the requirements and design specifications. .

Now we can notice that two concepts can sound be similar but are different, in the questions that I proposed the only difference is the position of one word and that is very interesting to me because the position of that word change the signification of the sentence and the concept.


Verification vs Validation

Code Revision

Sometimes we only take a look to the problem or to the system and we want to start programming right away, so we have a lot of problems later programming and debugging our code because we do not have like a process to review our code to the right way so this blog it’s about that and how to do a perfect Code Revision.

But first let me share a long video like an 1 hour but it’s really useful

One of the stages of the software development process is to review the code. For this stage there are so many techniques that can be useful to achieve that task. But you should consider the complexity of the system to select the best practice or the correct technique.

This time I will give you a general way to review the code done.

This technique involves 4 steps and 6 roles.


  1. Preparation – you determine inspection/review targets and the roles for each participant. Reading techniques should also be specified at this stage.
  2. Inspection – each inspector looks for defects according to their assigned role and perspective. In this stage, compiler warnings, static analysis tools, review tools, and defect tracking tools are put to use. These tools organize defects for the Rework stage
  3. Rework – is when reviewers go back and fix defects.
  4. Follow-up – where corrections are verified and reviewers make sure that new bugs haven’t been introduced. Defect tracking and review tools are used here too.


  1. Inspector: their goal is to detect and identify defects.
  2. Moderator: is responsible for leading the review group and keeping them focused on their goals. Moderators set up the environment and regulate the discussion and the time to keep reviews focused.
  3. Recorder: is responsible for documenting the issues that developers find.
  4. Author: the author is a developer who wrote the code being inspected. It is their responsibility to correct the defects once they are found.
  5. Organizer: the organizer develops a plan for development and review. They determine the time schedule for the inspection.
  6. Reader: explains the product being inspected/reviewed on behalf of the author.

The reading techniques are formed of simple questions that respond to the performance of the elements of the system.

Some IDE have different tools to track and analyse code. Depending of the platform you used to develop the system you should select one.

For more information check this links

Project Delivery 2

Really about this project, we take so serious and we try to do a lot of things but in this partial was a little difficult because we have a lot of things to do, so we have to do it simple but efficiently that is why we just answer the questions about the project, we did an interview with the head coach of the team of League of Legends and we decide to add this audio to the blog and maybe transcript the important parts on it.

so here’s the question first, later the interview and some changes that we decide to make in the use cases.

What did you learn about the project with these interviews?

At first, our idea was to have a complex web application with multiple interactions by every user that uses it. But when doing the interview we discovered that the stakeholders wanted more simple features but more complex analysis of data, so we changed the way of modeling the software into a much more easy and intuitive interactions with more complex process of data.

The regular player can check his or her stats at any time and make leagues to make small competitions between friends or other people. Those are the only interactions because for the stakeholders it is only important to have a good analysis of data so decisions can me made to recruit new representative players and to analyze the ones that are part of the team already.

From the interviews we also learnt that our focus need to be on the web application and later on the mobile app. This is because our main stakeholders which are the headhunters and administrators made very clear that the project needs to be done in a web application first so when the mobile app is done, the final clients or players will not have a problem using it and its database. Also, in that time the web application is going to be more structured and polished to be able to process big data.

Photo by Arielle Lilley

What did you learn about the process of interviewing?

Before starting the interview, we had our questions ready, and in the process of making them we tried to focus on finding out the necessity of our potential stakeholder. In the process of doing the interview we also learnt that some new questions needed to be asked based of the previous answer.

It was not that hard to understand what the stakeholder wanted because of the experience the whole team has in that area. The real challenge was to even though the stakeholder did not have a big necessity of the case, we needed to be persuasive to make the necessity real for the stakeholder.

Photo by Learn – Stock Photo

What do your use cases look like now? Did you have to remove some, change some, add some?

We removed the client stakeholder because now everyone is a player at first, with the main privileges so there was no reason to have a client stakeholder in place. We also changed the administrator to have now two more functions which are the ability to delete leagues and the permission to ban players. The term “ban” refers to block or eliminate the player, it is used for control and security. 

Design Museum, London.

If you have any work on class diagrams or database ER diagrams, include those as well.

Use cases


Classes to code

Well we have a lot of thing that can help us with this topic in previous blogs we talk about how some tools of UML will help us, but what about a new Language, when we have to convert some new to a class -> table->code this process if we think about it maybe we said that it’s really easy but let’s talk more about this.

But first after all I will let you a course that really help me to understand this kind of topic.

The activity of software development involves several participants. For example the programmer, the customer, the team leader and some others more. But In the functional part there exist a dilemma when you are going to develop an application. Which language is the appropriate for do it. Now there are so many languages that are getting popularity between the software environment.

After the firs steps of the software development cycle when you already have a solution for the problem you need to implement it. So, here is the part when you need to decide which language to use and also the paradigm.
There are different paradigms like:

  • Procedural Paradigm
  • Functional Paradigm
  • Object Oriented Paradigm (OOP)

Here I will focus on the OOP. Once you choose the paradigm then you can start thinking about the language to use. As paradigms there are different languages for this paradigm. Some of them focused in the OOP and some others are like mixtures of one or two paradigms.

In my experience taking design models to a specific language is not a difficult task because there are so many documentation of how to do it, I did that with Java and is not so hard. The main thing to take care when you are working with java as I said in past post is to have a good design to build good software.

Another option is to choose any other language as C, C++ or Python but the main idea is the same. The only thing you need to consider changing of language is the syntax of each one because the majority use a different syntax.

Photo by fossbytes

Some links to help you

Crea tu página web en
Empieza ahora