Ejercicios Capitulo 4

4.1 Sugiera el modelo de proceso del software genérico que podría utilizarse para gestionar el desarrollo de los siguientes sistemas, dando algunas razones basadas en tipo de sistema a desarrollar:

- Un sistema de control antibloqueo de frenos de un automóvil.

Modelo en Cascada, el sistema seria simple y no requerirá muchos cambios una vez hecho el análisis.

- Un sistema de realidad virtual para ayudar al mantenimiento del software

Ingeniería de Software basada en componentes,  se pueden reutilizar componentes del mismo software.

- Un sistema de contabilidad universitaria que reemplace el existente

Ingeniería de Software basada en componentes,  aunque no se harían muchos cambios (aparentemente) después de lanzado el software, pero puede utilizarse código o diseños muy parecidos a otras bibliotecas e incluso ideas del sistema anterior.

- Un sistema interactivo que permita a los pasajeros encontrar los horarios de los trenes a partir de las terminales instaladas en las estaciones.

Modelo Evolutivo, aparentemente es muy sencillo, pero es muy probable que el cliente quiera agregar nuevas funciones mas adelante

4.2 Explique porque los programas que se desarrollan utilizando el desarrollo evolutivo tienden a ser mas difíciles de mantener.

- Por la cantidad de líneas de código, (en el caso de proyectos grandes), no es sencillo integrar las contribuciones en el equipo

- El proceso no es visible, por lo que se tienen que hacer entregas para medir el progreso, esto genera mas costos para la empresa, y mas tiempo invertido

- Los cambios que se hacen (actualizaciones) tienden a corromper la estructura del sistema

4.5 Explique porque es importante hacer distinción entre el desarrollo de requerimientos del usuario y el de los requerimientos del sistema en el proceso de ingeniería de requerimientos.

Es necesario conocer y comprender cuales son los servicios que se necesitan desarrollar en el sistema, al saber esto se crea el documento de requerimientos, que es la especificación del sistema, si esto no se hace bien pueden generar problemas posteriores en el desarrollo e implementación del sistema, los requerimientos del usuario son las ideas superficiales de lo que es el sistema, y los requerimientos del sistema es algo mucho mas detallado de lo que en realidad es.

4.10 Indique como el esquema de clasificación de la tecnología CASE puede ser útil para los administradores encargados de adquirir sistemas CASE.

La tecnología CASE proporciona ayuda automatizada a los procesos de software, además de proporciona información acerca del software en desarrollo, esto permite algunas mejoras en la calidad y productividad del software, aunque es probable que no siempre resulte fácil ubicar un producto, El administrador puede tomar decisiones de cuando aplicarlas y cuando no.

UWE(UML-Based Web Engineering)

Las distintas metodologías se pueden dividir en tres generaciones en base a su sofisticación, estas son:

- Primera Generación:(Principios de los 90) Se sientan las bases de la ingeniería Web, en los que se incluyen conceptos como construcción de navegación, separación entre estructuras y el contenido durante el ciclo de desarrollo.

- Segunda Generación: (Segunda mitad de los 90) Se refinan los primeros modelos y se añaden los soportes de funcionalidad básica y se llevan a cabo los primeros esbozos de proceso donde se delimitan los modelos conceptual, lógico y físico.

- Tercera generación: (A partir del 2000): Se lleva a cabo la profundización en el soporte para la funcionalidad, enfatizacion de la figura del usuario en los métodos, y se avanza hacia la estandarización de notaciones, procesos y lenguajes de especificación.

¿Qué es UWE?

La propuesta de Ingeniería Web basada en UML es una metodología detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Modelado.

UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.

Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la definición de un meta-modelo (modelo de referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para la definición de restricciones sobre los modelos.

Los principales de aspectos en los que se fundamenta UWE son los siguientes:„Lenguaje de modelado unificado). Uso de una notación estándar, para todos los modelos (UML:

Definición de métodos: Definición de los pasos para la construcción de los diferentes modelos.

Especificación de Restricciones: Se recomienda el uso de restricciones escritas (OCL: Lenguaje de restricciones de objetos) para aumentar la exactitud de los modelos.

Ejercicios Capitulo 2

2.4 Explique Porque es importante presentar una descripción completa de una arquitectura del sistema en una etapa inicial del proceso de especificación del sistema.

Porque así se sabe cómo está estructurado el sistema, se identifican componentes de hardware y software, los componentes del fabricante, los componentes funcionales y la interconexión entre ellos. De esta forma se proporciona una visión general de la organización del sistema.

2.5 Considere un sistema de seguridad que esta pensado para proteger contra la intrusión y para detectar fuego. Contiene sensores de humo, de movimiento y de puertas, videocámaras controladas por computadora, que se encuentran en varios lugares del edificio, una consola de operación donde se informa del estado del sistema, y facilidades de comunicación externa para llamar a los servicios apropiados como la policía y los bomberos. Dibuje un diagrama de bloques de un posible diseño de dicho sistema.

2.8 Explique porque los sistemas heredados pueden ser críticos en el funcionamiento de un negocio

Por lo arriesgado que puede ser cambiarlos, cualquier cambio en una parte del sistema inevitablemente traerá cambios en otros componentes o partes del sistema, y eso probablemente traerá cambio de hardware o simplemente cambio de cómo hacer las cosas, esto puede traer disgusto a los auditores y a la organización.

2.9 Explique porque los sistemas heredados pueden causar dificultades para las compañías que desean reorganizar sus procesos de negocio

Porque la gente ya esta adaptada a como hacer las cosas.

Probablemente generara cambios en otros componentes de software

Cambios de Hardware

La información (datos) es probable que en el nuevo sistema  no sea congruente o este duplicada.

2.11 Suponga que es un ingeniero relacionado con el desarrollo de un sistema financiero. Durante la instalación, descubre que el sistema haya que se prescindan de muchas personas. La gente del entorno le niega el acceso a información esencial para completar la instalación del sistema. ¿Hasta donde debería, como ingeniero de sistemas, verse envuelto en esto? ¿Es responsabilidad suya completar la instalación como lo estipula el contrato?¿Debería abandonar el trabajo hasta que la organización haya resuelto el problema?

Es necesario completar el sistema  porque inevitablemente habrá usuarios insatisfechos.

Proceso Personal de Software (PSP)

El proceso personal de software Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.

Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.

Niveles

• Nivel 1 - inicial:
• Seguimiento y control de proyectos.
• Planeación de los proyectos.
• Nivel 2 - repetible:
• Revisión entre colegas.
• Ingeniería del producto de software.
• Manejo integrado del software.
• Definición del proceso de software.
• Foco del proceso de software.
• Nivel 3 - Definido:
• Control de calidad.
• Administración cuantitativa del proyecto.
• Nivel 4 - Controlado:
• Administración de los cambios del proceso.
• Administración del cambio tecnológico.
• Prevención de defectos....

Integración del Modelo de Capacidad de Madurez (IMCM)

Integración de Modelos de Madurez de Capacidades o Capability Maturity Model Integration (CMMI) es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios.

La versión actual de CMMI es la versión 1.3, liberada el 1 de noviembre de 2010.

Hay tres constelaciones de la versión 1.2 disponible:

• CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.

• CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.

• CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro de la constelación CMMI-DEV, existen dos modelos:

• CMMI-DEV
• CMMI-DEV + IPPD (Integrated Product and Process Development)

Independientemente de la constelación\modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada (por ejemplo, usando un método de evaluación como SCAMPI) y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organización, puede coger áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización.