Author: carlosmartell97

UML, visual help…?

UML. Unified Modeling Language. Shortly, it’s a visual modeling language. It’s very common for business analysts, software architects and developers to use it. It helps provide guidance for team’s activities (specific developers) and can also help monitor and measure team progress!

Used software engineering in general, but more specifically in object-oriented software, it shows an application structure.
This will basically help you visualize your classes, and easily communicate to others the structure and content of a class, or indications of what these should be.

As an example, this is what an UML class diagram for some “Employee” class would look like:
Nice, huh?
  • The top rectangle contains the name of the class desired.
  • On the next rectangle we can see its instance data, its state.
  • But we also need specifications for Employee’s behavior (methods needed to access its information), and so it’s specified on the next rectangle. Here you can see a constructor method, as well as some getters. Setters are not specified, but they would also be listed in this rectangle.
  • Did you see the signs at the start of each line of these last 2 rectangles?
    • MINUS means private!
    • PLUS means public

There are 14 types of UML diagrams, though. Here’s a list of some of them:
  • class diagram
  • use case diagram
  • object diagram
  • sequence diagram
  • state machine diagram
  • activity diagram
  • package diagram

All 14 types can be classified into 2 main categories: structure diagrams and behavioral diagrams. Structure diagrams shows the different objects in a system, whereas behavioral diagrams describe how objects interact with one another…

Authors: Carlos Martell, Hermes Espinola, Jesús Alvarez, Juan Melendres & Alejandro Güereca

To take your reading one or many steps further, you can start reading through these sites, our sources for this post:

*insert clickbait title here*

Okay, so you’ve come to my blog post. You want to know about software requirements elicitation and specification? Then stay with me.


I’ve talked about software requirements before, so what’s this deal with elicitation and specification, then?


First, let me explain the elicitation process. We start by gathering the requirements through discussions with the client and end users (through interviews, surveys, etc), then we make some sort of prioritization on these (through task analysis, etc). Now that we have all this, a discussion/negotiation with the stakeholders is made (here you might want to come up with some prototype to have more valuable feedback). At any point you might realize you have to go back to a previous phase to do modifications, or repeat them entirely. Everything must be documented.


Now, software requirement specification is supposed to be this document you create ONCE the requirements have been collected. This document will have specifications on how the intended software will interact with hardware, external interfaces, response time, limitations, etc. You can imagine things get pretty technical at this point, so it’s preferred that this document is written by some sort of system analyst. You’re going to want this document to be useful for the software development team, so…


This document’s appendix would hopefully look something like:
  • user requirements in natural language
  • technical requirements in structured language
  • design description in pseudo code
  • GUI screen prints
  • conditional and mathematical notations

You definitely don’t want this to happen:


All this is meant to be valuable information upon which you’ll know what has to be accomplished. Even if done simultaneously with other phases of the project (agile) or all focus is put on this phase until it’s complete (waterfall), this phase is one you definitely don’t want to miss. Knowing what your users want and what Continue reading "*insert clickbait title here*" →

*insert clickbait title here*

Okay, so you’ve come to my blog post. You want to know about software requirements elicitation and specification? Then stay with me.


I’ve talked about software requirements before, so what’s this deal with elicitation and specification, then?


First, let me explain the elicitation process. We start by gathering the requirements through discussions with the client and end users (through interviews, surveys, etc), then we make some sort of prioritization on these (through task analysis, etc). Now that we have all this, a discussion/negotiation with the stakeholders is made (here you might want to come up with some prototype to have more valuable feedback). At any point you might realize you have to go back to a previous phase to do modifications, or repeat them entirely. Everything must be documented.


Now, software requirement specification is supposed to be this document you create ONCE the requirements have been collected. This document will have specifications on how the intended software will interact with hardware, external interfaces, response time, limitations, etc. You can imagine things get pretty technical at this point, so it’s preferred that this document is written by some sort of system analyst. You’re going to want this document to be useful for the software development team, so…


This document’s appendix would hopefully look something like:
  • user requirements in natural language
  • technical requirements in structured language
  • design description in pseudo code
  • GUI screen prints
  • conditional and mathematical notations

You definitely don’t want this to happen:


All this is meant to be valuable information upon which you’ll know what has to be accomplished. Even if done simultaneously with other phases of the project (agile) or all focus is put on this phase until it’s complete (waterfall), this phase is one you definitely don’t want to miss. Knowing what your users want and what Continue reading "*insert clickbait title here*" →

Would you drop your mouse for your eyes?

How long did it take you to click on this blog? You had to scroll your way with your mouse until you reached the clickable text, right? Or you clicked at it with your finger directly on the screen… On the other hand, how long did it take you to look at this blog’s title? Milliseconds. Yeah. That’s what I mean.


It’s now been over a decade that we’ve been using the computer mouse as a fundamental tool in our interaction with computers. It’s not the only way we point at things, though. Mobile phones, mainly thanks to the explosion the iPhone brought, have also taught us we can directly touch with our fingers on the screen. Augmented reality has also taught us to use the movement of our body, with cameras and motion detectors.


But, think about it. All these interactions I’ve mentioned need another type of interaction none of them are truly taking into account. Before you ever move your mouse, touch your screen or move your hand in the air, the first thing you do is point your eyes at that thing. What if we took approach of this very first thing everybody does? Eye-tracking technology. That’s what many predict the future holds for us all. A multimodal computer interaction.


What most of us have now in our pockets would have been considered a supercomputer 15 years ago. And the revolution’s not stopping anytime soon. “The general notion of pointing at things to navigate through a menu can be done in tens of milliseconds with you eyes versus the time it takes you to use your hands”, says Jim Magraff, CEO of Eyefluence, a company that now builds eye-tracking technology for AR and VR.
Resultado de imagen para eye tracking technology
Communication with computers should be seamless, no delays nor interruptions. An “iPhone moment” Continue reading "Would you drop your mouse for your eyes?" →

Would you drop your mouse for your eyes?

How long did it take you to click on this blog? You had to scroll your way with your mouse until you reached the clickable text, right? Or you clicked at it with your finger directly on the screen… On the other hand, how long did it take you to look at this blog’s title? Milliseconds. Yeah. That’s what I mean.


It’s now been over a decade that we’ve been using the computer mouse as a fundamental tool in our interaction with computers. It’s not the only way we point at things, though. Mobile phones, mainly thanks to the explosion the iPhone brought, have also taught us we can directly touch with our fingers on the screen. Augmented reality has also taught us to use the movement of our body, with cameras and motion detectors.


But, think about it. All these interactions I’ve mentioned need another type of interaction none of them are truly taking into account. Before you ever move your mouse, touch your screen or move your hand in the air, the first thing you do is point your eyes at that thing. What if we took approach of this very first thing everybody does? Eye-tracking technology. That’s what many predict the future holds for us all. A multimodal computer interaction.


What most of us have now in our pockets would have been considered a supercomputer 15 years ago. And the revolution’s not stopping anytime soon. “The general notion of pointing at things to navigate through a menu can be done in tens of milliseconds with you eyes versus the time it takes you to use your hands”, says Jim Magraff, CEO of Eyefluence, a company that now builds eye-tracking technology for AR and VR.
Resultado de imagen para eye tracking technology
Communication with computers should be seamless, no delays nor interruptions. An “iPhone moment” Continue reading "Would you drop your mouse for your eyes?" →

Nonfunctional is worthy, too.

Okay, so you’ve most certainly heard about requirements before. At least you’ve read about it on my blog (please? ?). And probably you don’t have the full mental image of actual requirements, because most requirements definitions only focus on functional requirements, actually.


These so called functional requirements are based on the expected functioning of the product/service. This is typically represented in features such as menus or buttons. Here is where you want to think about potential use scenarios. For most cases, though, if you fail to identify some nonfunctional requirements, you’ll have some trouble later. Trust me.
A milk container has the functional requirement of being capable to contain fluid without leaking. Of course, milk containers can also be used for other things:



Now, nonfunctional requirements are those regarding attributes such as performance levels, security, usability, reliability and availability. Here is where you you want to think about user narrative statements, acceptance criteria. When these factors are not taken into account, not even your perfectly well functional requirements will save you from some very unsatisfied resulting customers. This highly increases the chances of abandonment.


A hard hat has the non-functional requirement of not breaking under pressure of less than 10,000 PSI. Now, let me just say there are some pretty cool things you can do with hard hats:



And I don’t blame you, the fact that they’re called NONFUNCTIONAL requirements already makes you think it’s not worth of your time, as if nonfunctional meant pointless, secondary, negligible. I hope you’ve learned here otherwise. It might help to make a mental image of them more as “quality requirements”. That rings more the bell for most of us.

Functionality and quality don’t cancel each other out, in fact, they live as one in all successful software. Both functional and nonfunctional requirements are Continue reading "Nonfunctional is worthy, too." →

Nonfunctional is worthy, too.

Okay, so you’ve most certainly heard about requirements before. At least you’ve read about it on my blog (please? ?). And probably you don’t have the full mental image of actual requirements, because most requirements definitions only focus on functional requirements, actually.


These so called functional requirements are based on the expected functioning of the product/service. This is typically represented in features such as menus or buttons. Here is where you want to think about potential use scenarios. For most cases, though, if you fail to identify some nonfunctional requirements, you’ll have some trouble later. Trust me.
A milk container has the functional requirement of being capable to contain fluid without leaking. Of course, milk containers can also be used for other things:



Now, nonfunctional requirements are those regarding attributes such as performance levels, security, usability, reliability and availability. Here is where you you want to think about user narrative statements, acceptance criteria. When these factors are not taken into account, not even your perfectly well functional requirements will save you from some very unsatisfied resulting customers. This highly increases the chances of abandonment.


A hard hat has the non-functional requirement of not breaking under pressure of less than 10,000 PSI. Now, let me just say there are some pretty cool things you can do with hard hats:



And I don’t blame you, the fact that they’re called NONFUNCTIONAL requirements already makes you think it’s not worth of your time, as if nonfunctional meant pointless, secondary, negligible. I hope you’ve learned here otherwise. It might help to make a mental image of them more as “quality requirements”. That rings more the bell for most of us.

Functionality and quality don’t cancel each other out, in fact, they live as one in all successful software. Both functional and nonfunctional requirements are Continue reading "Nonfunctional is worthy, too." →

Hey, listen. Software Processes. Yeah…

You might get some idea from reading it. And you might not be too wrong. Not too much.


Officially, it’s the structured set of activities you do to develop a software system. This commonly involves the steps: specification, design and implementation, validation and evolution. Some sort of perspective of a process.
If you’re a reader of my blogs (Hi there, then!), you’ll find familiar some of the processes I’ll mention now.
There are also various different ways of executing these processes:
  • plan-driven: All activities are planned in advance. Upon the realization of these, progress is measured.
  • agile-processes: This one’s different. Cooler, in my opinion. Planning is incremental, so the process changes with respect to changing customer requirements.
  • both: Yes. In reality, most real-world practices are done with a combination of the previous two.
  • Waterfall model: Another plan-driven one. Although here, it’s typical to separate each phase of development.
  • Incremental development: This one is also a combination. Specification, development and validation are over-lapsed. It’s not necessarily agile, though. It can also be plan-driven.
  • Reuse-oriented: It’s assembled from existing components. Also, plan-driven or agile. You’re finding this weird already? Stay with me. Please :)
             Resultado de imagen para incremental development joke


You see, it’s not like there are some wrong, never-do software processes. It really all comes down to each particular case. Let’s analyze some of these in more detail.


The waterfall method consists of, mainly, 5 different phases:
  • requirements definition
  • system and software design
  • implementation and unit testing
  • integration and system testing
  • operation and maintenance
Now, don’t get too excited. This method’s most important weakness is that once the process starts, it’s very hard to go back (try going backwards in a real life waterfall!) some phases in case somethings needs to be changed. One phase must be completed
Continue reading "Hey, listen. Software Processes. Yeah…" →

Hey, listen. Software Processes. Yeah…

You might get some idea from reading it. And you might not be too wrong. Not too much.


Officially, it’s the structured set of activities you do to develop a software system. This commonly involves the steps: specification, design and implementation, validation and evolution. Some sort of perspective of a process.
If you’re a reader of my blogs (Hi there, then!), you’ll find familiar some of the processes I’ll mention now.
There are also various different ways of executing these processes:
  • plan-driven: All activities are planned in advance. Upon the realization of these, progress is measured.
  • agile-processes: This one’s different. Cooler, in my opinion. Planning is incremental, so the process changes with respect to changing customer requirements.
  • both: Yes. In reality, most real-world practices are done with a combination of the previous two.
  • Waterfall model: Another plan-driven one. Although here, it’s typical to separate each phase of development.
  • Incremental development: This one is also a combination. Specification, development and validation are over-lapsed. It’s not necessarily agile, though. It can also be plan-driven.
  • Reuse-oriented: It’s assembled from existing components. Also, plan-driven or agile. You’re finding this weird already? Stay with me. Please :)
             Resultado de imagen para incremental development joke


You see, it’s not like there are some wrong, never-do software processes. It really all comes down to each particular case. Let’s analyze some of these in more detail.


The waterfall method consists of, mainly, 5 different phases:
  • requirements definition
  • system and software design
  • implementation and unit testing
  • integration and system testing
  • operation and maintenance
Now, don’t get too excited. This method’s most important weakness is that once the process starts, it’s very hard to go back (try going backwards in a real life waterfall!) some phases in case somethings needs to be changed. One phase must be completed
Continue reading "Hey, listen. Software Processes. Yeah…" →

Time to talk about APIs

This means Application Programming Interface, by the way. That may not help much, though. Even so, most surely you’re already using them every single day… Let me just mention you a few ways APIs involved in your daily activities: Facebook, Yahoo, Youtube, Amazon, Twitter, Pinterest, Reddit, Foursquare, Instagram, Pandora and even WhatsApp. Don’t tell me you don’t use any of these. There are widgets, buttons and badges everywhere making you pull and push content to other sites.


You might want to think of APIs as a wall socket. These electrical sockets are essentially interfaces to a service. You’re a consumer of this service. You don’t need to have your very own power source for you to be able to charge your electrical devices.
Now, back to reality, you use APIs as an interface to some other application/website service. You’re a user of this application/site. It’s through this API (make it widget, button, badge or whatever), that you don’t need to use the application/website as a whole, but only a small part for which the API was specifically made for.


There are even more detailed ways of having an API. A few examples: thermostats, smoke detectors, automobiles, clothing, glasses, etc.

And it’s logical. I mean, if you want as many people as possible to use your product/service, why wouldn’t it be a magnificent idea to split your product/service into tiny, functional, very specific parts (APIs) that can be implemented through other applications/websites or whatever; your users won’t have to be moving from one place to another to do as they desire. And that’s very, VERY important :)

Here I leave a video showing IFTTT (one of many API enabled orchestration platforms), a service that takes approach of many, many APIs out there and lets you combine them in practically infinite ways Continue reading "Time to talk about APIs" →