Tarea Capitulo 2

2.4  Presentar una arquitectura completa en el principio del desarrollo de nuestro sistema es una manera de comunicar cuales sean nuestras metas, objetivos, obstaculos y sobre todo el diseño que llevaria nuestro sistema una vez terminado y proverernos de ayudas ya sean visuales o tecnicas.
2.5

  

2.8 pueden ser criticos por que en plena actividad del sistema se topan con la conclusion que ese sistema no fue creado para dicho proceso, o por que le hace falta mas actividad al sistema y eso solo se dan cuenta hasta que se prueba el sistema digamos unos dos meses.

2.9 Pueden crear dificultades al momento de crear algunas modificaciones al sistema y este no fue creado para hacerle dichas modificaciones, se caeria como se cae un castillo de naipes : ) .

2.11 bueno como ingeniero les explicaria a los supervisores que necesitamos acceder a la informacion de una manera profesional,  explicar que solo se cambiara la arquitectura del sistema no los datos que este alberga, de dar una solucion que convenga para ambos bandos.

claro que es mi responsabilidad llegar a terminar el trabajo como lo estipula el contrato pero haber colocado las especificaciones mucho antes en el contrato donde se explica los requerimientos de la instalacion. Si la empresa aun no comprende los requerimientos pues empezar a desarrollar un dun informe donde especifica el por que no se a podido terminar el proyecto..

                                                  

Proceso Software Personal

El Proceso Personal de Software es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs. 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 principiantes.

El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos. En el PSP se excluyen los siguientes temas:

Trabajo en equipo, Administración de configuraciones y Administración de requerimientos.

El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y las KPAs que se manejan en cada uno:

Nivel 2 - Inicial:

- Seguimiento y control de proyectos

- Planeación de los proyectos

Nivel 3 - 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 4 - Definido:

- Control de calidad.

- Administración cuantitativa del proyecto.

Nivel 5 - Controlado:

- Administración de los cambios del proceso.

- Administración del cambio tecnológico.

- Prevención de defectos.

- El PSP tiene varias fases:

PSP0: Proceso Base.

PSP0.1: Complementos al proceso base.

PSP1 y PSP1.1: Planeación personal.

PSP2 y PSP2.1: Control de calidad personal.

PSP3: Programas más grandes.

I T C G

Proceso Software personal

El Proceso Personal Software, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad, PSP es una metodología que vale la pena revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo individual.

Atendiendo a la premisa de que existe una fuerte relación entre las habilidades de los ingenieros de software y la calidad de los productos que desarrollan, las actividades establecidas en PSP están orientadas al conocimiento, administración y mejora de sus habilidades al construir programas.

 En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso de autoaprendizaje y auto-mejora.

Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndose en cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo de software. Al primer nivel se le conoce como 0 o de medición personal, al segundo como nivel 1 o de planeación personal, al tercero, como nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada uno de estos niveles, con excepción del 3, tiene una versión que los extiende, introduciendo tareas y actividades para un mejor manejo de los aspectos de interés en nivel, o bien para incluir nuevos aspectos.

Modelo de la madurez de la capacidad (CMM)

Modelo de la madurez de la capacidad (CMM) es a proceso modelo de la madurez de la capacidad que ayuda en la definición y entender de una organización procesos.

CMM primero fue descrito en un libro Manejo del proceso del software por Vatios de Humphrey (publicación. Addison-Wesley Conocían a Professional, Massachusetts, 1989), y por lo tanto también como “CMM de Humphrey”. Vatios de Humphrey basado le en el trabajo anterior de Phil Crosby. Desarrollo activo de este modelo por SEI (Departamento de los E.E.U.U. del instituto de la tecnología de dotación lógica de la defensa) comenzó en 1986. El SEI estaba en Universidad Carnegie-Mellon en Pittsburgh.

El CMM fue pensado originalmente como herramienta para objetivo determinar la capacidad de los contratistas del gobierno procesos para realizar un proyecto contraído del software. Aunque viene del área del desarrollo del software, puede (y ha sido y está siguiendo siendo) ser aplicado mientras que un modelo generalmente aplicable a la ayuda en entender la madurez de la capacidad de proceso de organizaciones en áreas diversas. Por ejemplo, tecnología de dotación lógica, ingeniería de sistema, gerencia de proyecto, mantenimiento del software, gerencia de riesgo, adquisición del sistema, tecnología de información (ÉL), gerencia de personal. Se ha utilizado extensivamente para software de la aeroelectrónica y proyectos del gobierno alrededor del mundo.

El CMM ha sido reemplazado por una variante - CMMI (Integración del modelo de la madurez de la capacidad). El viejo CMM fue retitulado a la tecnología de dotación lógica CMM (SE-CMM) y las acreditaciones de las organizaciones basadas en SE-CMM expiraron el 31 de diciembre de 2007.

Las variantes de los modelos de la madurez derivaron del CMM han emergido sobre los años, incluyendo, por ejemplo, seguridad del software dirigiendo CMM SSE-CMM Modelo de la madurez de la capacidad de la gente y el modelo de la madurez del mantenimiento del software S3M.

Los modelos de la madurez internacionalmente se han estandardizado como parte de ISO 15504.

El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).

El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.

A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:

·         Definidas en un procedimiento documentado

·         Provistas (la organización) de los medios y formación necesarios

·         Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)

·         Medidas

·         Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.

Los niveles son:

1 - Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.

2 - Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.

3 - Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).

4 - Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.

5 - Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

Ventajas

• Análisis causal y resolución
• Gerencia de la configuración
• Análisis y resolución de la decisión
• Gerencia de proyecto integrada
• Medida y análisis
• Innovación y despliegue de organización
• Definición de proceso de organización
• Foco de proceso de organización
• Funcionamiento de proceso de organización
• Entrenamiento de organización
• Supervisión y control del proyecto
• Planeamiento del proyecto
• Proceso y aseguramiento de la calidad del producto
• Integración del producto
• Gerencia de proyecto cuantitativa
• Gerencia de los requisitos
• Desarrollo de los requisitos
• Gerencia de riesgo
• Gerencia del acuerdo del surtidor
• Solución técnica
• Validación
• Verificación

Desventajas

1. Resistencia al cambio
2. Falta de patrocinio de la alta dirección
3. Falta de experiencia en programas de mejora de procesos
4. No se tiene un conocimiento especializado en Ingeniería de Software
5. No se tiene un conocimiento especializado en Administración de Proyectos
6. No se tiene conocimiento sobre modelos de calidad