Well, this time its time to say Thank you. In our lives, we can regret plenty of different things. But I am sure  one of the biggest regrets you, me and I will have, are also the most difficult ones. Not saying things on time.

Always be sure to say what you feel. Either you are happy, sad, angry, even hungry. Shout it. Never shut it up. This is really a small post but what I am feeling, what I want to say is:

THANK YOU KEN. THANK YOU FOR BEING THIS AWESOME TEACHER THAT GETS OUT THE ROUTINE TO TRY TO TEACH US SOMETHING BIGGER THAN A SIMPLE SCHOOL SUBJECT. YOU TRIED TO TEACH US A LIFE LESSON (AS IS SELF-LEARNING AND RESPONSIBILITY TO SAY AN EXAMPLE).

I CAN SAY FROM EVERYONE THAT WE ALL HAD GROWN ON A WAY. SOME PEOPLE MORE THAN OTHERS BUT AT THE END IS LEARNING AND GROWING WHICH IS THE IMPORTANT THING IN LIFE.

ALWAYS KEEP MOVING, ALWAYS KEEP LIVING, EXPLORING, LEARNING. HAVE THAT CHILD SOUL AND REMEMBER, IF THINGS ARE NOT SO GOOD; NO WORRIES. SOON EVERYTHING IS GOING TO BE ALL RIGHT.

YOU HAVE A FRIEND IN ME

Feel romantic? You should listen to this

So now, lets talk about one important aspect when building software. We gotta have always in mind that helping the regular user have this intuitive way of using the app-software will lead us to a more successful development.

Here is where the User Interface Design comes to matter.

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that the interface has elements that are easy to access, understand, and use to facilitate those actions. UI brings together concepts from interaction design, visual design, and information architecture.

Users have become familiar with interface elements acting in a certain way, so try to be consistent and predictable in your choices and their layout. Doing so will help with task completion, efficiency, and satisfaction.

• Input Controls: buttons, textfields, checkboxes, radio buttons, dropdown lists, list boxes, toggles, date field
• Navigational Components: breadcrumb, slider, search field, pagination, slider, tags, icons
• Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal windows
• Containers: accordion

Everything stems from knowing your users, including understanding their goals, skills, preferences, and tendencies.  Once you know about your user, make sure to consider the following when designing your interface:

• Keep the interface simple. The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging.
• Create consistency and use common UI elements. By using common elements in your UI, users feel more comfortable and are able to get things done more quickly.  It is also important to create patterns in language, layout and design throughout the site to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the site.
• Be purposeful
  
  
  Continue reading "Beautify Me ;)" →

Software development efforts result in the delivery of a software product that satisfies user requirements. Accordingly, the software product must change or evolve. Once in operation, defects are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle begins following a warranty period or postimplementation support delivery, but maintenance activities occur much earlier

.

Software maintenance is an integral part of a software life cycle. However, it has not received the same degree of attention that the other phases have. Historically, software development has had a much higher profile than software maintenance in most organizations. This is now changing, as organizations strive to squeeze the most out of their software development investment by keeping software operating as long as possible. The open source paradigm has brought further attention to the issue of maintaining software artifacts developed by others.

Maintenance is needed to ensure that the software continues to satisfy user requirements. Maintenance is applicable to software that is developed using any software life cycle model (for example, spiral or linear). Software products change due to corrective and noncorrective software actions. Maintenance must be performed in order to

• correct faults;
• improve the design;
• implement enhancements;
• interface with other software;
• adapt programs so that different hardware, software, system features, and telecommunications facilities can be used;
• migrate legacy software; and
• retire software.

Five key characteristics comprise the maintainer’s activities:

• maintaining control over the software’s day-to-day functions;
• maintaining control over software modification;
• perfecting existing functions;
• identifying security threats and fixing security vulnerabilities; and
• preventing software performance from degrading to unacceptable levels.

This blog is the most relevant information extracted from the bottom source. Day by day I will try to be eliminating the source words and add my own content but for practice purposes (for now) will be as

As software engineers, we all should already know that, when working on a new project, you start by establishing the way of attacking-solving the problem or software to develop. So it is important to get there are these things called patterns (software design patterns) which may help you as a guide to your way of working.

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

There are three design patterns we are going to talk about.

Structural

In Software Engineering, Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities, making it easier for these to work together.

• Adapter
  Match interfaces of different classes
• Bridge
  Separates an object’s interface from its implementation
• Composite
  A tree structure of simple and composite objects
• Decorator
  Add responsibilities to objects dynamically
• Facade
  A single class that represents an entire subsystem
• Flyweight
  A fine-grained instance used for efficient sharing
• Private Class Data

  Restricts accessor/mutator access

• Proxy
  An object representing another object

Creational

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

• Abstract Factory
  Creates an instance of several families of classes
• Builder
  Separates object construction from its representation
• Factory Method
  Creates an instance of several derived classes
• Object Pool
  Avoid expensive acquisition and release of resources by recycling objects
  
  
  
  
  Continue reading "Software design patterns" →

What is software architecture?

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:

“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”

Architectural Landscape

• User empowerment. A design that supports user empowerment is flexible, configurable, and focused on the user experience. Design your application with appropriate levels of user personalization and options in mind. Allow the user to define how they interact with your application instead of dictating to them, but do not overload them with unnecessary options and settings that can lead to confusion. Understand the key scenarios and make them as simple as possible; make it easy to find information and use the application.
• Market maturity. Take advantage of market maturity by taking advantage of existing platform and technology options. Build on higher level application frameworks where it makes sense, so that you can focus on what is uniquely valuable in your application rather
  
  
  
  Continue reading "One brick at a time- Software Architecture" →

What is software design?

It is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.

Software design may refer to either “all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems” or “the activity following requirements specification and before programming, as a stylized software engineering process.”

Software design usually involves problem solving and planning a software solution. This includes both a low-level component and algorithm design and a high-level, architecture design.

There are several basic design principles that enable the software engineer to navigate the design process:

• The design process should not suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.
• The design should be traceable to the analysis model. Because a single element of the design model can often be traced back to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.
• The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited; design time should be invested in representing truly new ideas and integrating patterns that already exist when applicable.
• The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. That is, the structure of the software design should, whenever possible, mimic the structure of the problem domain.
• The design should exhibit uniformity and integration. A design is uniform if it appears fully coherent.
  
  
  
  Continue reading "Bibidi Badi-Software Design" →

In software engineering, we have plenty kind of requirements, but in this blog we are really interested in to kinds of them. The software requirements elicitation and software requirements specification.

Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as “requirement gathering”.

The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process.

In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:

1. ‘Problems of scope’. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
2. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches:

1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the
   
   
   Continue reading "Let’s learn about some requirements" →

Sus siglas en ingles (UML) Unified Modeling Language es un estándar para desarrollo de software. Tiene como objetivo mejorar la comunicación entre programadores, hacer saber de las necesidades servidor cliente, crear un modelado de la estructura para el diseño de un programa.

Los pioneros de  UML fueron: Grady Booch, James rumbaugh e Ivar Jacobson. En la época de los 80s, al desarrollar individualmente una metodología para el análisis y diseño orientado objeto, donde posterior mente (en el inicio de los 90s) juntaron su trabajo. De ahi nacio la idea de un lenguaje unificado.

Es importante que entendamos que UML no es programación, no son sentencias ni codigo; no esta asociado a ningún lenguaje de programación. Ni es metodología.

DIAGRAMAS UML

• Define la estructura y el comportamiento del programa.
• Organizar características y funciones de un proceso para su mejor funcionamiento.
• Se utiliza para hacer el análisis del sistema.
• Presentar diversas perspectivas de un sistema
• Se pueden correlacionar un diagrama con otro.
• Genera muchas formas de organizarlos y extenderlos.

DIAGRAMA DE CLASES

Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares.

DIAGRAMA DE OBJETOS

Es una entidad que tiene valores específicos de los atributos y acciones.

DIAGRAMA DE ESTADOS

Es el estado en particular que se encuentra el objeto. Establece condiciones. Realiza actividad o espera algún evento.

DIAGRAMA DE SECUENCIAS

Son interacciones entre objetos que suceden con el tiempo.

DIAGRAMA DE ACTIVIDADES

Las actividades que ocurren dentro de un caso de uso. Lo que se hace en un estado o grupo de estados. Orden, donde, tiempo, cuando, quien y que harán.

Entre estos y mas conceptos los podemos ver junto con sus respectivos ejemplos en la playlist Curso UML de Ingenio y Tecnología. Toda la información del blog fue extraída de dicha playlist y plasmada en texto (las partes

El software de código libre-abierto u Open Source Software. Muy probablemente hayamos escuchado este termino muchas veces, en especial si en nuestra vida nos interesan los temas relacionados con la tecnología y software en general. En concepto es el movimiento que promueve y fomenta a los usuarios y creadores de software a compartir, distribuir y contribuir (entre otras cosas) el software con la comunidad. Haciendo que junto a ella se crezca el software y se distribuya a través de la comunidad.

Una definición que me gusta es: software libre refiere al programa informático que brinda una gran libertad al usuario. Aquel que instala un programa de software libre, puede usarlo, modificarlo, copiarlo y redistribuirlo sin restricciones.

En un articulo del sitio web de GNU sobre software libre  se habla de 4 libertades fundamentales:

• La libertad de ejecutar el programa como lo desee, con cualquier propósito.
• La libertad de estudiar el funcionamiento del programa y adaptarlo a sus necesidades. El acceso al código fuente es un prerrequisito para esto.
• La libertad de redistribuir copias para ayudar a los demás.
• La libertad de mejorar el programa y de publicar las mejoras, de modo que toda la comunidad se beneficie. El acceso al código fuente es un prerrequisito para esto.

Es importante mencionar que existen diferentes licencias para el software y dependiendo de esta, son las libertades de manejarlo y distribuirlo en general, ademas del como se ve beneficiada o no la empresa que desarrollo a este software. Les dejo un video para que aprendan un poco mas sobre esto. Muchas gracias por pasar por este blog, cualquier duda, comentario o sugerencia hacermelo saber.