DIAGRAMA DE CLASES

El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que
percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un
modelo de programación.

• La clase define el ámbito de definición de un conjunto de objetos.
• Cada objeto pertenece a una clase.
• Los objetos se crean por instanciación de las clases.

• Cada clase se representa en un rectángulo con tres compartimientos:
• Nombre de la clase
• Atributos de la clase
• Operaciones de la clases

SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado paraproyectos en entornos complejos, donde se necesita obtener resultados pronto, donde losrequisitos son cambiantes o poco definidos, donde la innovación, la competitividad, laflexibilidad y la productividad son fundamentales.

DRA: MODELO DRA

El desarrollo rapido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto.

Es una adaptación de "alta velocidad" del modelo de cascada. El proceso de DRA permite que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy corto de 60 a 90 días.

VENTAJAS

1. Es muy rápido.
2. Permite trabajar en él a varias personas a la vez

DESVENTAJAS

1. El enfoque DRA tiene inconvenientes para proyectos grandes, necesita suficientes recursos humanos para crear el numero correcto de equipos.
2. Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema, los proyectos fallarán.
3. El DRA sería inapropiado cuando los riesgos técnicos son altos.

RUP

El proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP).

Es un proceso desarrollado de software y junto con el Lenguaje Unificado de Modelado UML. Constituye la metodología estándar más utilizada para el análisis, implementación y documentación. 

LEAN

La metodología de desarrollo de software Lean es una translación de los principios y prácticas de la manufactura esbelta hacia el dominio del desarrollo de software. Adaptado del Sistema de producción Toyota, apoyado por una sub-cultura pro-lean que está surgiendo desde la comunidad ágil.

CASOS DE USO

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Un caso de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

• Actor.
• Casos de Uso.
• Relaciones de Uso, Herencia y Comunicación.

Elementos

• Actor:
  
  
  Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
  Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
  
  
• Caso de Uso:
  
  
  
  Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
  
  
• Relaciones:
  
  • Asociación 
    Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
  • Dependencia o Instanciación 
    Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
  • Generalización 
    Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
    Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
    extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
    uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
    De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y moldeamiento de clases, en donde esta la duda clásica de usar o heredar.
    
    

METODOLOGIAS ÁGILES 

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestasmetodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemosaquellas propuestas más tradicionales que se centran especialmente en el control del proceso,estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y lasherramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en  un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo

más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. En este trabajo se presenta resumidamente el contexto en el que surgen las

metodologías ágiles, sus valores, principios y comparación con las metodologías tradicionales 

ATRIBUTOS DE CALIDAD

 Existen diferentes clasificaciones y agrupaciones de atributos de calidad, algunas de las más representativas son:

• ISO-9126 Software Quality Model

• IEEE 1061

ISO 9126

• Funcionalidad

• Confiabilidad

• Facilidad de uso

• Eficiencia

• Facilidad de mantenimiento

Funcionalidad

Confiabilidad

Una vez el software se encuentra funcionando, según se especificó, la confiabilidad define la capacidad de un sistema de  mantener su nivel de servicio bajo condiciones definidas por periodos específicos de tiempo

La tolerancia a fallas se define como la habilidad del sistema para soportar fallas en sus componentes

Facilidad de Uso

Facilidad de uso de una funcionalidad dada la facilidad para aprender cómo utilizar el sistema hace parte de la facilidad de uso.

Eficiencia

Utilización de recursos del sistema para cumplir con su funcionalidad. Ejemplo: Utilización de disco, memoria, ancho de banda, procesador, etc. 

Facilidad de Mantenimiento

La habilidad para identificar y corregir un defecto dentro de un componente de software la facilidad de probar el sistema (testability) es una subcategoría de este atributo.

Portabilidad 

Habilidad del software para adaptarse a cambios en el ambiente o los requerimientos la adaptabilidad se considera una subcategoria de este atributo.

IEEE 1061

• Desempeño

• Confiabilidad

• Seguridad

• Seguro

Desempeño

Grado en el cual un sistema o componente cumple sus funciones dentro de restricciones dadas tales como velocidad, exactitud, o uso de memoria . Tiempo requerido para responder a un evento específico.

Número de eventos procesados en un intervalo dado de tiempo

Confiabilidad

Propiedad de un sistema tal que se puede confiar justificablemente en los servicios que este presta.

• Confiabilidad

• Disponibilidad - El sistema puede ser usado

• Confianza - Continuidad de servicio

• Seguro - No produce consecuencias catastróficas

• Confidencialidad - No ocurrencia de accesos no autorizados a la información

• Integridad - No ocurrencia de alteraciones no autorizadas de información

• Mantenibilidad - Aptitud para permitir reparaciones y evolución

Seguridad

Propiedad de un sistema contra el acceso, modificación o destrucción no autorizada de información.

• Confidencialidad

• Integridad

Seguro

Grado de confianza con el que un sistema es utilizado sin que ocasione accidentes (Safety-Critical).

• No existe riesgo ni pérdida de vidas humanas.

FASES GENÉRICAS DEL CICLO DE VIDA DEL SOFTWARE (CVS)

INGENIERÍA DE REQUISITOS O (REQUERIMIENTOS): 

Lo primordial  y más importante es satisfacer las necesidades del cliente   estas deben ser Explícitas  e Implícitas , y se dividen en las siguientes etapas:

1. RECONOCIMIENTO O LEVANTAMIENTO DE REQUISITOS: En  esta etapa se recomienda las preguntas abiertas, sin improvisación  y al momento de realizar las entrevistas ir preparado con preguntas objetivas y claras que permitan tener el mayor conocimiento de los requisitos del Software a elaborar, a continuación se detallan los pasos a seguir para el iniciar esta fase:

• Entrevistas 
• Preguntas Abiertas
• Preguntas Cerradas
• Lluvia de Ideas 
• Rueda Delphi
• Acta de Salida (Documento con especificación detallada de requísitos)
• Validación por parte del cliente 

                     ESPECIFICACIONES DE LOS REQUISITOS 

• FUNCIONALES: Son los que describen que va  a hacer la aplicación o el sistema. y deben ser descritos en forma clara.

• NO FUNCIONALES: Son los que describen características o propiedades. Dentro de esta especificación  y asociados a atributos de calidad  se encuentran:                                               

• Disponibilidad
• Confiabilidad
• Escalabilidad
• Seguridad
• Seguro
• Mantenibilidad
• Usabilidad
• Portabilidad
• Modificabilidad

CICLOS DE VIDA DEL SOFTWARE

MODELO CASCADA: 

Es un paradigma que sugiere un enfoque sistemático, secuencial hacia el desarrollo del Software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación , el modelado, la construcción y el despliegue para culminar en el soporte del Software terminado.

 MODELO ESPIRAL: 

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de Ingeniería de Software concurrente y a la vez con muchos usuarios. Se caracteriza principalmente por:

• Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.

•  Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.