Modelos de Proceso del Software

El resumen del plan guarda y estima los datos del proyecto actual, el cual debería de contener lo siguiente:

• 
  Estimación original de LOC(“Lines Of Code”, Líneas de código) que se estima se van a desarrollar.
  
• 
  Líneas de código que se llevan en desarrollo hasta ese momento.
  
• 
  El tiempo estimado que es requerido para cada fase.
  
• 
  El tiempo que se requiere para cada fase.
  
• 
  El numero total y el porcentaje de fallos que se han provocado en cada fase.
  
• 
  El numero total y el porcentaje que se han eliminado en cada fase.
  

4.5.2.5 PSP0.1 Codificación estándar [15]
Desarrollo de la codificación estándar para lo siguiente:

• 
  Cabecera
  
• 
  Uso/ reuso
  
• 
  Identificadores
  
• 
  Comentarios
  
• 
  Sección mas importante
  
• 
  Espacios en blanco
  
• 
  Identidad
  
• 
  Capitalización
  

Dentro de este estándar se pueden incluir definiciones y ejemplos.

4.5.2.6 PSP0.1 Medida del tamaño [15]
Durante la planeación del proceso de software, incluye la estimación del tamaño del trabajo así como las líneas de código.
El desarrollo del estándar tiene pequeños problemas con lo siguiente:

• 
  Modificación o eliminación de líneas.
  
• 
  Comentarios o líneas en blanco.
  
• 
  Líneas con múltiples declaraciones.
  
• 
  Declaraciones nulas o vacías.
  
• 
  Incluir archivos (agregados una vez o varias veces).
  
• 
  Funciones de línea o expansión de marcos.
  
• 
  Declaraciones
  
• 
  Etiquetas
  
• 
  Símbolos como llaves “{ }” , begin/ end, else, case….
  

4.5.2.7 PSP0.1 Mejora del proceso [15]
La mejora del proceso provee un registro de fallas problemas e ideas de mejora. Puede contener lo siguiente:

• 
  Descripción de la falla encontrada dentro del proyecto
  
• 
  Numero del problema
  
• 
  Descripción y las dificultades
  
• 
  Descripción del impacto que tiene el producto o el proceso con la falla o problema.
  
• 
  Descripción de las sugerencias para mejorar el proceso.
  
• 
  Numeración de cada una de las sugerencias.
  
• 
  Identificación de los elementos del proceso que son afectados.
  
• 
  Cuando será apropiado, relacionar las sugerencias de mejor para el problema.
  
• 
  Dar prioridades a las sugerencias y explicar porque son importantes.
  
• 
  Agregar comentarios sobre el proyecto.
  
• 
  Lección aprendida
  
• 
  Condiciones que es necesario recordar para determinar el porque funciona bien el proceso o el porqué es deficiente.
  

4.5.2.8 PSP0 Documentación del proceso [15]
En esta parte se debe tener documentada la planeación el desarrollo y el post ejecución del proceso. En seguida se describe que es lo que debe contener cada uno de ellos.
Planeación:

• 
  Producir u obtener los requerimientos de las declaraciones.
  
• 
  Estimación de nuevos totales como los cambios en las líneas de código requeridos en PSP0.1.
  
• 
  Estimación del tiempo requerido para el desarrollo.
  
• 
  Registrar el inicio del proyecto en el resumen del plan del proyecto.
  
• 
  Registrar la fecha del proyecto.
  

Desarrollo:

• 
  Diseño, implementación, compilación, prueba.(PSP0.1)
  
• 
  Registrar el tiempo.
  

Post-ejecución:

• 
  Completar el resumen del plan del proyecto, con el tiempo actual, fallas, tamaño de los datos.
  
• 
  Terminar el mejoramiento del proceso.
  

4.5.3 PSP1 Planeación Personal del Proceso [15]
El PSP1 estima el tamaño del software, hace una prueba de reporte del PSP. Adicionalmente contribuye a PSP1 estimar los recursos y el horario.
El PSP1 intenta establecer el proceso de forma ordenada y repetida para desarrollar el software usando el tamaño, recursos y horarios estimados.
El proceso de valoración llega a ser progresivamente más exacto conforme los datos se recopilan de varios proyectos.
Las tareas que se incluyen del PSP0 y PSP0.1 agregan lo siguiente:

• 
  Estimación de tamaño.
  
• 
  Reporte de prueba.
  
• 
  Planeación de tareas
  
• 
  Planeación del horario
  

4.5.3.1 PSP1 Estimación de tamaño [15]
Las siguientes disciplinas se usan para estimar las líneas de código. Se debe tener el tamaño de los datos sobre un número de proyectos previamente desarrollados para poder establecer estimaciones iniciales.
Método PROBE (Proxy-Based Estimating), Descrito en la disciplina para la Ingeniería de Software.
Puntos de Función:

• 
  Ali Arifoglu. Metodología de software para la estimación de costos ACM Sigsoft Software Engineering.
  
• 
  COCOMO Model (Constructive Cost Model) es el modelo constructivo de costos. Este modelo es para la estimación de líneas de código.
  

4.5.3.2 PSP1 Reporte de pruebas [15]
El reporte de pruebas se usa para mantener un registro de pruebas de ejecución y resultados obtenidos. Estos pueden ser tan detallados como se desee, con esto se puede hacer la misma prueba y obtener los mismos resultados. El reporte incluye lo siguiente:

• 
  Nombre y numero de prueba
  
• 
  Objetivo de la prueba
  
• 
  Descripción de la prueba
  
• 
  Condiciones de tiempo o configuración especial
  
• 
  Resultados esperados
  
• 
  Resultado actual
  

4.5.3.3 PSP1.1 Planeación de Tareas [15]

La planeación de las tareas implica estimar el tiempo de desarrollo y de los datos de la terminación para cada tarea del proyecto. Este también proporciona una base según el horario que se sigue. El plan debe contener lo siguiente:

• 
  Nombre y número de la tarea.
  
• 
  Planeación de hora de acuerdo a la tarea por semana, y para el proyecto.
  
• 
  Tiempo actual por tarea por semana, y ara el proyecto.
  

4.5.3.4 PSP1.1 Planeación de horarios [15]

El horario se usa para recordar el horario actual y empleado en el calendario por periodo. Se usa para relacionar tareas previstas con el horario según el calendario. Las siguientes semanas se usan para pequeños proyectos, y puede que sea mejor hacer mayor esfuerzo por día.

El horario puede contener lo siguiente:

• 
  Numero de cada semana, típicamente empezando en 1.
  
• 
  Fechad de calendario para cada semana.
  
• 
  Planeación prevista para el trabajo en el proyecto por semana.
  
• 
  Horas previstas acumuladas.
  
• 
  Horas reales que se invierten en el proyecto por semana.
  
• 
  Horas reales acumuladas.
  

4.5.3.5 PSP1 Documentación del proceso [15]

Planeación

• 
  Produce u obtiene la declaración de los requisitos.
  
• 
  Estimación del tamaño del software, tiempo del desarrollo requerido (PSP1).
  
• 
  Plan completo de tareas.
  
• 
  Horario completo del plan (PSP1.1).
  
• 
  Incorporación de los datos iniciales en el resumen del plan de proyecto.
  
• 
  Registro de tiempo y datos iniciales.
  

Desarrollo

• 
  Diseño, Implementación, compilación, prueba.
  
• 
  Recolectar los datos del reporte de prueba (PSP1).
  
• 
  Recolectar los registros de los datos.
  

Post-ejecución

• 
  Resumen del plan del proyecto completo con el tiempo real, fallas, tamaño de los datos.
  
• 
  Completar la mejora del proceso.
  

4.5.4 PSP2 Calidad personal [15]

El proceso PSP2 introduce revisiones de diseño, código a la medida y medición de la calidad.

Este tipo de revisiones mejoran la calidad del software más que otro cambio personal que se haga en el proceso del software. Introduce también criterios y verificación de diseño completos.
Se incluyen tareas de PSP1 y de PSP1.1 más las siguientes:

• 
  Revisión de código (PSP2).
  
• 
  Revisión de diseño (PSP2).
  
• 
  Diseño de plantillas (PSP2.1).
  

4.5.4.1 PSP2 Revisión de código [15]

El objetivo principal de la revisión de calidad es mejorar la calidad del programa examinando parte o todo el sistema y su documentación asociada.

Las revisiones técnicas o inspecciones de programa son similares excepto porque su objetivo principal es identificar las fallas o defectos tales como anomalías en el código, errores lógicos, incumplimiento de estándares.
Las revisiones tienen un número de pruebas dinámicas del excedente de las ventajas.

• 
  No requieren que el programa se este ejecutando
  
• 
  Son una medida directa de defectos o cualidades de la calidad
  
• 
  Se consideran mas efectivos
  

La revisión de código consiste en la comprobación de la inicialización de la variable y sus parámetros.

• 
  En el inicio del programa, inicio de los ciclos, formato de la llamada de la función
  

Llamada de función y formato de la llamada

• 
  Punteros parámetros, y el uso de ‘&’
  

Comprobación y deletreo de nombres

• 
  Es consistente.
  
• 
  Esta dentro del alcance de la declaración.
  
• 
  Todas las estructuras y clases usan ‘.’ Y ‘->’ de forma correcta.
  

Comprobación de secuencias

• 
  Identificación de terminación por puntuaciones y NULL.
  

Comprobación de archivos

• 
  Declaración correcta.
  
• 
  Abrir y cerrar correctamente.
  

Comprobación de punteros

• 
  Iniciar en NULL.
  
• 
  Borrar solamente después que se crea o es nuevo
  
• 
  Borrar siempre después de su uso
  

Comprobación del formato de salida

• 
  Alineación y espaciado correcto
  

Verificación de operadores lógicos

• 
  Uso apropiado de operadores lógicos (=, <, >,…etc.).
  
• 
  Uso apropiado de paréntesis para operaciones lógicas.
  

Asegurar que las llaves estén alineadas.

Verificar cada línea de código por instrucciones, sintaxis y puntuación apropiada.

Asegurar el código conforme al estándar de codificación.

4.5.4.2 PSP2 Revisión de Diseño [15]
En la revisión de diseño se deben asegurar los requisitos, especificaciones y niveles altos de diseño sean cubiertos totalmente. En esta parte se producen todas las salidas especificadas, se crean todas las entradas necesarias y todos los requerimientos incluidos son indicados en esta parte.
Verificación de la lógica del programa

• 
  Apilado, Listas, Recursividad
  
• 
  Todos los ciclos son propiamente inicializados, tanto el incremento y terminación del mismo.
  

Verificación de casos especiales

• 
  Asegurar las operaciones con los valores de empty, full, min, max, negative, zero.
  
• 
  Proteger contra fuera de limites, desbordamiento (overflow), desbordamiento de menor capacidad (underflow).
  
• 
  Asegurar que las condiciones imposibles son imposibles.
  
• 
  Manejar todas las condiciones incorrectas de entrada.
  

Verificación de uso de funciones

• 
  Todas las funciones y objetos se deben de usar y entender propiamente.
  
• 
  Todas las abstracciones externas son definidas.
  

Verificación de nombres

• 
  Todos los nombres y tipos son claramente definidos.
  
• 
  El alcance de todas las variables son evidentes o bien definidos.
  
• 
  Todos los nombres y objetos se usan dentro de su alcance definido.
  

Revisión del diseño de acuerdo al estándar aplicable al diseño.

4.5.4.3 PSP2.1 Diseño de plantillas [15]
Hay cuatro plantillas de diseño que proveen de forma ordenada un marco de trabajo y el formato de registro para los diseños.
Los formatos no indican la forma en como hacer el diseño, pero pueden ayudar a que se registren de manera apropiada.

Las plantillas incluyen lo siguiente:

• 
  Escenario de operación de la plantilla.
  
• 
  Especificación funcional de la plantilla.
  
• 
  Especificación de estado de la plantilla.
  
• 
  Especificación lógica de la plantilla.
  

Escenario de operación de la plantilla
Esta plantilla tiene las descripciones de los panoramas probables que se seguirán al usar el programa.
Las plantillas deben incluir lo siguiente:

• 
  Numero de escenarios para los escenarios y los pasos para el escenario.
  
• 
  Identificación del objetivo de los usuarios.
  
• 
  Fuente de acción así como los usuarios, programas o sistemas.
  
• 
  Descripción de la acción, que lugar toma así como el mensaje de error de una entrada incorrecta.
  
• 
  Lista de comentarios significativos.
  

Especificación funcional de la plantilla
Esta plantilla se puede usar para describir funciones y procedimientos de diseño de funciones o de objetos de diseño orientado a objetos.
Las plantillas deben incluir:

• 
  Nombre de la función / clase o clases de donde hereda.
  
• 
  Cualquier parámetro o atributo cuyos valores son externos visibles o cualquier comportamiento del objeto.
  
• 
  Documentación de los métodos para cada objeto, incluyendo el prototipo, variables requeridas, tipos y la operación realizada.
  

Especificación de estado de la plantilla

Esta plantilla se usa para registrar el comportamiento del programa, subprograma o clase en un sistema orientado a objetos.

La plantilla incluye lo siguiente:

• 
  Nombre del estado.
  
• 
  Descripción de estado.
  
• 
  Atributos o variables que caracterizan el estado.
  
• 
  Para cada estado.
  
  • 
    Lista de todos los estados siguientes posibles.
    
  • 
    Lista de condiciones para cada estado siguiente.
    
  • 
    Dar ejemplos de la condición de transición.
    

Especificación lógica de la plantilla
Esta plantilla mantiene la lógica del pseudo código para cada función o unidad del programa.
La plantilla debe contener lo siguiente:

• 
  Enumerar todos los “incluyes” nuevos o inusuales requeridos por la función.
  
• 
  Enumerar todos los tipos inusuales o especiales.
  
• 
  Entregar el prototipo de la función o la declaración.
  
• 
  Documentación auxiliar de información requerida para entender la función.
  
• 
  Asignar un número o etiqueta para cada declaración lógica significativa.
  
• 
  Documentar la lógica del programa
  
  • 
    Uso de pseudocódigo.
    
  • 
    Uso de una línea separada para cada función significativa.
    
  • 
    Uso de lenguaje común o matemático para mayor claridad.
    
  • 
    Incluir comentarios donde sea necesario.
    

4.5.4.4 PSP2 Documentación del Proceso [15]

Planeación

• 
  Producir u obtener la declaración de los requisitos.
  
• 
  Estimación del tamaño del software, tiempo de desarrollo requerido.
  
• 
  Estimación de tiempo requerido en el desarrollo.
  
• 
  Completar el plan de tareas.
  
• 
  Completar el horario.
  
• 
  Incorporación de los datos iniciales en el resumen del plan de proyecto.
  
• 
  Registrar los datos iniciales en el registro de tiempo
  

Desarrollo

• 
  Diseñar, implementar, compilar y probar.
  
• 
  Agregar la revisión del diseño y revisión de código (PSP2).
  
• 
  Usar las plantillas de diseño donde sea apropiado.
  
• 
  Tomar los datos del informe de prueba.
  
• 
  Tomar los datos del informe de registro de tiempo.
  

Post-ejecución

• 
  Completar el resumen del plan del proyecto con el tiempo real, falla y tamaño de los datos.
  

4.5.5 PSP3 Proceso cíclico [15]
El proceso cíclico combina múltiples procesos de PSP2.1 para soportar el desarrollo de software a gran escala.
El objetivo principal es ampliar el proceso de software personal hacia proyectos industriales y para cubrir el trabajo de proyecto de equipo.
Esta estrategia se centra en el desarrollo del producto, incrementos convenientes para el desarrollo cíclico.
Las tareas incluyen todo lo de PSP2 y PSP2.1 y lo siguiente:

• 
  Desarrollo cíclico(PSP3)
  

4.5.5.1 PSP3 Desarrollo Cíclico [15]
Cuando se usa PSP3, se debe de tener un plan para implementar grandes programas en módulos incrementales más o menos de 100 líneas de código (u otro tamaño apropiado).
A lo largo del resumen del proyecto PSP3 utilizara el resumen del ciclo para seguir los datos.

• 
  Tamaño del programa
  
• 
  Tiempo que se lleva en el desarrollo de cada fase
  
• 
  Fallas eliminadas
  

4.5.5.2 PSP3 Documentación del Proceso [15]

Planeación

• 
  Declaración de los requerimientos producidos y obtenidos
  
• 
  Estimación del tamaño del software, tiempo de desarrollo requerido
  

• 
  Completar el plan de tareas.
  

• 
  Completar el horario de trabajo
  
• 
  Incorporación de los datos iniciales en el resumen del plan de proyecto.
  
• 
  Registrar los datos iniciales en el registro de tiempo
  

Desarrollo

• 
  Diseñar, implementar, compilar y probar.
  
• 
  Agregar la revisión del diseño y revisión de código
  
• 
  Usar las plantillas de diseño donde sea apropiado.
  
• 
  Usar el desarrollo cíclico, y seguir los resúmenes del ciclo.
  
• 
  Tomar los datos del informe de prueba.
  
• 
  Tomar los datos del informe de registro de tiempo.
  

Post-ejecución

• 
  Completar el resumen del plan del proyecto con el tiempo real, falla y tamaño de los datos
  

Asignaciones
Los principios de estas asignaciones son los siguientes:

• 
  Atención especial a las tareas de PSP. El objetivo principal de estas asignaciones no es completarlas correctamente sino que estas tareas usen completa y correctamente los elementos apropiados del PSP.
  
• 
  Sobre todo, el trabajo debe ser correcto. Es mejor estar atrasado que este incorrecto. Si se necesita mas tiempo es necesario pedirlo.
  
• 
  Todas las asignaciones son individuales. La asistencia técnica se obtiene del instructor o de otro grupo de miembros que aclaran los requerimientos o tareas de PSP. Se debe de registrar cuando se recibe asistencia.
  

Vinculación de listas
Se debe escribir un programa para calcular la desviación estándar de una serie de n números usando lista encadenada. Es el promedio de los números. La formula de la desviación estándar es:


Contando las Líneas de Código
Al escribir el programa se deben de contar las líneas de código, omitiendo comentarios y líneas en blanco. Asegurarse de que las declaraciones se hagan en una sola línea, o se cuenten varias veces. Por ejemplo, las siguientes líneas se cuentan de manera múltiple ya que contienen dos líneas de código

• 
  If (x==0) f();
  
• 
  If (x==0)
  

f();

• 
  X=10; y=x + 5;
  

El total de Líneas de código del programa debe contar los totales para cada unidad logia(es decir para cada función). También el número de las declaraciones que no son ejecutables deben de contadas.
Almacenamiento y recuperación de archivos
Escribir un programa para almacenar, recuperar y modificar serie de n números reales de un archivo. De entrada el programa debe aceptar enteros o números reales y guardar como números reales. Las funciones que debe proveer el usuario son las siguientes:

• 
  El usuario asigna el nombre del archivo.
  
• 
  El usuario selecciona la forma de usar el archivo, lectura, escritura, modificar.
  
• 
  Lectura, el programa proporciona una numeración por línea dentro del archivo.
  
• 
  Escritura, el usuario establece el número de registros.
  
• 
  Modificación
  
  • 
    El programa proporciona el número y el usuario tiene la opción de aceptar, reemplazar o eliminar el número.
    
  • 
    El usuario puede dar orden al programa de aceptar el resto de la numeración al archivo.
    
  • 
    El usuario puede guardar las modificaciones con un nuevo nombre dejando el original intacto.
    

Asignación Estándar
Desarrollar los siguientes estándares para el PSP
Cuenta estándar de las líneas de código

• 
  Producir una especificación estándar de cómo contar las líneas de código.
  
• 
  Se puede usar en conjunto con la asignación.
  

Codificación estándar

• 
  Producir una codificación estándar que se usara para nuestro PSP
  
• 
  Se puede usar para evaluar cualquier asignación que se desarrolle
  

Revisión estándar

• 
  Producir un estándar que sea usado para el diseño y revisión de código
  

Proceso de Ingeniería de Software

• 
  Producir un estándar que documente el proceso de la Ingeniería de Software, donde se usa y demostrar donde encajan las tareas de PSP
  

Análisis del reporte de fallas
Agregar los siguientes comentarios al resumen de comentarios basados en las fallas encontradas durante el desarrollo.

• 
  El total de fallas encontradas
  
• 
  Las nuevas y modificadas líneas de código
  
• 
  Las fallas por KLOC(Kilo Lines Of Code)
  

Que debe dar la tabla:

• 
  Numero de fallas encontradas en la compilación
  
• 
  Numero de fallas encontradas al probarlo
  
• 
  Numero de fallas encontradas por KLOC en la pruebas.
  
• 
  Numero de fallas encontradas en la compilación por KLOC
  
• 
  
  

El listado debe dar el promedio de reparación

• 
  Fallas encontradas durante la compilación
  
• 
  Fallas encontradas durante la prueba
  
• 
  Fallas introducidas en el diseño y la codificación
  
• 
  Fallas introducidas en el código
  

BIBLIOGRAFÍA

1. 
   Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª Edicion.
   
2. 
   Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición
   

REFERENCIAS WEB

3. 
   Nelson Medinilla Martínez, Facultad de Informática, Universidad Politécnica de Madrid, “Análisis y selección de estrategias de desarrollo de software” [En línea], Madrid España [Consulta: Mayo de 2006], estrategias.pdf>
   
4. 
   Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas Venezuela [Consulta: Abril de 2006],
   
5. 
   Tesis doctorales en Zarza, “Ingeniería de Software” [En línea], España [Consulta: Mayo de 2006],
   
6. 
   Mundo Geek, “Ciclos de vida del software” [En línea], [Consulta: Mayo de 2006], <http://mundogeek.net/archivos/2004/05/20>
   
7. 
   Wikipedia Foundation Inc, EUA Desarrollo en Cascada [En línea], St. Petersburg [Consulta: Mayo de 2006], <http://es.wikipedia.org/wiki/Modelo_en_cascada>
   
8. 
   Instituto Tecnológico de la paz, “Análisis y diseño de sistemas Modelo de Espiral” [En línea], México [Consulta: Mayo de 2006], analisis/index.htm>
   
9. 
   Copyright © Programación en Castellano, [En línea], España [Consulta: Mayo de 2006],
   
10. 
    Zavala R. 2000. Diseño de un Sistema de Información Geográfica sobre Internet. Tesis de Maestría en Ciencias de la Computación. Universidad Autónoma Metropolitana-Azcapotzalco., “La Ingeniería del Software” [En línea], [Consulta: Abril de 2006], México, D.F.
    
11. 
    Juan Pavón Maestras, Universidad Complutense de Madrid, “El proceso unificado” [En línea], Madrid España [Consulta: Abril de 2006], jpavon/is2/03ProcesoUnificado.pdf>
    
12. 
    Carlos Reynoso, Universidad de Buenos Aires, Arquitectura de Software [En línea] Buenos Aires Argentina [Consulta: Mayo de 2006], msdn/arquitectura/roadmap_arq/heterodox.asp>
    
13. 
    Grupo de Investigación Kybele, Universidad Rey Juan Carlos, “Fases del proceso unificado” [En linea], Madrid España [Consulta: Abril de 2006],
    
14. 
    Wikipedia Foundation Inc, EUA “Proceso Unificado de Rational” [En línea], St. Petersburg [Consulta: Abril de 2006],http://es.wikipedia.org/wiki/RUP
    
15. 
    Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA [Consulta: Mayo de 2006] cmsc645/se_psp.pdf>
    
16. 
    Gustavo Adolfo Ramírez González, Universidad del Caucan Popayán, “Proceso Unificado para desarrollo de Software”, Colombia [Consulta: Junio de 2006],
    
17. 
    A.U.S. GustavoTorossi, “El Proceso Unificado de Desarrollo de Software” [En línea], Provincia de Chaco Republica de Argentina [Consulta: Junio de 2006]
    
18. 
    Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006],
    

Modelos de proceso de software