martes, 12 de octubre de 2010

El Proceso de Software.

  Un proceso de software se puede caracterizar como se muestra en la Figura 2.2. Se establece un marco común del proceso definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un número de conjuntos de tareas -cada uno es una colección de tareas de trabajo de ingeniería del software, hitos de proyectos, productos de trabajo, y puntos de garantía de calidad- que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto.

 Finalmente, las actividades de protección tales como garantía de calidad del software, gestión de configuración del software y medición*-abarcan el modelo de procesos. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

En los Últimos años, se ha hecho mucho énfasis en la «madurez del proceso>>E. l Softwate Engineering Institute (SEI)3 ha desarrollado un modelo completo que se basa en un conjunto de funciones de ingeniería del  software que deberían estar presentes conforme organizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar el estado actual de madurez del proceso de una organización, el SE1 utiliza un cuestionario de evaluación y un esquema de cinco grados.



El esquema de grados determina la conformidad con un modelo de capacidad de madurez [PAU93] que define las actividades clave que se requieren en los diferentes niveles de madurez del proceso.



FASES: 

Fase de definicion:
El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto. 

•       Cada fase se encuentra con una o varias cuestiones de las destacadas anteriormente.

•       La fase de definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto.

Por tanto, han de identificarse los requisitos clave del sistema y del software.

Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales: 

–ingeniería de sistemas o de información, 
- planificación del proyecto del software y 
–análisis de los requisitos.

FASE DE DESARROLLO:

La fase de desarrollo se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.

 •Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: 

 –diseño del software,                          
–generación de código y 
 –prueba del software.     
   
Fase de Mantenimiento:        
                                                                                           
La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. 

 •Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

 Mejora. Conforme se utilice el software, el cliente/ usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

 Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. 

 En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.


Actividades Protectoras:

  Las actividades de protección se aplican a lo largo de todo el proceso del software:
      Seguimiento y control del proyecto de software.    
             Revisiones técnicas formales.
            Garantía de calidad del software.
            Gestión de configuración del software.
      Preparación y producción de documentos 
             Gestión de reutilización
                                                 Mediciones. 
                                     Gestión de riesgos 

Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.        

Marco de Trabajo Comun. 




Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.
Un marco de proceso común (MPC) define un enfoque organizado para el desarrollo y mantenimiento de software. El MPC efectivo para proyectos OO no es un modelo inicial secuencial. El marco de proceso común usado para dirigir un proyecto OO debe ser por naturaleza evolutivo.








No hay comentarios:

Publicar un comentario

Nota: solo los miembros de este blog pueden publicar comentarios.