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.