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.
If of testing we are talking, the verification and validations are our next targets.
The terms ‘Verification‘ and ‘Validation‘ are frequently used in the software testing world but the meaning of these terms are mostly vague and debatable. You will encounter (or have encountered) all kinds of usage and interpretations of those terms, and it is our humble attempt here to distinguish between them as clearly as possible.
First of all.
The process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase. Its objective is 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.
We constantly should be asking to our self: Are we building the product right? How are we going to do this? Simple, by:
And evaluating plans, requirement specs, design specs, code and test Cases
The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements. Its objective is to ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment.
This time we need to ask: Are we building the right product? Our evaluation item is the product (software) and the way of doing it is by testing, testing testing testing.
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)
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
Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal windows
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.
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
improve the design;
interface with other software;
adapt programs so that different hardware, software, system features, and telecommunications facilities can be used;
migrate legacy software; and
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.
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.
Match interfaces of different classes
Separates an object’s interface from its implementation
A tree structure of simple and composite objects
Add responsibilities to objects dynamically
A single class that represents an entire subsystem
A fine-grained instance used for efficient sharing
Private Class Data
Restricts accessor/mutator access
An object representing another object
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.
Creates an instance of several families of classes
Separates object construction from its representation
Creates an instance of several derived classes
Avoid expensive acquisition and release of resources by recycling objects
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.”
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
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 satisﬁed 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.
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:
‘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.
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.
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:
Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the
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.
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.
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.