En este post describiremos de manera objetiva y sencilla los potenciales de cada modelo de desarrollo que existe para proyectos de software. Basada en la siguiente imagen.

Waterfall: Esta metodología describe el proceso tradicional que ha tenido el software por mucho tiempo, podemos observar por el gráfico que se sigue un ciclo de vida del software, está la fase de requerimientos, diseño, producción, test y mantenimiento hasta poder observar como el cliente no es involucrado en el desarrollo de la misma. Ahora que con este proceso se puede determinar que una vez el cliente ha especificado lo que quiere es muy difícil que pueda cambiar de decisión. Para procesos de proyecto tecnológicos que requieren una validación, este modelo no puede satisfacerlo.

Agile Development: Esta metodología facilita mucho que el cliente pueda participar de la construcción del software, la objetividad y la particularidad de la transparencia permiten que se pueda concretar los objetivos del cliente. Este método sin duda evita problemas que se pueden encontrar comúnmente en procesos escalonados y sin ningún tipo de participación por parte del cliente, al cual se necesita que sea un eje importante dentro del desarrollo del software.

Kanban: Sin duda esta metodología ofrece potencialidades en el desarrollo de software de manera significativa. Estas potencialidades se las puede apreciar desde la manera en el como el cliente interactúa en el proceso de desarrollo. La compenetración de los clientes con los desarrolladores es sin duda una de sus fuertes para alcanzar los tan preciados objetivos que se tiene para el software.

Scrum: En esta metodología podemos observar que se tiene un eje central bien definido y es el equipo que se conforma para el desarrollo. Si bien el cliente interactúa en este método no lo es tanto como para poder ser tan tangible en su desarrollo. La base es la organización del equipo y la manera que ellos pueden alcanzar los más preciados objetivos.

Lean: Esta metodología permite construir un software lo suficientemente funcional, eso sí, nos permite observar que cada componente o cada estructura esta adecuadamente estructurada para permitir conjuntamente que el cliente sea participe de ella y que se le demuestre que sus objetivos serán alcanzados y hasta podría cumplir más de lo que se ha descrito. Todo esto llevado a cabo mediante un minucioso desarrollo e interesándose más en las estructuras principales.

Conclusiones

• El desarrollo de software sin una metodología adecuada no se podría sacar el máximo potencial en cuanto al alcance de objetivos para el cliente, varias metodologías tienen sus fortalezas y debilidades en cuanto a que tipo de software se desarrolle.
• Es primordial entender de una manera específica sobre los objetivos que queremos alcanzar con el software, seleccionar y entender porque hemos seleccionado la metodología de desarrollo y así aprovechar sus principales ventajas.

Read More →

Las representaciones optimizadas en los sistemas distribuidos para detectar imprevistos en el tiempo no son muy intuitivas y no deberían ser ignoradas. los dos mecanismos que se analizan son vectores de versión y vectores de reloj, dos tipos de mecanismos muy útiles y muy complejos a la hora de poder ser manejado con la correcta certeza que podrán ser métodos detectores de eventualidades funcionales.

Los vectores de versión creado en el año 1983 (Parker, 1986) antes de los vectores de reloj, han visto su funcionalidad a la hora de manejar y rastrear eventualidades dentro de los sistemas distribuidos. Los errores que se pretende mejorar es la capacidad de concurrencia que maneja los vectores, es decir, los vectores con una entrada por cliente no escalan bien cuando millones de clientes acceden al servicio. Estas limitaciones son fácilmente resueltas cuando se habla de algoritmos optimizados que para este tipo concreto de problema pueda asignar un único identificador localmente o inmediatamente. En sistemas donde los clientes y servidores son divididos en nodos, es posible tal creación de un único identificador, pero esto retrasaría la comunicación con los servidores ante la creación de identificadores generados en el servidor. Con esta condición los clientes comunican solo con servidores y una nueva actualización sobrescribe todas las versiones anteriormente. La mayoría de ocurrencias de estos eventos los podemos encontrar en sistemas de almacenamiento compartido, por ejemplos sistemas de administradores de código, ya que cada usuario del proyecto une sus cambios y el servidor asigna una identificación dentro del proceso para correlacionar de manera satisfactoria los eventos.

Para ilustrar de mejor manera esta afirmación, explicare de manera detallada y con un lenguaje no muy técnico lo que se detalla en el párrafo anterior.

Eventualidades dentro de un sistema distribuido de alamcenamiento

Dentro de lo mencionado anteriormente, la ilustración 1 permite observar que en el escenario existe 4 nodos cada uno con su función definida para un sistema distribuido de almacenamiento. Cuando el cliente A y el cliente B actualizarán concurrentemente al servidor S, para el primer paso vemos como el cliente B procede a escribir una versión con un único nombre en este caso s1, y entrando al proceso de servidor S como representación {s1}, enseguida y de manera prolija el cliente A escribe una nueva versión a la cual el servidor S dará como {s2} tal cual como una nueva asignación. Como se puede ver el servidor ha tenido sus propios clientes t1, t2, t3 como recibe la actualización del servidor S, la próxima vez que reciba datos esta será reemplazada por la nueva información.

Entendiendo que la generación de nombres únicos para la asignación de interacciones en el tiempo en los sistemas distribuidos, permite la compactación de la representación de los vectores. Dado que los sistemas mantienen sus procesos y el reto es mantenerlos vivos la unión y actualización de sus nodos a través de los vectores de unión hacen que sea más un mecanismo óptimo para la ordenación de eventos en sistemas distribuidos.

Bibliografía
• Baquero, C. and Preguiça, N. (2016) ‘Why logical clocks are easy’, Communications of the ACM, 59(4), pp. 43–47. doi: 10.1145/2890782.
• Parker, D.S., Popek, G. J., Rudisin, G., Stoughton, A., Walker, B. J., Walton, E., Chow, J. M., Edwards, D., Kiser, S., Kline, C. 1983. Detection of mutual inconsistency in distributed systems. IEEE Transactions on Software Engineering 9(3): 240–247.

Read More →

Todos hemos visto o hemos sido víctimas de un fallo de un sistema informático. Por alguna razón no necesariamente obvia, los sistemas caen y no consiguen realizar los servicios que se les ha requerido.

Veamos a través de un gráfico que es la confiabilidad de un sistema informático:

Veamos las cuatro dimensiones fundamentales de la confiabilidad según Sommerville  

Además de estas cuatro dimensiones principales, también se pueden considerar otras propiedades del sistema incluidas en el término confiabilidad.

“Cuando mayor sea la confiabilidad que se necesita, más habrá que gastar en probar y chequear que efectivamente se h alcanzado dicho nivel de confiabilidad. Debido al carácter exponencial de esta curva coste/confiabilidad, no es posible demostrar que un sistema es totalmente confiable, ya que los costes necesarios para asegurar esto podrían ser infinitos” (Ian Sommerville

Read More →

Los productos de software tienen asociados algunas características que les permiten reflejar la calidad del mismo. Puesto que estos atributos no necesariamente se relacionan con lo que hace el software, sino con la manera como es su comportamiento durante la ejecución, estructura y organización del programa fuente y en la documentación asociada.

No sirve de nada tener el mejor software si nadie sabe cómo usarlo

• Mantenibilidad:  Dado que las necesidades de los clientes pueden cambiar por cambios en sus modelos de negocio, un software debe estar escrito de tal manera que pueda evolucionar y pueda adaptarse. Hemos visto por ejemplo diseñar nuestro código con principios S.O.L.I.D.

Principios S.O.L.I.D orientado a objetos y diseño ágil

• Confiabilidad: Dentro de la confiabilidad existe unas características como la fiabilidad, protección y seguridad. El software debe ser construido y testeado de tal manera que no pueda causar ningún tipo de problema sea económico o físico.

• Eficiencia: Para lograr que un sistema pueda brindar eficiencia se analiza varios factores entre ellos el manejo óptimo de recursos del computador, tiempos de respuesta, capacidad de auto recuperación, manejo de concurrencia, etc.

• Usabilidad: No sirve de nada tener el mejor software si nadie sabe cómo usarlo, es esencial tener una documentación y diseñar interfaces gráficas que permitan al usuario apropiado utilizarlo sin esfuerzo adicional. Para ello puedes consultar nuestro post acerca de Elicitación que te ayudará aclarar lo que el cliente necesita 

4 Errores comunes resueltos con elicitación

Es normal definir ciertos tipos de atributos dependiendo que tipo de aplicación se realizará, ejemplo sistemas bancarios jamás tendrán los mismos atributos que un simple juego por computadora. Puesto que se han definido los más esenciales y al momento de desarrollarlos tenerlos claro para evitar futuras complicaciones y entregar productos de calidad.

Read More →

A lo largo del tiempo la gestión de los proyectos de software ha cambiado con el fin de encontrar soluciones a la deficiencia de cumplir con lo que el cliente necesita. Al ser la elicitación un factor importante al aportar la extracción y comprensión de lo que realmente el software debe hacer. Resaltar la importancia de obtener los requisitos desde un entorno global del desarrollo del software, se puede abarcar de mejor manera y de manera significativa el alcance que obtendrá nuestro proyecto de software. 

 Para mejorar los procesos de elicitación dentro de un proyecto de software se han identificado 4 factores que ocurren de manera repetitiva. Se han documentado formas de poder gestionar y realizar de manera óptima un levantamiento de requerimientos según sea el caso en el que el proyecto se desenvuelva.

• Caso 1

 Cuando ambas partes de un proyecto tienen la visión funcional del proyecto de software va a tener que afrontar, existe un percance al realizar más exploración sobre los requerimientos, la parte contratante involucra definir detalles técnicos que pueden confundir, más que aclarar, los objetivos generales del sistema. 

• Caso 2

  Encontrarnos con el caso de la parte contratante tiene claro los objetivos que debe alcanzar el software, pero el equipo de desarrollo no ha comprendido el propósito general, para este caso es importante encontrar una herramienta y también una metodología ágil que nos ayude poder enlazar la parte de desarrollo con la involucración del cliente

 

• Caso 3

  Para cuando ninguna de las dos partes tiene claro la visión que realizará el proyecto de software, existen técnicas muy usadas en otros campos de planificación de proyectos, una de ellas es la muy famosa realización de encuestas, entablar comunicación con cada una las personas que intervendrán en el funcionamiento global, después de aquello se obtiene una visión bastante profunda que le permitirá a cada parte saber y entender lo que los stakeholders necesitan y quieren ver la funcionalidad en el sistema que se desarrollará.

• Caso 4

Nos encontramos con el último caso que se puede dar, cuando los desarrolladores tienen claro lo que el proyecto de software debe cumplir para asegurar que los objetivos del contratante serán satisfechos. Pero la parte contratante no ha visto de manera generalizada lo que realmente necesita, la ayuda viene determinada desde un enfoque de caja negra, es decir, entran datos y se obtiene información. Identificarlos de esta manera se logra que el cliente pueda visibilizar lo que el proyecto generará.

Conclusiones.

 

Como hemos visto la importancia de la especificación de requerimientos dentro del proyecto de software, recae sobre una eficiente elicitación de requisitos. Muchos métodos son aplicables dependiendo el tipo de proyecto que se realiza, identificar y emplear estos métodos ayudará a generar eficiencia tanto en el tiempo y cualquier otro inconveniente que surge al no contar con estos procesos al realizar un proyecto de software.

Read More →

• Front End 

 In this section are those programmers who understand very well the concepts of design and behavior of users, those that make our graphical interfaces look first. 

En esta sección se encuentran aquellos programadores que entienden muy bien los conceptos de diseño y comportamiento de los usuarios, aquellos que hacen que nuestras interfaces gráficas luzcan de primera.

• Mobile

Here are all those programmers who work in the construction of technology platforms for smart phones.

Aquí se encuentran todos aquellos programadores que trabajan en la contrucción de paltaformas tecnológicas para telefonos inteligentes.

• Las cuatro dimensiones de la confiabilidad de un sistema (SOFTWARE)

• Gaming

This industry is dedicated to know more about platforms of development of games and entertainment, a field very demanded besides being one of the most complex.

Esta industria se dedica a conocer más sobre plataformas de desarrollo de juegos y entretenimiento, un campo muy demandado además de ser uno de los más complejos.

 

• Back-End

They are specialists in codifying what a system must perform for a user. It is neatly the code that is below in every technological project.

Son especialistas en codificar lo que un sistema debe realizar para un usuario. Netamente es el código que esta por debajo en todo proyecto tecnológico.

• Documento de requerimientos de software SRS 

• Applications

They are those programmers who are dedicated to encode any type of applications, be it desktop, mobiles, services, etc.

Son aquellos programadores que se dedican a codificar cualquier tipo de aplicaciones, sea de escritorio, mobiles, servicios, etc.
 

• Data Scientist

These people are able to develop or use tools that allow them to analyze the large amount of data a company handles in order to make the best decision.

Estas personas son capaces de desarrollar o utilizar herramientas que les permitan analizar la gran cantidad de datos que maneja una empresa con el fin de tomar la mejor decisión.
 

• QA / Test

Those people who control that a software project complies with the standards and norms that assure the quality of the same.

Aquellas personas que controlan que un proyecto software cumpla con los estándares y normas que aseguren la calidad de la misma. 

• Algorithms

These people are able to design code that meets specific needs for specific processes.

Estas personas son capaces de diseñar código que satisfaga necesidades concretas para procesos especificos.

• Embedded

They are the programmers that make your keyboard, mouse, etc. can work. They interact a lot with hardware creators.

Son los programadores que hacen que tu teclado, mouse, etc pueda funcionar. Interactuan mucho con los Creadores de hardware.

• Operating Systems

The dream that maybe we all want to be, these people are able to update functionalities in operating systems. Find errors or update more stable versions of OS.

El sueño que tal vez todos quisieramos ser, estas personas son capaces de actualizar funcionalidades en sistemas operativos. Encuentran errores o Actualizan versiones de S.O más estables

• Dev-Ops

They are specialists in large designs, ie projects at large scales such as banks, government companies. They are usually called "Core" builders.

Son especialista en diseños grandes, es decir, proyectos a grandes escalas como por ejemplo de empresas de Bancos, gubernamentales. Usualmente son llamados constructores de "Core".
 

• Full Stack

They are specialists in dominating the majority of technologies to develop technological projects.

Son especialistas en dominar la mayoria de tecnologías para desarrollar proyectos tecnológicos.

• Language / Compiler

Specialists in programming language development or in turn to improve how you handle processes or other server resources.

Especialistas en desarrollo de Lenguajes de programación o a su vez de mejorar como maneja los procesos o los demás recursos del servidor.

Other post about software

• ¿Cuáles son los atributos de un buen software?

Read More →

Introduction:Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.  

More Information: Web site official

Estructura básica de SCRUM

Read More →