domingo, 16 de junio de 2019

Examen Final - 2014 - Sistemas 2


Parte I. Responder las siguientes consignas (40 puntos)
Responder con brevedad en no más de 5 (cinco) renglones, pero con precisión y de forma justificada, a cada una de las consignas que se plantean. Se penalizará la falta de síntesis.
  1. ¿En qué circunstancias se utiliza la relación de inclusión en Casos de Uso?¿Por qué?
  2. Describa al menos 4 consideraciones a tener en cuenta para un buen diseño de la GUI
  3. ¿En qué se diferencian el Diagrama de Clases UML del Diagrama de Clases del Dominio?
  4. ¿Qué beneficios aportan los Patrones de Diseño?

Parte II – Testing (10 puntos)
Dada la siguiente registración para obtener una cuenta de Hotmail, marque con una X según considere Verdadero o Falso cada postulado:




V
F
No es necesario probar el botón “Comprobar disponibilidad” pues siempre funciona


Una de las pruebas a realizar es la de completar todos los campos con datos erróneos


No es necesario probar la visualización de la página en otro navegador diferente del Internet Explorer v9


Se debe comprobar el no ingreso en la base de datos de registros duplicados de Windows Live ID


No es necesario probar el botón “Aceptar” pues siempre funciona






Diagramas UML

Enunciado
El proceso manual de esquilado del mega emprendimiento lanero del sr. B.B. Wolf en la Patagonia Argentina es conducido por dos personas: el esquilador y un ayudante. Entre ambos es mucho más sencillo controlar a las ovejas ariscas y el tiempo total que dura la esquila se reduce a casi la mitad si se lo compara con el mismo proceso ejecutado por una sola persona. El esquilador y el ayudante reciben a cada oveja y realizan una última revisión para saber si la oveja está o no en condiciones de ser esquilada. En líneas generales todas las ovejas son esquiladas, pero de vez en cuando ocurre que alguna hay que separarla por distintas cuestiones. Si la oveja es separada, el proceso termina aquí y el dúo de trabajadores busca a la siguiente. Las ovejas son esquiladas entre ambos y, cuando se termina el trabajo, el ayudante lleva la lana de la oveja al depósito, en donde se controla. Este control incluye el pesado de la lana y su clasificación de acuerdo a la calidad de la misma. Al ayudante se le da una etiqueta autoadhesiva con el resumen de lo que acaba de entregar. Mientras tanto, el esquilador conduce a la oveja a una evaluación donde se corrobora, entre otras cosas, el estado general de la oveja y, fundamentalmente, que no se encuentre lastimada. Al esquilador también se le da una etiqueta autoadhesiva con el detalle del estado de la oveja. Cuando el esquilador y su ayudante se encuentran nuevamente pegan en una planilla las etiquetas que les dieron para consolidar la información. Si necesitan dejar asentada alguna observación lo hacen en la misma planilla. Luego de esto se dirigen a buscar la siguiente oveja para continuar su trabajo.

Parte III – UML – Diagrama de Actividades (20 puntos)
Con la información del último párrafo construya un diagrama de actividades que muestre el trabajo del esquilador y su ayudante con una oveja

El empresario B. B. Wolf mostró un interés particular y personal por incursionar en la venta retail de ropa hecha con lanas de sus empresas. Para esto adquirió “La Ovejita Tierna”, un comercio minorista en Chubut pensando en convertirlo en una franquicia en el término de un año.
El sr. Wolf tiene la creencia de que la base de un buen negocio es el control detallado del inventario y propone un esquema de trabajo en donde que cada sucursal podrá tener varios depósitos (como mínimo tendrá uno). Cada depósito tendrá un inventario y éste contendrá las prendas. La empresa trabajará solamente tres clases de prendas: pullovers, chalecos y camperas. El costo de cada prenda se compone a través de dos variables: El costo de materiales y de mano de obra. El costo de los materiales depende del talle, que puede ser S, M o L. El costo de mano de obra depende de la clase de prenda, ya que la complejidad varía de clase a clase y nada tiene que ver el talle.


Parte IV – UML – Diagrama de Clases (30 puntos)
Realizar un diagrama de clases que permita resolver la problemática de calcular el costo del inventario de un depósito de una sucursal. Suponga la existencia de una clase Sucursal que tiene un método cuya firma es CalcularCosto(Deposito : Deposito) : double

viernes, 14 de junio de 2019

Modelo Incremental - Sistemas 2

Modelo Incremental

Descripción


  • Combina elementos del modelo lineal con la filosofía de creación de prototipos.
  • El primer incremento a menudo es un producto esencial(núcleo).
  • A partir de la evaluación se planea el siguiente incremento y así sucesivamente.
  • Es interactivo por naturaleza
  • Es útil cuando el personal no es suficiente para la implementación completa


Ventajas

  • Se puede financiar el proyecto por partes.
  • Apropiado para proyectos grandes de larga duración.
  • No se necesita tanto personal al principio como para una implementación completa.


Modelo en espiral - Sistemas 2

Modelo en espiral

Descripción

Propuesto inicialmente por Boehm en 1988.

  • Desarrollo cíclico (iterativo) donde en cada ciclo se llevan a cabo 4 tareas:
    • Determinación de objetivos, alternativas y restricciones
    • Evaluación de alternativas, análisis y control de riesgos.
    • Desarrollo y verificación del producto.
    • Planificación del siguiente ciclo (fase).
  • Cada ciclo corresponde a una fase del proyecto

En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:


Objetivos: Se hacen entrevistas a los clientes,se les hace rellenar cuestionarios,etc.

Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista:
  • Características del producto.
  • Formas de gestionar el proyecto.


Restricciones:
  • Desde el punto de vista del producto:Interfaces de tal o cual manera,rendimiento,etc.
  • Desde el punto de vista organizativo: Coste,tiempo, personal, etc.


Riesgos: Lista de riesgos identificados.

Resolución de riesgos: La técnica más usada es la construcción de prototipos.

Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.

Planes: Lo que se va a hacer en la siguiente fase.

Compromiso: Decisiones de gestión sobre como continuar.

Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.


Características


  • En cada giro se construye un nuevo modelo del sistema completo.
  • Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada,evolutivo)
  • Mejor modelo para el desarrollo de grandes sistemas.
  • El análisis de riesgo requiere la participación de personal con alta cualificación.

Ventajas

  • No necesita una definición completa de los requisitos para empezara funcionar.
  • Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
  • El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).
  • El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

Desventajas 

  • Es difícil evaluar los riesgos.
  • Necesita de la participación continua por parte del cliente.
  • Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

 



Modelo de Cascada - Sistemas 2

Modelo de Cascada

Descripción


Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Después de cada etapa se realiza una revisión para comprobar si se puede pasara la siguiente.

Estructura Modelo en Cascada(Bennington 1956)

El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:



Ingeniería y Análisis del Sistema:  Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software,así como la función,el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software,el detalle procedimental y la caracterización de la interfaz.

Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea.

Prueba: La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo(sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcional eso del rendimiento.

Características 

  • Es el más utilizado.
  • Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios.
  • Para que el proyecto tenga éxito deben desarrollarse todas las fases.
  • Las fases continúan hasta que los objetivos se han cumplido.
  • Si se cambia el orden de las fases, el producto final será de inferior calidad.


Ventajas

  • La planificación es sencilla.
  • La calidad del producto resultante es alta.
  • Permite trabajar con personal poco cualificado.



Desventajas

  • No refleja realmente el proceso de desarrollo del software
  • Se tarda mucho tiempo en pasar por todo el ciclo
  • Perpetua el fracaso de la industria del software en su comunicación con el usuario final
  • El mantenimiento se realiza en el código fuente
  • Las revisiones de proyectos de gran complejidad son muy difíciles
  • Impone una estructura de gestión de proyectos

La metodología en cascada se suele emplear, especialmente, en aquellos proyectos cuyos requisitos y procesos se pueden describir de forma precisa durante la fase de planificación, en los que cabe suponer que las hipótesis no van a sufrir una gran variación durante el transcurso del proyecto. Los procedimientos estrictamente lineales se adaptan, así, especialmente bien a proyectos de software pequeños, sencillos y claramente estructurados. A esta misma conclusión llegó Royce en los años 1970. Por este motivo, la alternativa al procedimiento lineal que propuso, y que más tarde se conocería como waterfall model, incluía tres ampliaciones principales:

Verificación tras cada fase de proyecto

Según Royce, los resultados de cada una de las fases de proyecto se deben comparar y verificar inmediatamente con los documentos elaborados previamente. Es decir, inmediatamente después de desarrollar un módulo, por ejemplo, se debería garantizar que este cumple con las exigencias definidas con anterioridad sin esperar a que concluya el proceso de desarrollo.

Al menos, dos iteraciones

Según Royce, el modelo se debería ejecutar en, al menos, dos ocasiones: primero para elaborar un prototipo y, a continuación, para desarrollar el producto de software en sí.

Pruebas que incluyen al usuario final

La tercera ampliación del modelo en cascada propuesta por Royce en su ensayo es una medida que, a día de hoy, se ha convertido en un procedimiento estándar en el desarrollo de productos: la inclusión del usuario final en el proceso de producción. Royce propone incluir al usuario en tres momentos diferentes del proceso de desarrollo de software: durante la planificación del software en la fase de análisis, entre el diseño del software y su implementación y en la fase de prueba que precede al lanzamiento del software.

Procedimientos alternativos al modelo en cascada

Debido a la secuencia estrictamente lineal de las fases sucesivas de proyecto, el modelo en cascada se adaptaría, en el mejor de los casos, a proyectos de software de poca envergadura. Por el contrario, los procesos complejos de varios niveles serían difícilmente representables con este modelo. Por este motivo, con el paso del tiempo han ido surgiendo enfoques alternativos.

Mientras que algunos modelos, como el modelo en espiral o el modelo en V, se consideran una evolución del waterfall model clásico, algunos métodos, como la programación extrema, el desarrollo ágil de software o el desarrollo iterativo, se centran en un enfoque completamente diferente y suelen permitir una adaptación a los cambios más recientes o a las exigencias más actuales.



Resumen Final - Patrones GRASP - Sistemas 2

Patrones GRASP


Los patrones GRASP describen los principios fundamentales de la asignación de responsabilidades a objetos, expresados en formas de patrones.
GRASP es un acrónimo que significa General Responsibility Assignment Software Patterns. El nombre se eligió para indicar la importancia de captar estos principios, si se quiere diseñar eficazmente el software orientado a objetos.
Paso a enumerarlos junto con su definición formal:

Experto en información

Problema:

¿De qué forma podemos saber qué responsabilidad delegar a cada objeto?

Solución:

Asignar una responsabilidad al experto en información; la clase que tiene la información necesaria para llevar a cabo la responsabilidad.

Creador

Problema:

¿Quién debería ser responsable de crear una nueva instancia?

Solución:

Crear una nueva instancia por la clase que:

  • Tiene la información necesaria para realizar la creación del objeto
  • Usa directamente las instancias creadas del objeto
  • Almacena o maneja varias instancias de la clase
  • Contiene o agrega la clase


Controlador

Problema:

¿Quién gestiona un evento del sistema?

Solución:

Asignar la responsabilidad de gestionar un mensaje de un evento del sistema a una clase que represente una de estas dos opciones:

  1. Representa el sistema global, dispositivo o subsistema (controlador de fachada).
  2. Representa un escenario de caso de uso en el que tiene lugar el evento del sistema (controlador de caso de uso o de sesión)


Alta cohesión

Problema:

¿Cómo mantener manejable la complejidad?

Solución:

Asignar responsabilidades de manera que la información que almacena una clase sea coherente y este relacionada con la clase.

Bajo acoplamiento

Problema:

¿Cómo dar soporte a las bajas dependencias y al incremento de la reutilización?

Solución:

Diseñar con el objetivo de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases

Polimorfismo

Problema:

¿Quién es responsable cuando el comportamiento varía en función del tipo?

Solución:

Cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad del comportamiento – utilizando operaciones polimórficas – a los tipos para los que varía el comportamiento.

Fabricación Pura

Problema:

¿Quién es el responsable cuando está desesperado, y no quiere violar los principios de alta cohesión y bajo acoplamiento?

Solución:

Asignar un conjunto altamente cohesivo de responsabilidades a una clase de “comportamiento” artificial o de conveniencia que no representa un concepto del dominio del problema – algo inventado -, para dar soporte a la alta cohesión, bajo acoplamiento y la reutilización.

Indirección

Problema:

¿Cómo asignar responsabilidades para evitar el acoplamiento directo?

Solución:

Asignar la responsabilidad a un objeto intermedio para mediar entre otros componentes o servicios, de manera que no se acoplen directamente.

Variaciones Protegidas

Problema:

¿Cómo asignar responsabilidades a los objetos, subsistemas, y sistemas de manera que las variaciones o inestabilidad en estos elementos no influya de manera no deseable en otros elementos?

Solución:

Identificar los puntos de variaciones predecibles o inestabilidad; asignar las responsabilidades para crear una “interfaz” estable alrededor de ellos.



Resumen Final - Patrones de comportamiento - Sistemas 2

Patrones de comportamiento


State

Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo. Por ejemplo: una alarma puede tener diferentes estados, como desactivada, activada, en configuración. Definimos una interfaz Estado_Alarma, y luego definimos los diferentes estados.



Resumen Final - Patrones Estructurales - Sistemas 2

Patrones Estructurales


Composite

Sirve para construir objetos complejos a partir de otros más simples y similares entre sí, gracias a la composición recursiva y a una estructura en forma de árbol.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz común, se tratan todos de la misma manera.

¿Cuándo utilizar este patrón? 

Los escenarios en los que este patrón suele utilizarse son, principalmente:

  • Como su propia definición indica, cuando se requiere representar jerarquías todo-parte que superen cierto tamaño.
  • Cuando se desea que los clientes puedan ignorar la diferencia entre colecciones de objetos y objetos individuales, haciendo que ambos se traten de la misma manera.


Decorator

Responde a la necesidad de añadir dinámicamente funcionalidad a un Objeto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera.

Facade

Su objetivo es proporcionar una interfaz unificada a otro conjunto de interfaces de un subsistema. Façade define una interfaz de más alto nivel que hace que el subsistema más fácil de usar.
Se aplicará el patrón Facade cuando se necesite proporcionar una interfaz simple para un subsistema complejo, o cuando se quiera estructurar varios subsistemas en capas, ya que las fachadas serían el punto de entrada a cada nivel. Otro escenario proclive para su aplicación surge de la necesidad de desacoplar un sistema de sus clientes y de otros subsistemas, haciéndolo más independiente, portable y reutilizable (esto es, reduciendo dependencias entre los subsistemas y los clientes).



Resumen Final - Patrones de diseño - Sistemas 2

Patrones de diseño


¿Qué es un patrón?


  • “Una solución (probada) a un problema en un determinado contexto”.
  • “Es una regla que expresa la relación entre un contexto, un problema y una solución”.


Características


  • Mejora la comunicación
  • Ideas probadas y que funcionan
  • Reutilizables
  • Independientes del entorno
  • NO es garantía de un sistema bien diseñado
  • NO es una solución, pero es un buen punto de partida para pensar una


Elementos


  • Nombre: Identifica al patrón y permite tener vocabulario de diseño común con otras personas.
  • Problema: Define cuando aplicar el patrón, siempre que el contexto lo haga relevante.
  • Solución: Contiene un template genérico de los elementos que componen el diseño, sus relaciones, responsabilidades y colaboraciones.
  • Consecuencias: Se analiza el impacto de aplicar un patrón en la solución, tanto a favor como en contra.


Tipos de patrones

Estructurales

Se ocupan de cómo las clases y objetos se agrupan para formar estructuras más grandes.
Ejemplo: Composite, Decorator, Facade.

De comportamiento

Más que describir objetos o clases, describen la comunicación entre ellos.
Ejemplo: State.

Creacionales

Inicialización y configuración de objetos.



Resumen Final - Atributos esenciales de un buen software - Sistemas 2

Atributos esenciales de un buen software


Mantenibilidad

El sistema debe ser capaz de evolucionar de acuerdo a las necesidades de cambio de los clientes.

Confiabilidad

Debe ser fiable, seguro y proteger la información.

Eficiencia

No debe malgastar recursos.

Usabilidad

No debe representar un problema para el usuario. Debe tener una GUI y documentación adecuados.

Resumen Final - Gestión de configuraciones - Sistemas 2

Gestión de configuraciones


Planificación

Definición de objetivos, políticas y alcance de la implementación de la gestión. Ejemplo:

  • ¿Cuáles serán los roles y responsabilidades?
  • ¿Política de nombres y estados?
  • Diseño del sistema de gestión e interfaces a otros procesos.


Identificación

“Es la selección, identificación y rotulado de las estructuras de configuración y elementos de configuración, incluyendo sus detalles y la relación entre ellos”

Control

“Es asegurarse de que sólo se registren y dispongan EC identificables y autorizados. Impide que se realicen agregados, cambios, reemplazos o remociones sin los permisos y documentación requeridos”.

Reportes

Los reportes de estado deben incluir:

  • Identificadores únicos de EC y su estado actual.
  • Configuraciones básicas, versiones y sus estados.
  • Persona responsable por los cambios de estado.
  • Historia de cambios.
  • Problemas y RFC abiertos.


Auditoría y verificación

Se deben realizar auditorías en los siguientes momentos:

  • Apenas implementado el sistema de gestión de configuración.
  • Antes y después de grandes cambios de infraestructura IT.
  • Antes de la instalación de una versión de software para asegurarse que el entorno es como se espera.
  • Después de una recuperación de un desastre.
  • En intervalos aleatorios.
  • En respuesta a un EC no autorizado detectado.
  • A intervalos regulares.




Resumen Final - Fase de transición - Sistemas 2

Fase de transición


Gestión de configuración

Una configuración básica es “una configuración estándar que se puede reproducir y distribuir a los usuarios”.

Elementos de Configuración (EC)


  • Hardware
  • Software
  • Documentación
  • Persona


Base de datos de elementos de configuración (CMDB)


  • Definiciones de lanzamientos planificados, incluyendo componentes de hardware y software con referencia a las solicitudes de cambio originales.
  • Registro de EC impactados por lanzamientos planificados e implementados.
  • Equipos y software en una ubicación dada.
  • Todos los EC afectados por un problema, cambio o incidente.


Configuración básica

Se puede crear por cualquiera de estas razones:

  • Como una base para trabajos futuros.
  • Como un registro de los EC afectados por un RFC y cuales fueron realmente cambiados.
  • Como punto donde se puede volver si las cosas no funcionan.
  • Como registro base para la compra de muchos elementos estándar similares.


Resumen Final - Prueba de software - Sistemas 2

Prueba de software


¿Qué es la calidad?

Existen dos puntos de vista:

  • Cliente: Es el valor percibido y juzgado por el cliente.
  • Producto: Es el grado en el que un conjunto de características cumple un requerimiento.


Control de calidad

Parte de la gestión de calidad orientada al cumplimiento de los requisitos de calidad.

Aseguramiento de la calidad

Parte de la gestión de calidad orientada a proporcionar confianza en que se cumplirán los requisitos de calidad.

Control de calidad en el software

Es necesario establecer requisitos de calidad como atributos (Fiabilidad, portabilidad, etc.)

Aseguramiento de la calidad en el software

Estándares del producto.


  • Aplican al producto a desarrollar
  • Incluyen estándares de documentación


Estándares de proceso


  • Define el proceso a seguir para el desarrollo del software
  • Incluyen definiciones de procesos, especificación de requisitos de diseño y de validación como de los documentos a utilizar en cada fase del proyecto


¿Qué es el testing?

Según IEEE, “es el proceso de evaluar un sistema o componente de un sistema de forma manual o automática para verificar que satisface los requisitos esperados o para identificar diferencias entre los resultados reales y los esperados”.

¿Por qué es necesario el testing?


  • Describe, con ejemplos, la manera en que un defecto puede causar daño a un entorno, persona, sistema o compañía.
  • Distingue entre la causa de un defecto y su efecto.
  • Ayuda a medir la calidad de un software en términos de defectos encontrados.


Principios del testing


  • Muestra la presencia de errores: No es posible probar todo. Muestra que los defectos existen, no su ausencia.
  • Agrupación de defectos: La mayoría de los defectos se concentran en pocos módulos.
  • Paradoja de pesticida: Repetir pruebas no permite descubrir nuevos errores.
  • Depende del contexto: El dominio del sistema condiciona la prueba.


Objetivos del testing


  • Mejorar la calidad del software
  • Reducción de errores
  • Obtención de métricas
  • Reducción del costo de software para la empresa


Tipos de hallazgos


  • Fallo del sistema: Evento que tiene lugar en algún instante cuando el sistema no funciona como esperan sus usuarios.
  • Error: Desperfecto en un componente o sistema que puede causar que el mismo falle en desempeñar las funciones requeridas.
  • Falla: Diferencia entre cómo se debe comportar el sistema y lo que se definió en los requerimientos.


Estrategias de Testing


  • Unitarias: Prueban el correcto funcionamiento de cada módulo en particular, de modo que todos los módulos funcionen bien por separado.
  • Integración: Sirve para probar que todos los módulos pertenecientes a una entidad funcionan bien de manera integrada.
  • Regresión: Se usan para probar el software luego de un error grave o luego de un deploy.


Tipos de test


  • Caja blanca: Este tipo de pruebas están orientadas a probar el 100% del código. Se prueba rutas lógicas del software y la colaboración entre componentes existentes.
  • Caja negra: Se centran en lo que se espera que realice un módulo, es decir, intentan encontrar casos en los que el módulo no se atiene a su especificación.
  • Usabilidad: Asegura que su aplicación está diseñada respetando consideraciones básicas de usabilidad.
  • Validación o aceptación: Se realizan con el usuario para observar su reacción y obtener su aprobación.
  • Stress tests: Tienen varios objetivos, pueden demostrar que un sistema cumple los requisitos y criterios de rendimiento, pueden comparar dos sistemas para ver cuál funciona mejor, o pueden medir qué partes del sistema o de carga de trabajo provoca que el conjunto funcione mal.


Resumen Final - Gestión de Requerimientos - Sistemas 2

Gestión de Requerimientos


El proceso de Software

Es un conjunto estructurado de actividades requeridas para desarrollar un sistema de software:

  • Especificación
  • Diseño
  • Validación
  • Evolución

Las actividades varían de acuerdo al tipo de sistema.

Ingeniería de requerimientos

Es el proceso de establecer lo que el cliente necesita del sistema y los límites bajo los cuales opera y se desarrolla.

Requerimiento

Es un conjunto de necesidades de alto nivel de un servicio o sistema.

Pueden ser:

  • Funcionales: Describen servicio o funciones.
  • No funcionales: Son un límite en el sistema o proceso de desarrollo.
  • De dominio: Tiene que ver con aspectos legales y/o normas de la organización.

Pueden servir para:

  • Ser la base de un contrato, por lo que debe estar abierto a interpretaciones.
  • Ser la base del contrato en si, por lo que debe estar bien detallado.


Definición de requerimientos

Una declaración en lenguaje natural, incluye los diagramas de servicios del sistema y sus límites operacionales. Debe ser comprensible para el cliente/usuario.

Especificación de requerimiento

Documento estructurado con la descripción o detalle de los servicios del sistema.
Se debe escribir como un contrato entre el cliente y el contratista.

Especificación de software

Descripción detallada de software que puede servir como base de diseño o implementación. La usan los desarrolladores.

Características de la especificación de requerimientos

Mediante los casos de uso se muestran cuatro niveles de descripción:

  • División del trabajo: Casos de uso que describen los procesos de trabajo de los usuarios. Define las fronteras entre usuarios y el sistema.
  • Funciones del sistema específicas de la aplicación.
  • Funciones del sistema específicas del trabajo (funciones de apoyo, seguridad, etc)
  • Diálogo: Casos de uso que describen las interacciones entre usuarios y la GUI.

La validación de requerimientos es continua para asegurarse que la especificación es:

  • Correcta: Debe representar la visión que el cliente tiene del sistema.
  • Completa: Describe todos los escenarios posibles, incluidos los excepcionales.
  • Consistente: No se contradice a sí misma.
  • No ambigua: No se pueden tener diferentes interpretaciones de lo allí especificado.
  • Realista: El sistema se debe implementar con las restricciones documentadas.
  • Verificable: Una vez que se construye el sistema se pueden diseñar pruebas para demostrar que se cubren los requerimientos.
  • Rastreable: Se debe organizar de modo que cada función se pueda rastrear hasta su conjunto de requerimientos.


Requisitos no funcionales

Son aspectos del sistema que no afectan el comportamiento funcional del sistema. Pueden ser:

  • GUI
  • Documentación
  • Consideraciones de Hardware
  • Cuestiones de calidad, etc.


Validación de requerimientos

Pruebas de utilidad:

  • Examinan la comprensión que tiene el usuario de los casos de uso.
  • Localizan problemas en la especificación
  • Etc.


Documento de Análisis de Requerimientos (DAR)


  • En él se documentan los resultados de la actividad de obtención de requerimientos y análisis.
  • Describe todo el sistema desde el punto de vista de los requerimientos funcionales y no funcionales.
  • Debe escribirse cuando el modelo de casos de uso sea estable.


Mini Resumen - Patrones de diseño - Sistemas 2

Patrones de diseño

Los patrones de diseño (design patterns) son soluciones habituales a problemas comunes en el diseño de
software. Cada patrón es como un plano que se puede personalizar para resolver un problema de diseño particular de tu código.

Abstract Factory
(Creacional)

Provee una interfaz para crear familias de objetos relacionados, sin especificar su clase concreta (obtenemos polimorfismo).  Es aconsejado usarlo cuando se prevé la creación de nuevas familias de objetos, pero es contraproducente cuando se quieren agregar nuevos objetos o cambiar los existentes ya que todas las clases se verían afectadas.
El punto importante es usar una interfaz


Builder
(Creacional)

Separa el proceso de construcción de un objeto (paso a paso), de su representación interna(forma en que sus partes están ensambladas).  La idea del builder es por un lado, pedirle que vaya armando las partes que componen el objeto, sin saber de qué clases son, y además pedirle el producto final, sin saber cómo se ensamblan las partes que componen el objeto.
A medida que le vamos indicando que cree las partes, éstas se guardan en atributos del
Builder, o sea, en su estado.
Se apunta a tener una clase builder para construir un objeto, en la cual se construyen por separados los objetitos que forman al objeto y después se unen.


Singleton
(Creacional)

La intensión del singleton es tener una clase que se pueda instanciar una sola vez en el ambiente y que tenga un único punto de acceso en el sistema.  Lo implementamos a través de una variable de instancia que se inicializa en forma tardía la primera vez que lo pide un usuario (por el getInstance()), y dejando el constructor privado.
La cosa es tener una clase que se puede instanciar solo una vez.


Strategy
(Comportamiento)















Es un objeto que define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varié independientemente de los clientes que lo usan.
Es decir permite el cambio de comportamiento y propiedades de un objeto, se puede ver como un cambio parcial del tipo de objeto. Es un patrón de State que no cambia la funcionalidad, sino su co
mportamiento
Cualquier programa que ofrezca un servicio o función determinada, que pueda ser realizada de varias maneras, es candidato a utilizar el patrón Strategy. Puede haber cualquier número de estrategias y cualquiera de ellas podrá ser intercambiada por otra en cualquier momento, incluso en tiempo de ejecución.
La idea es tener una clase que define un algoritmo para hacer x cosa y este algoritmo puede variar la forma de hacer esa cosa. O sea internamente se intercambian los algoritmos.


Template method














Consiste en un algoritmo genérico utilizado por subclases que realizan de distinta forma algunas subtareas.
Se define un método que delega parte de la resolución en un método abstracto redefinido para cada una de las subclases.


Listado de cases de Bases de datos y sus temas

 Listado de clases de Sistemas de Bases de Datos Clase Clases de 02/04 Clase Clase Temas: Claves foráneas. Clase Clas...