miércoles, 2 de julio de 2014

PATRONES DE DISEÑO DE SOFTWARE


Los Patrones de diseño están basados en la funcionabilidad.

Encapsula lo que varia.

Favorece la composición sobre la herencia.

En este post se definen 2 patrones que sirven para el buen desarrollo de software, ademas vienen inmersas algunas pruebas que pudieran llevarse a cabo para tener la menor cantidad de errores. 

Patrón Estrategia

El objetivo es encapsular el comportamiento, explotar el polimorfismo programando supertipos en lugar del objeto usado en tiempo de ejecución.

Estrategia: (Primer patrón de diseño de software) define una familia de algoritmos, encapsula cada uno y los hace intercambiables.

Los patrones no son una librería, son una forma de resolver problemas, estructurar, objetos y clases, los frameworks y librerías no son patrones de diseño, son soluciones particulares que usan aveces patrones.

Patrón Observador
Define una dependencia de uno a muchos entre objetos de tal forma que cuando un objeto cambia su estado, todos los demás componentes reciben una notificación con dicha acción.

Cada sujeto puede tener muchos observadores.

Todos los observadores deben de emplear la interfaz.

El observador se asocia con un objeto en particular.

Las Pruebas de Software

Las estimaciones de esfuerzo depende del volumen del proyecto, corregir un problema durante la fase de operación es mas costoso que corregirlo al momento del diseño.

En las pruebas del sistema no se basan en resultados, ni validación estadística sino que se busca identificar los problemas.

El siguiente es un listado de algunas pruebas para el diseño de software

  •  Prueba Eye Tracking.
  •  Revisión Heurística.
  •  Inspección mediante checklist o estándares.
  •  Análisis de log file.
  •  Inspección de la consistencia.
  •  Análisis de los legs del servidor.


miércoles, 25 de junio de 2014

DIAGRAMAS UML (MODELADO DE CLASES)


Diagramas de clases (ejemplos y conceptos)

Las clases son el centro operativo de un sistema orientado a objetos.

El sistema se compone de pequeñas colecciones llamadas "Objetos".

Las clases describen diferentes tipos de objetos que puede obtener un sistema.

"Una clase" es una familia de objetos.

"Un objeto" no es una clase, tan solo es una versión de ella.


  • El nombre de la clase son -sustantivos-
  • Los objetos son -instancias de una clase-
  • Los métodos son -verbos-

Ejemplo:

Modelar  -la clase lavadora-

Atributos(características)          Comportamiento

   * modelo                                * sacar ropa
   * marca                                  * agregar ropa
   * numero de serie                   * agregar detergente
   * capacidad 



Todos los atributos de la clase propuesta deben aplicarse a todos los objetos de la clase.
Los tributos describen el significado de la clase, para determinarlos pueden formularse las siguientes preguntas:

  • ¿Cómo se describe?
  • ¿Cómo se describe en el contexto del problema?
  • ¿Qué debo saber para poder funcionar?
  • ¿Cuáles de mis estados necesito conocer para funcionar?
  • ¿Qué estados deben estar como miembros de la clase?

La multiplicidad permite especificar que un atributo es una colección de datos,se representa por números para indicar su cantidad exacta o * para indicar que son demasiados; este es un concepto mas para los diagramas de clases.


Existen otros conceptos que se utilizan en este tipo de diagrama como lo son:

Herencia: cuando una clase hereda atributos a otra clase, esta contendrá todos los métodos de la clase anterior.

Polimorfismo: son métodos llamados igual pero en sentido diferente.

Regresando a los atributos, estos pueden ser declarados dentro de la clase como:

Públicos (+): significa que estos serán accesibles por métodos de la misma clase.

Protegidos (#): significa que serán accesibles por métodos de la clase.

Privados(-): significa que solo podrán ser accedidos por la clase donde fueron declarados y no sera posible para todas aquellas clases ajenas.

Estas son algunas de las relaciones que se utilizan entre las clases.


Asociación: se utilizan cuando una clase necesita trabajar con un objeto de otra clase.
Dependencia: esta relación declara que una clase requiere conocer acerca de otra para usar sus objetos.

Herencia o generalización: define la herencia entre clases.

Composición: palabra clave "tiene un", su relación es muy fuerte.

Agregación: indica que una clase tiene objetos que pude compartir con otras clases, palabras clave "tiene" o "esta formado" 






jueves, 19 de junio de 2014

DIAGRAMAS PARA EL MODELADO


Dentro de la planeación que se realiza antes de llevar a cabo un proyecto, se encuentra inmersa el orden del sistema, es decir, como es que vamos a ordenar y manipular cada una de las actividades a realizar en el proceso del armado de sistema.

Para esto empleamos los famosos "diagramas de actividades", mejor conocidos en el ámbito computacional, estos reflejan como el sistema va a lograr las metas requeridas.

Las acciones tan solo son un paso dentro del proceso de toda una actividad, mientras que una actividad es el proceso de llevar a cabo algo.

Para los diagramas de actividades emplean lo siguiente:


Acciones o tareas: pasos a seguir para desarrollar una actividad.


Rutas o caminos: flechas que nos sirven para guiar nuestro proceso.


Decisión: tomar una u otra opción.


Unión: aquí convergen las decisiones, para continuar con el proceso. 


Fork: flujo donde se separan en 2 caminos.

Join: se unen los caminos en una sola acción.

Sale señal: emerge una acción.


Entra señal: recibe una acción.


Estas son solo por mencionar algunos de los elementos básicos que se utilizan para el desarrollo de los diagramas de actividades.

Como sugerencia pueden utilizar la herramienta de YED para modelar esto.

Ejemplo:













miércoles, 11 de junio de 2014

MODELADO DE TAREAS

El modelado de tareas como tal es un método que se necesita para el desarrollo de software; como su nombre lo menciona, lo que se pretende es que el ingeniero de software tenga la habilidad para poder definir cada una de las tareas que se le solicitan, ademas de agregar las que crea conveniente, de esta forma obtendrá un listado de las cuales habrá de ordenar y modelar para el buen y optimo funcionamiento del sistema.

Este método esta basado en las siguientes características:

El modelado de tareas describen cada una de las actividades del usuario.
el propósito en general es indicar como las actividades se deben realizar para obtener un nuevo sistema.

Pueden ser representadas en diversos niveles de abstracción.

         *Alto nivel: son las actividades de las principales tareas.
         *Bajo nivel: las actividades se presentan con una granularidad pequeña.

Dentro de este modelado de tareas, podríamos emplear el uso de una herramienta denominada "ConcurTask Trees (CTT)" .

-Esta herramienta es de sintaxis gráfica.
- Esto facilita el uso y sobre todo su comprensión.
- Aquí cada tarea debe ser especificada con : un identificador, nombre, categoría, tipo, referencia, frecuencia de uso, plataforma, donde se usa, anotaciones informales, precondiciones.

He aquí algunas de las categorías para trabajar.

Interacción



Aplicación


Usuario


Abstracta



Este es un pequeño "árbol", donde se muestran cada uno de ellos.




Prototipo

Inmediatamente después de definir requerimientos, políticas, visión, modelado de tareas, entre otros aspectos, viene de la mano el prototipo, este es una estrategia para enfrentar la complejidad de lo imprescindible, ademas este no debe ser completo, tiene que ser fácil de modificar y que por supuesto tendrá una caducidad dado que solo sera una "versión de prueba".

los prototipos son como preguntas.
1.- ¿Cómo debe lucir?
2.- ¿Cómo debe funcionar?
3.- ¿Cómo debe ser la experiencia del usuario?

Estas son tan solo algunas que podrían formularse para ayudar a definir y crear el prototipo.

Luego de esto viene la "Arquitectura de Software", ésta es caracterizada por: 

*El sistema debe ser amable y atento con el usuario.
*Tiene que satisfacer todo imposible.
*La arquitectura conlleva: documentación, planos y especificaciones que describen el objeto a construir.

Esta "Arquitectura" esta basada prácticamente en el diseño de un todo, es decir, es la base, la idea de lo que se quiere construir, con todo lo anterior concluimos que es necesario llevar una secuencia de procesos, para el buen desarrollo de un software, es vital llevar una serie de pasos que nos orienten a terminar satisfactoriamente cada uno de los requisitos de sistema, de tal manera que el cliente quede sumamente satisfecho.

miércoles, 4 de junio de 2014

TIPOS DE DESARROLLO Y REQUERIMIENTOS

Tipos de Desarrollo

Dentro de la Ingeniería de Software se necesita el mejor desempeño en las actividades laborales que este conlleva, se necesita de una buena organización, optimización y un buen desarrollo de habilidades y métodos. Es por eso que a continuación se listan algunas características en los tipos de desarrollo.

*Métodos Clásicos de Desarrollo de Software*

-Difieren en su naturaleza.
-Poseen un espíritu normativo.
-Comienzan con la licitación y el análisis completo de los requerimientos del usuario.
-Los ingenieros integran sus ideas.
-Los programadores implementan el diseño.
-Legislación negativa.
-Crisis de confianza en los procesos regidos por metodologías prescriptivas en el análisis de requerimientos.

*Métodos Ágiles de Desarrollo de Software*

-Se promueve la documentación.
-Se planifica y reconoce los limites de planificación.
-"La gente es el primer factor de éxito de un proyecto de software".
-No necesitan de desarrolladores brillantes, sino alguien que se adapte ante cualquier circunstancia.
-No se producen documentos a menos de que sean necesarios.
-Los documentos deben ser cortos y centrarse en lo fundamental a atacar.
-Colaboración con el cliente, esta colaboración entre ambos será las marca inicial.
-El Desarrollo Ágil de software es un marco de trabajo conceptual.
-Su meta al final del día es conseguir un "demo" sobre lo que se esta trabajando.
-Los métodos ágiles enfatizan que el software funcional es la primera medida del progreso.

A groso modo se puede deducir que los proyectos que usan métodos ágiles han logrado un nivel de madurez mayor, ademas de muy buenos resultados, a comparación a los que se han elaborado utilizando los métodos clásicos, aunque esto depende del tipo de organización que se maneje dentro del  Desarrollo de Software.

(2)

*Ingeniería de Requerimientos*

En la Ingeniería de Software, ademas de necesitar lo antes ya mencionado (en otras entradas), también necesita una serie de requisitos que serán propiamente indicados por el cliente que solicita el proyecto y ademas de algunos otros requerimientos que vienen implícitos en él, es decir, "El Desarrollador" será capaz de interactuar con el cliente para llegar a un acuerdo y aclarar los requerimientos que su sistema necesita, ya sean explícitos o implícitos.
(1)

Ciclo de Vida 

1.- Ingeniería de Requerimientos.
2.- Diseño.
3.- Complementación.
4.- Validación.
5.- Liberación.
6.- Mantenimiento.


De acuerdo al Ciclo de Vida, mencionado aquí arriba, los requerimientos sin duda alguna son el primer paso para el buen manejo de un proyecto.

Los Requerimientos facilitan en gran medida el mecanismo para comprender lo que quiere el cliente analizando todas sus posibles soluciones.

Existen los requerimientos:

Funcionales.- Son los que dicen que debe hacer el sistema, en el sentido del servicio.

No funcionales.- Son las características del sistema como la mantenibilidad, Sistema Operativo, etc.

Definición de Requisito:

Es una capacidad que el sistema debe tener porque el cliente lo ha pedido explícita o implícitamente, la determinación de requerimientos es el primer paso en la construcción de la aplicación.

Los requisitos son de vital importancia ya que permite gestionar las necesidades del proyecto, mejora la capacidad de predecir cronogramas, mejora la calidad del software si se cumple con todos y cada uno de los requisitos solicitados por el cliente, ademas de que evitas los rechazos de usuarios finales debido a que obliga a los usuarios a considerar sus requerimientos cuidadosamente.

(3)
Lo siguiente es una serie de pasos que pueden ayudar a determinar los requerimientos necesarios.-Identificar lo que se necesita, es decir, sus requisitos.
-Análisis de requisitos y negociación.
-Especificación de requisitos.
-Modelado del sistema.
-Validación de requisitos y gestión de los mismos.





La obtención de requisitos no es para nada fácil de obtener por diversas razones:
*La naturaleza de los requisitos es cambiante.
*Surgen nuevos requisitos.
*El cliente puede no tenerlos claros.

La clave para poder obtenerlos de manera más sencilla es "La Comunicación"

De esta manera concluimos que podemos elegir alguno de los tipos de desarrollo antes mencionado de tal forma que la organización interna de quienes desarrollan el software se vea lo mejor coordinada posible, tomando en cuenta los requerimientos necesarios para el buen funcionamiento de todo lo que se realice.

(1)http://www.infinitumpage.mx/TMX5557343198/WEB/
(2)http://www.intergrupo.com/blog/mobile/desarrollo-agil-software-mantenimiento.aspx
(3)http://requerimientossoftware.blogspot.mx/

miércoles, 28 de mayo de 2014

LA ADMINISTRACIÓN DENTRO DE LA INGENIERÍA DE SOFTWARE (IS)

La administración de proyectos en la ingeniería de software implica sin duda alguna la planificación, supervisión y el control de todo aquel que labore en el área.

(1)
El hecho de tener una buena administración dentro de la empresa se ve reflejada en todo ámbito, la construcción de un sencillo programa como hasta uno mas dedicado es una actividad muy compleja, particularmente si trabaja mucha gente en el, ya que como puede tardar unos días como bien puede llevarse un tiempo indefinido, es por esta sencilla pero elaborada razón, por la cual se debe gestionar con pronta e inmediata gestión cada uno de los proyectos que se desee desarrollar.

La gestión esta basada básicamente en todas las actividades y tareas que serán ejecutadas por una o mas personas con el simple propósito de controlar y planificar el proyecto para alcanzar el objetivo esperado. Algunas de las actividades que lleva a cabo la gestión de proyectos es:

* La Planificación: que es la determinación de un curso de acción para alcanzar los objetivos organizacionales. Involucra la especificación de objetos y metas para un proyecto, en esta parte debe planearse que es lo que se realizará y que se entregará al final del trabajo.

* La Organización: es el arreglo de las relaciones entre las diversas áreas para el cumplimiento del objetivo.
* Staffing: es la selección y entrenamiento del personal para desempeñar en las diversas áreas de toda la organización.

(2)
* La Dirección: es todo aquello que va a mover a los trabajadores a realizar sus actividades con la mejor disposición y los mejores resultados, es decir . la "Motivación" que impulsara a cada uno de ellos a seguir realizándose en su área laboral.

* El Control: es la medición y evaluación del desempeño de las actividades a través de los objetivos planeados.

-Habilidades de Gestión-

*Habilidades Técnicas: conocimiento y pericia en actividades, esto implica el hecho de trabajar con herramientas y técnicas especificas.

*Habilidades Humanas: es la habilidad para relacionarse y trabajar con otras personas.

*Habilidades Conceptuales: es la habilidad para reconocer y entender las relaciones entre todos los elementos que conlleva el proyecto.

*Habilidades de Diseño: la habilidad para generar una solución practica a un problema.

En general debe existir una serie de recursos fundamentales para la buena relización de un proyecto, desde el hecho de observar a la gente y al entorno para poder así darle un enfoque mas particular y en beneficio de los demás, también existe la importancia de ser curioso, experimentar y de acuerdo a una serie  de eventos deducir una posible solución, la cual a su vez podría ser la mas factible, ademas se debe uno plantar una y tantas preguntas como se pueda para poder concluir en algo y que las respuestas obtenidas sirvan como base para el buen desarrollo de la aplicación a tratar.
(3)

(1) http://www.eoi.es/portal/guest/actualidad/evento/2361/gestion-de-riesgos-en-los-proyectos-segun-metodologia-pmi-sede-eoi-andalucia
(2) http://masorganizacional.blogspot.mx/2011/09/gestion-por-competencias.html
(3) http://gestion-ambiental-biblioteca.blogspot.mx/

Información 
-Material de clase,Ingeniería de Software, Juan Gonzalez.

martes, 20 de mayo de 2014

EL SOFTWARE Y SUS IMPLICACIONES

(1)
Uno de los principales problemas en el desarrollo de software de nuestra actualidad, es que en muchos proyectos los encargados de desarrollar el software se concentran demasiado en la programación y escritura de su código, tan pronto se los definen, que olvidan otros factores que influyen en el buen desarrollo del software. Al tomar en cuenta solo algunos requerimientos, no evaluar o analizar el trabajo a desarrollar de manera exhaustiva, trae consigo muchos problemas, como puede ser la perdida de grandes cantidades monetarias o hasta la perdida de capital humano, según sea el caso, es por ello que al momento de que se pretenda elaborar un software para algún cliente es de vital importancia revisar, analizar y realizar todas las pruebas pertinentes para así poder entregar un buen trabajo sin consecuencias desastrosas.

De esto deriva un término llamado "CRISIS DEL SOFTWARE" y algunos de los "síntomas" para detectarlo son las siguientes:

*Baja calidad del software.
*Tiempo y presupuesto excedido.
*Confiabilidad cuestionable. 
(2)
*Altos requerimientos de personal para su desarrollo y mantenimiento.

Existen muchas otras razones que pueden ser propuestas como causa de la crisis, no son mutuamente excluyentes, de hecho, es posible que la verdadera causa sea una mezcla de todas ellas, sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de de financiación de la actividad científica.

 La crisis se manifestó a sí misma en varios aspectos, por ejemplo: 
*Proyectos gestionados con un sobre-presupuesto. 
*Proyectos gestionados con un sobre-tiempo. 
*Software de baja calidad. 
*El software a menudo no satisfacía los requerimientos deseados. 
*Los proyectos son inmanejables, con un código difícil de entender. 

Como una posible solución es que al momento de que defina un proyecto, analizar y verificar cada uno de los escenarios posibles en los que se puede o no desarrollar, tratar de obtener los errores antes de que suceda algún incidente, conocer y entender cada uno de los requerimientos del sistema, los requerimientos del software, el diseñar, analizar, codificar, probar en diferentes instancias, son sólo algunos de los pasos que deberían llevarse a cabo antes de exponer el proyecto ante la sociedad, pues no solo es codificar y "Trabajo Terminado", sino que va mas allá.

Imagenes:
(1)http://www.bolivarvalera.com/icms/es/2014/noticias/7170/eeuu-respalda-revelar-vulnerabilidad-en-software.do#.U3tvotJ5PXs
(2)http://qualityandprogramming.blogspot.mx/2012/03/crisis-del-software.html