DIAGRAMA DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

• Clases: Patrón o modelo a crear objetos
• Atributos: Características de la clase
• Visibilidad: Publica (+), Privada (-), Protegida (#), Paquete (~)
• Interfaz: clases que definen un juego de operaciones externas accesibles pero sin métodos. 
   

Herencia: permite organizar las definiciones de la clase para simplificar y facilitar su implementación.

Asociación: es un término formal para un tipo de relación.

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Actor: Algo con comportamiento, como una persona, un sistema de computo , una organización, etc. Ej.: Un cajero

Escenario: Una secuencia dada de acciones e interacciones entre actores y el sistema involucrado. Ej.. Retiro exitoso de un cajero automática.

Casos de uso: Un conjunto compuesto de escenarios exitosos y fallidos que están interrelacionados entre si, y describen el uso que los actores le  dan a un sistema para lograr una meta. Exite 3 tipos, estos son:

• Resumidos: Normalmente de un párrafo y solo contienen el escenario principal
• Casuales: Uno o pocos párrafos escritos  de forma informal
• Completos: Son mas  elaborados. Todos los pasos y sus variantes son detalladas

Diagramas de Casos de Uso: El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Relaciones del diagrama de casos de uso:

• Arco de comunicación – Asociación: camino de comunicación entre un actor y un caso de uso.
• Incluye: Indica que un caso de uso es incluido en otro. Normalmente ocurre cuando unos casos de uso comparten unos pasos comunes. El caso de uso incluido es el factor común del comportamiento compartido.
• Generalización: Indica que un caso de uso es una variante de otro. El caso de uso especializado puede variar cualquier aspecto del caso de uso base.
• Extiende: El caso de uso base declara un conjunto de puntos de extensión. El caso de uso especializado solo puede alterar el comportamiento de los puntos de extensión marcados.

PROCESO UNIFICADO

Unificación de tres metodologías de desarrollo basadas en el paradigma orientado a objetos. Es un conjunto de actividades para transformar los requisitos de usuario en un sistema software, Basado en componentes interconectados a través de interfaces.

Características:

• Dirigido por casos de uso: Conducen el proceso de desarrollo, los desarrolladores crean modelos de diseño e implementación que realizan los casos de uso 

• Centrado en la arquitectura: Es una vista del diseño completo que hace visibles las características principales. En este se crear una arquitectura inicial donde no específica de los casos de uso.

• Iterativo e incremental: Una iteración produce un incremento donde cada fase e iteración se centra en disminuir algún riesgo y concluye con un hito bien definido, todas las iteraciones son planificadas y controladas.

Ideas: Cualquier interacción del sistema con el usuario es un caso de uso

Actor: alguien o algo

Caso de uso: Es una función del sistema que da al usuario un resultado útil, es este el que captura los requisitos funcionales.

Las 4 "P"

• Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versión de un producto.
• Proceso:  Un proceso de ingeniería de software es una definición del conjunto de actividades necesarias para transformar los requisitos de usuario en un producto.  Un proceso es una plantilla para crear proyectos.
• Producto: Artefactos que se crean durante la vida del proyecto, como los modelos, código fuente, ejecutables, y documentación.  El resultado de llevar a cabo un proceso software dentro de un proyecto concreto.
• Personas: Los principales autores de un proyecto de software son loas arquitectos, desarrolladores, ingenieros de prueba y el personal de gestión que les da soporte, además de los usuarios, clientes, y otros interesados. Las personas son realmente seres humanos, a diferencia del termino abstracto “trabajadores” 

Estructura del PU : Fases e iteraciones

Fase: intervalo de tiempo entre dos hitos importantes del proceso durante el cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman 

decisiones sobre si pasar a la siguiente fase. 

4 fases: 

•  Iniciación (inception): Establecer la visión, el alcance y el plan inicial del proyecto. 
•  Elaboración (elaboration): Diseñar, implementar y probar una arquitectura correcta, y completar el plan del proyecto. 
•  Construcción (construction): Desarrollar el sistema (construir la primera versión operativa). 
•  Transición (transition): Proporcionar el sistema a sus usuarios finales. 

Iteración: representa un ciclo de desarrollo completo, desde la captura de requisitos en el análisis hasta la implementación y pruebas, que produce una versión (interna o externa) de un 

producto ejecutable, que constituye un subconjunto del producto final en desarrollo. 

Iteración genérica (similar al modelo en cascada): 

•  Planificación
•  Flujos de trabajo fundamentales: requisitos, análisis, diseño, implementación y pruebas
•  Evaluación 

FASES GENERICAS DEL CICLO DE VIDA DEL SOFTWARE 

• Analisis
• Diseño
• Codificacion
• Pruebas
• Puesta marcha
• Mantenimiento

"INGENIERÍA DE REQUISITOS"

1. Reconocimiento de los requisitos o levantamiento

• Entrevistas (abiertas, cerradas)
• Lluvia de ideas
• Delphi

2. Documentos especificos

• Validar (cliente)

REQUERIMIENTOS FUNCIONALES

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos.

REQUERIMIENTOS NO FUNCIONALES

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema. Como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.

ATRIBUTOS DE LA CALIDAD

• Disponibilidad: hace referencia a la posibilidad de que algo, un producto o un fenómeno, esté disponible de ser realizado, encontrado o utilizado.

• Confiabilidad: se puede definir como la probabilidad en que un producto realizará su función prevista sin incidentes por un período de tiempo especificado y bajo condiciones indicadas.

• Escalabilidad: La escalabilidad es la capacidad de mejorar recursos para ofrecer una mejora (idealmente) lineal en la capacidad de servicio. La característica clave de una aplicación es que la carga adicional sólo requiere recursos adicionales en lugar de una modificación extensiva de la aplicación en sí.

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

• Seguro: Grado de confianza con el que un sistema es utilizado sin que ocasione accidentes.

• Mantenibilidad: Aptitud para permitir reparaciones y evolución. La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno.

• Usabilidad: Está vinculada, a la simpleza, la facilidad, la comodidad y la practicidad. En otras palabras, la noción tiene relación con la eficacia percibida de un objeto y la posibilidad de aprovechar todo su potencial.

• Potabilidad: Habilidad del software para adaptarse a cambios en el ambiente o los requerimientos.

• Modificabilidad: Se refiere al desarrollo de software flexible para adecuarse a cambios para extender, cambiar o eliminar funcionalidades del sistema.

• Rendimiento: Se refiere a la proporción que surge entre los medios empleados para obtener algo y el resultado que se consigue.

• 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.

• Eficiencia: Utilización de recursos del sistema para cumplir con su funcionalidad.

Crisis del Software:

Se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad.

Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.

Ciclos de Vida del Software:

Describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
• Diseño general: requisitos generales de la arquitectura de la aplicación.
• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
• Programación (programación e Implementación): es la Implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
• Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
• Implementación
• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Modelo en cascada:

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

Ventajas del modelo cascada:

1. Modelo y planificación fácil y sencillos.

2. Sus fases son conocidas por los desarrolladores.

3. Los usuarios lo pueden comprender fácilmente.

Desventajas del modelo cascada:

1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.

2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.

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 captura algunos principios básicos:

•  Decidir qué problema se quiere resolver antes de viajar a resolverlo.
•  Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
•  Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
•  No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

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

Método:

• Proceso o camino sistemático establecido para realizar una tarea o trabajo con el fin de alcanzar un objetivo predeterminado.
•  Modo de decir o hacer algo con orden.  Procedimiento científico seguido en la ciencia para hallar la verdad.
•  Un  procedimiento que se usa para realizar una tarea específica en la clase o módulo.
• Procedimiento para alcanzar algo que se adopta para enseñar o educar.

Procedimiento:

• Sucesión cronológica de operaciones concatenadas entre sí, que se constituyen en una unidad de función para la realización de una actividad o tarea específica dentro de un ámbito predeterminado de aplicación. 
• Todo procedimiento involucra actividades y tareas del personal, determinación de tiempos de métodos de trabajo y de control para lograr el cabal, oportuno y eficiente desarrollo de las operaciones.
• Un método, función o propiedad de una clase o módulo.

Herramienta:

Subprograma o módulo encargado de funciones específicas y afines entre sí para realizar una tarea.

Framework  :

(plataforma, entorno, marco de trabajo) Es  un framework es una estructura de soporte definida, en la cual otro proyecto de software puede ser organizado y desarrollado.

Los frameworks suelen incluir:

• Soporte de programas.
• Bibliotecas.
• Lenguaje de scripting.
• Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de programas.

Los frameworks permiten:

• Facilitar el desarrollo de software.
• Evitar los detalles de bajo nivel, permitiendo concentrar más esfuerzo y tiempo en identificar los requerimientos de software.