lunes, 16 de abril de 2018

¿Qué importancia tiene el análisis y diseño de sistemas para el éxito de los proyectos de software?

¿Qué importancia tiene el análisis y diseño de sistemas para el éxito de los proyectos de software?

Resultado de imagen para Qué importancia tiene el análisis y diseño de sistemas para el éxito de los proyectos de software

Me he dado cuenta que tanto el análisis  como el diseño de sistemas son muy importantes en la creación de un proyecto, ya que cuando recién estas iniciando te imaginas ya el producto final, pero si comienzas a desarrollar el proyecto sin antes haber realizado un análisis irán surgiendo problemas o algunas cosas que no tenias contempladas lo cual causara que el diseño de el sistema también tenga fallas y no quede como lo imaginabas o ni siquiera funcione.

Por esto yo recomendaría que le dediquen el tiempo necesario para que el análisis de el proyecto resulte eficiente y así poder evitar retrasos a la hora de diseñar, y poder obtener un buen proyecto, cercano o igual a como lo imaginaste en el menor tiempo posible.

Los 3 amigos (Grady Booch, James Rambaugh e Ivar Jacobson).

Los 3 amigos.
 (Grady Booch, James Rambaugh e  Ivar Jacobson). 

Grady Booch
Resultado de imagen para Grady Booch

Grady es reconocido internacionalmente por su trabajo innovador en arquitectura de software, ingeniería de software y entornos de desarrollo colaborativo.

Se desempeñó como científico jefe de Rational Software Corporation desde su fundación en 1981 y mediante su adquisición por parte de IBM.En 2003, ha estado profundamente involucrado en la estrategia de sistemas cognitivos de IBM, para Watson y actualmente es el científico principal de Watson / M enfocado en la cognición incorporada.

Dirigió el tema de IBM Global Technology Outlook sobre sistemas cognitivos, y ahora continúa trabajando con los arquitectos clave de Watson Group y la organización hermana de IBM Research para avanzar en la ciencia y la práctica de los sistemas cognitivos. 

Es la autor de los seis libros más vendidos, incluida la Guía del usuario de UML y el análisis y diseño orientados a objetos y aplicaciones con aplicaciones. Escribe una columna regular sobre arquitectura para el software IEEE.

 Grady ha publicado varios cientos de artículos sobre ingeniería de software, incluyendo artículos publicados a principios de los 80 que originaron el término y práctica de diseño orientado a objetos (OOD), además de artículos publicados a principios de 2000 que originaron el término y la práctica de entornos de desarrollo colaborativo.

James Rambaugh
Resultado de imagen para James Rumbaugh

Es uno de los principales metodólogos orientados a objetos. Es el principal desarrollador de la Técnica de Modelado de Objetos (OMT) y el autor principal del libro best-seller Modelado y Diseño Orientado a Objetos . Antes de unirse a Rational Software Corporation en octubre de 1994, trabajó durante más de 25 años en el Centro de Investigación y Desarrollo de General Electric en Schenectady, Nueva York.

Desarrolló el lenguaje de programación orientado a objetos DSM, el modelo de control de árbol de estado, la notación de modelado de objetos OMT y el editor gráfico de la herramienta Object Modeling Tool.

 Su carrera se ha ocupado de la semántica de la computación, las herramientas para programar la productividad y las aplicaciones que usan algoritmos complejos y estructuras de datos.
Desarrolló Chipwright, un sistema CAD gráfico interactivo para el diseño de VLSI con verificación de reglas de diseño incremental, también desarrolló Flow Graph System, un sistema gráfico interactivo genérico para controlar una red de trabajos de ingeniería de diseño, incluida la gestión de múltiples versiones de datos y la coordinación del flujo de información entre las aplicaciones.

Llevo a cabo algoritmos para la visualización de imágenes tridimensionales en tiempo real utilizando procesadores de matriz, y desarrolló Parallax, un lenguaje para la programación de procesadores de matriz segmentados.


Ha publicado artículos de revistas sobre su trabajo y ha hablado en conferencias líderes orientadas a objetos. Escribe una columna regular para el Journal of Object-Oriented Programming.

Ivar Jacobson

Resultado de imagen para James Rumbaugh
En 1967 propuso la utilización de componentes de software en el desarrollo de la nueva generación de conmutadores telefónicos controlados, que Ericsson estaba desarrollando. Para ello inventó diagramas de secuencia y desarrolló diagramas de colaboración. También aplicó diagramas de transición de estado para describir el flujo de mensajes entre los componentes.

 Inventó casos de uso como una forma de especificar los requisitos funcionales de software.
En 1987, dejó Ericsson y fundó la empresa Objective Systems. Una mayoría de las acciones de la compañía fue adquirida por Ericsson en 1991, y la compañía fue renombrada Objectory AB.Ivar Jacobson desarrolló el proceso de software OOSE en Objectory AB alrededor de 1992.

 En 1995 Ericsson vendió Objectory AB a la firma Rational Software, y Jacobson comenzó a trabajar con Grady Booch  y James Rambaugh  , primero para crear el Lenguaje Unificado de Modelado (UML) y posteriormente para desarrollar el Proceso Unificado Racional (RUP).






UML( Lenguaje Unificado de Modelado).

UML

Resultado de imagen para uml



El Lenguaje Unificado de Modelado  fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento, tiene aplicaciones más allá del desarrollo de software.

El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software.

UML cumple con los siguientes requerimientos:

  • Establecer una definición formal de un metamodelo común basado en el estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del UML.
  • Brindar una explicación detallada de la semántica de cada concepto de modelado UML.
  • Especificar los elementos de notación de lectura humana para representar los conceptos individuales de modelado UML, así como las reglas para combinarlos en una variedad de diferentes tipos de diagramas que corresponden a diferentes aspectos de los sistemas modelados.

Resultado de imagen para uml

Modelado UML

El desarrollo de sistemas se centra en tres modelos generales de sistemas diferentes:
  • Funcionales: Se trata de diagramas de casos de uso que describen la funcionalidad del sistema desde el punto de vista del usuario.
  • De objetos: Se trata de diagramas de clases que describen la estructura del sistema en términos de objetos, atributos, asociaciones y operaciones.
  • Dinámicos: Los diagramas de interacción, los diagramas de máquina de estados y los diagramas de actividades se usan para describir el comportamiento interno del sistema.

Estos modelos de sistemas se visualizan a través de dos tipos diferentes de diagramas: estructurales y de comportamiento.


Referencias:

viernes, 13 de abril de 2018

Paradigma de programación orientado a objetos



Paradigma de programación orientado a objetos





La programación orientada a objetos, es necesaria en la vida de un programador ya que con esta visualizamos las actividades de cada una de esas. Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

  • Herencia:


 Es la transmisión del código entre unas clases y otras. Para soportar un mecanismo de herencia tenemos dos clases: la clase padre y la/s clase/s hija/s. La clase padre es la que transmite su código a las clases hijas. En muchos lenguajes de programación se declara la herencia con la palabra "extends".
Eso quiere decir que todo el código de la clase padre se transmite, tal cual, a la clase hija. Si lo quieres ver así, es como si tuvieras escrito, línea a línea, todo el código de la clase "Padre" dentro de las llaves de la clase "Hija". Por eso, la herencia es fundamental para reutilizar código, porque no necesitas volver a incorporar el código de Padre en Hija, sino que realmente al hacer el "extends" es como si ya estuviera ahí.

  • Polimorfismo: 


Es uno de los conceptos esenciales de la programación orientada a objetos. Así como la herencia está relacionada con las clases y su jerarquía, el polimorfismo lo está con los métodos. Hay tres tipos de polimorfismo: el polimorfismo de sobrecarga, el polimorfismo paramétrico  y el polimorfismo de inclusión.

Polimorfismo de sobrecarga:
Ocurre cuando las funciones del mismo nombre existen, con función similar, en clases que son completamente independientes unas de otras (estas no tienen que ser clases secundarias de la clase objeto). Esto significa que no necesitamos preocuparnos sobre el tipo de objeto con el que estamos trabajando si todo lo que deseamos es verlo en la pantalla.  El polimorfismo de sobrecarga nos permite definir operadores cuyos comportamientos varían de acuerdo a los parámetros que se les aplican.

Polimorfismo paramétrico:

 Es la capacidad para definir varias funciones utilizando el mismo nombre, pero usando parámetros diferentes (nombre y/o tipo). El polimorfismo paramétrico selecciona automáticamente el método correcto a aplicar en función del tipo de datos pasados en el parámetro. 
Una “signature” es el nombre y tipo (estático) que se da a los argumentos de una función. Por esto, una firma de método determina qué elemento se va a llamar. 

Polimorfismo de subtipado:
La habilidad para redefinir un método en clases que se hereda de una clase base se llama especialización. Por lo tanto, se puede llamar un método de objeto sin tener que conocer su tipo intrínseco: esto es polimorfismo de subtipado. Permite no tomar en cuenta detalles de las clases especializadas de una familia de objetos, enmascarándolos con una interfaz común (siendo esta la clase básica). 

  • Abstracción:


Es un término del mundo real que podemos aplicar tal cual lo entendemos en el mundo de la Programación Orientada a Objetos. Algo abstracto es algo que está en el universo de las ideas, los pensamientos, pero que no se puede concretar en algo material, que se pueda tocar.
La abstracción expresa las características esenciales de un objeto, las cuales distinguen al objeto de los demás.

  • Encapsulación:


Se encarga de mantener ocultos los procesos internos que necesita para hacer lo que sea que haga, dándole al programador acceso sólo a lo que necesita. Esto da dos ventajas iniciales: Lo que hace el usuario puede ser controlado internamente evitando que todo colapse por una intervención indeseada. La segunda ventaja es que, al hacer que la mayor parte del código esté oculto, puedes hacer cambios o mejoras sin que eso afecte el modo como los usuarios van a utilizar tu código. Sólo tienes que mantener igual la forma de acceder a él.

Referencias:

jueves, 12 de abril de 2018

Paradigma de programación




Paradigma de programación



Para tener una mejor idea a lo que se refiere primero definiremos la palabra paradigma.

Paradigma es un conjunto de creencias, prácticas y conocimientos que guían el desarrollo de una disciplina durante un período de tiempo. 

Un paradigma de programación es la forma en que un programador o un conjunto de programadores dan solución a uno o varios problemas. En este sentido, representa una manera particular de dar soluciones.

Existen distintos paradigmas de programación. Los principales son el imperativo, el declarativo, el lógico, el funcional y el orientado a objetos. 
Estos paradigmas se diferencian unos de otros debido a la forma de abordar los elementos involucrados en el problema, así como los pasos necesarios para llegar a su solución.

  • Imperativo: Los programas se componen de un conjunto de sentencias que cambian su estado. Son secuencias de comandos que ordenan acciones a la computadora.
  • Declarativo: Opuesto al imperativo. Los programas describen los resultados esperados sin listar explícitamente los pasos a llevar a cabo para alcanzarlos.
  • Lógico: El problema se modela con enunciados de lógica de primer orden.
  • Funcional. Los programas se componen de funciones, es decir, implementaciones de comportamiento que reciben un conjunto de datos de entrada y devuelven un valor de salida.
  • Orientado a objetos: El comportamiento del programa es llevado a cabo por objetos, entidades que representan elementos del problema a resolver y tienen atributos y comportamiento.


Referencias:
http://www.4rsoluciones.com/blog/que-son-los-paradigmas-de-programacion-2/
http://michelletorres.mx/paradigmas-de-programacion/
https://www.significados.com/paradigma/




domingo, 11 de marzo de 2018

Métodos y metodologías en el desarrollo de software
Nombre

Cascada
Espiral
Extreme Programming
Metodologías Ágiles
Descripción
Es un modelo lineal de diseño de software que emplea un proceso de diseño secuencial.
Refleja la relación de tareas con prototipos rápidos, mayor paralelismo y concurrencia en las actividades de diseño y construcción.
Se utiliza principalmente para evitar el desarrollo de funciones que actualmente no se necesitan, pero sobre todo para  para atender proyectos complicados.
Son aquellas que permiten adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno.
Etapas
-Planteamiento
-Iniciación
-Análisis
-Diseño
-Construcción
-Pruebas
-Implementación
-Mantenimiento

-Determinar o fijar objetivos
-Análisis del riesgo

-Desarrollar, verificar y validar
-Planificación


Roles
-Analista
-Programador
-Diseñador
-Tester
-Programador
-Cliente
-Tester
-Programador
-Cliente
-Tester
-Tracker
-Gestor
-Coach
-Consultor
-Programador
-Tester
-Tracker
-Coach
-Big boss
Ventajas
-Comenzar con el software con bastante rapidez.
-Estimar calendarios y presupuestos con mayor precisión.
-Lograr un nivel de satisfacción del cliente más elevado que otros enfoques, ya desde el principio.

-Reduce riesgos del proyecto
-Incorpora objetivos de calidad
-Integra el desarrollo con el mantenimiento, etc.


-Mejora la motivación e implicación del equipo de desarrollo.

-Ahorrar tanto tiempo como costes

-Mayor velocidad y eficiencia.

-Eliminar aquellas características innecesarias del producto.

-Mejorar la calidad del producto.

-Alertar rápidamente tanto de errores como de problemas.
Desventajas
-Alterar el diseño del proyecto en cualquier etapa es muy complicado.
-Una vez que una fase se ha completado, es casi imposible de realizar cambios.
-Es absolutamente necesario reunir todos los requisitos iniciales.
-Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
-Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y dinero.

-Genera mucho tiempo en el desarrollo del sistema
-Modelo costoso
-Requiere experiencia en la identificación de riesgos



Número de integrantes de los equipos
5 integrantes aproximadamente.
7 integrantes aproximadamente.


¿En la construcción de qué tipo de aplicaciones se usa?




Nombre de una empresa que la emplea
calaméo



País que emplea dicha metodología




Ejemplo de metodología


Metodología en cascada

Resultado de imagen para metodologia de cascada
La metodología en cascada es un modelo lineal de diseño de software que emplea un proceso de diseño secuencial. En esta metodología el desarrollo va desde un punto inicial hasta llegar al punto final, por lo cual pasa por varios procesos los cuales son:

Planteamiento
Iniciación
Análisis
Diseño
Construcción
Pruebas
Implementación
Mantenimiento

La metodología en cascada da énfasis en la planificación de proyecto, por lo cual  antes de comenzar a realizar  cualquier tipo de desarrollo es necesario que tanto la visión como el plan estén claros.



Ventajas:

La metodología en cascada supera algunas de las limitaciones de otros métodos, los procesos de desarrollo que siguen la metodología en cascada tienden a ser más seguro, ya que existe una firme orientación al plan. Se dispone de una completa planificación y documentación que permite suplir a un miembro del equipo en caso de que abandone el proyecto.
  • Comenzar con el software con bastante rapidez.
  • Estimar calendarios y presupuestos con mayor precisión.
  • Lograr un nivel de satisfacción del cliente más elevado que otros enfoques, ya desde el principio.

Desventajas:

Este método es increíblemente rígido e inflexible, lo cual hace que tenga algunos inconvenientes como son:

  • Alterar el diseño del proyecto en cualquier etapa es muy complicado.
  • Una vez que una fase se ha completado, es casi imposible de realizar cambios.
  • Es absolutamente necesario reunir todos los requisitos iniciales.
  • Resulta muy difícil responder a los problemas que puedan surgir, ya que tanto la retroalimentación, como las pruebas se retrasan hasta estadios muy tardíos del desarrollo de proyecto.
  • Solucionar cualquier cuestión que se plantee requiere una cantidad sustancial de tiempo, esfuerzo y dinero.


La metodología en cascada no es ni mejor ni peor que otras, sólo hay que saber elegirla cuando resulta más conveniente su aplicación, en función del proyecto y sus necesidades.