Procesos de software

(1)

Procesos de software

Ing. Priscilla Garbanzo Tencio, MIS

[email protected]

San José, 2005

Temas

z

Deficiencias en el desarrollo de software

z

Definición de proceso de desarrollo de software

z

Ejemplos de Metodologías o marcos de trabajo

z

Beneficios que brinda

(2)

Temas

z Deficiencias en el desarrollo de software

z Identificación

z Causas

z Atención al proceso

z Definición de proceso de desarrollo de software

z Ejemplos de metodologías o marcos de trabajo

z Beneficios que brinda

Análisis (1994)

Análisis del estado de los proyectos de software: Report Chaos(1994)

53%

16%

31%

Finalizado con inconvenientes (fuera de plazo, fuera de presupuesto, sin satisfacer todos los requerimientos) Finalizado sin inconvenientes

Cancelado

(3)

Deficiencias en el desarrollo de software

z Los sistemas no responden a las expectativas de los usuarios.

z Los programas “fallan” con cierta frecuencia.

z Los costos del software son difíciles de prever y normalmente superan las estimaciones.

z La modificación del software es una tarea difícil y costosa.

z El software se suele presentar fuera del plazo establecido y con menos características que las consideradas inicialmente.

z Normalmente, es difícil cambiar de entorno de hardware usando el mismo software.

z El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.

Causas de finalización con inconvenientes o finalización por clausura.

z Carencia en los insumos de los usuarios.

z Especificaciones y requerimientos incompletos.

z Cambios en las especificaciones y requerimientos incompletos.

z No existe medición del proceso ni registro de datos históricos.

z Escaso o deficiente monitoreo en el avance del proceso de desarrollo.

z No se utiliza la tecnología adecuada.

z Uso de nueva tecnología o técnicas.

z Carencia de recursos.

z Expectativas poco realistas.

(4)

Causas de finalización con inconvenientes o finalización por clausura.

z Excesiva e irracional presión en los calendarios.

z Crecimiento excesivo de los requerimientos para un producto de software.

z No se hace gestión de riesgos formalmente.

z No se realiza un proceso formal de pruebas.

z No se realizan revisiones técnicas formales e inspección de código.

z Objetivos del proyecto poco claros.

Análisis (2003)

Análisis del estado de los proyectos de software: Report Chaos(2003)

51%

34%

15%

Finalizado con inconvenientes (fuera de plazo, fuera de presupuesto, sin satisfacer todos los requerimientos) Finalizado sin inconvenientes

Cancelado

(5)

Condición más cercana

z

Esto es un avance significativo pero aún nos queda trabajo por realizar ya que solo el 34%

del 100% terminan siendo proyectos exitosos. Además el estudio del 2003 muestra que han incrementado las

problemáticas de sobrepaso de tiempos y costos, y que los productos no cumplen con las características y funcionalidades

pactadas originalmente.

Causas de finalización exitosa del proyecto.

z Suficiente participación de los usuarios en el proceso.

z Adecuado control y seguimiento del proyecto.

z Definición de requerimientos clara.

z Expectativas realistas.

z Definición de puntos de control (hitos) pequeños dentro del proceso.

z Personal competente.

z Objetivos y visión del proyecto claros.

z Equipo de trabajo enfocado.

(6)

¿Por qué importa el proceso?

Experiencia de proyectos con poca atención en el proceso durante las etapas tempranas

Porcentaje de esfuerzo

Tiempo Trabajo productivo

Proceso Trabajo no productivo

Mc Connell

Atención al proceso

Experiencia de proyectos que ponen atención al proceso en etapas tempranas de desarrollo.

Porcentaje de esfuerzo

Tiempo Trabajo productivo

Proceso

Trabajo no productivo

Mc Connell

(7)

Temas

z Deficiencias en el desarrollo de software

z Definición de proceso de desarrollo de software

z Definición

z Elementos

Construcción de una casa para “fido”

Puede hacerlo una sola persona Requiere:

Modelado mínimo Proceso simple Herramientas simples

I. Introducción: Modelado de SW

(8)

Construcción de una casa

Construida eficientemente y en un tiempo razonable por un equipo

Requiere:

Modelado

Proceso bien definido Herramientas más sofisticadas

Construcción de un rascacielos

(9)

Necesidades de los usuarios

Expresadas por medio de los requerimientos o características de calidad. Existen dos tipos:

z Funcionales (qué debe hacer el sistema): Funcionalidad del sistema.

z No Funcionales (bajo que condiciones o restricciones): Req. del producto usabilidad, eficiencia, fiabilidad, portabilidad, mantenibilidad, reutilizabilidad, interoperabilidad Req. organizacionales de entrega, de implementaciòn, de estàndares Req. Externos interoperabilidad, èticos, legislativos.

Desarrollo de software

Requerimientos nuevos o modificados

Sistema nuevo o modificado Proceso de Desarrollo

de Software

Proceso adecuado

No existe un proceso de software universal. El proceso debe permitir obtener productos de calidad, que optimice los recursos (tiempo, costo).

Las características particulares de cada proyecto y organización (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable.

Satisfacción de los usuarios El producto obtenido satisface las necesidades del cliente.

Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

Elementos de un Proceso de Desarrollo S.W.

Proceso Software Actividades

(cómo, cuando)

(10)

Elementos base

z

Actividades (¿Cómo?)

Es una unidad de trabajo que un individuo perteneciente a un rol puede realizar. Posee un claro propósito, usualmente es expresado en términos de crear o modificar un artefacto y se encuentra

compuesta de pasos.

Tipos

z Modelado del negocio

z Requerimientos

z Análisis

z Diseño

z Implementación

z Construcción

z Implantación

z Planeación y seguimiento

z Aseguramiento de la calidad

z Control de cambios, versiones y respaldos

(11)

Otra clasificación

Actividades de protección Marco de trabajo del proceso común

Actividades de trabajo del proceso común Conjunto de tareas

Tareas Hitos, entregas

Puntos SQA

Actividades principales y actividades de apoyo

Actividades principales

z

Modelado del negocio

z

Requerimientos

z

Análisis

z

Diseño

z

Implementación

z

Pruebas

z

Implantación

(12)

Cascada

Requerimientos

Análisis

Diseño

Programación

Pruebas Operación

Actividades de apoyo o protección

z

Las actividades de protección son

independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso. Son actividades paralelas a las actividades principales.

z

Tales como aseguramiento de la calidad del software, gestión de configuración del

software y medición, abarcan el modelo del

proceso.

(13)

Cascada

Requerimientos

Análisis

Diseño

Programación

Pruebas Operación

“Ciclo V”

Especificación de requerimientos

Diseño arquitectónico

Pruebas de aceptación

Pruebas de integración Software

probado Casos de prueba

Casos de prueba Revisión

Revisión

(14)

Verificación y validación

Business Need

Define Requirements

Design System

Build System Verify

Acceptance Test

System Test

Integration Test

Unit Test Verify

Verify Verify

Validate

Validate Validate

Validate Validates

Validates

Static Reviews

Dynamic Testing

Ciclo (de vida) V

V-Model Software Development Life Cycle

LEGEND

SDLC Phase

Baselined Phase products

Feasibility Study Requirements

definition Statement of requirements Project initiation

Plans Updated requirements

Requirements specification

Architectural design

Design specification

Detailed design

Module designs

Code Coding

Operation Project phase out Operational

software Operational

test

Project completion

Acceptance test Accepted

software

Tested software Integration

test Integrated software Integration Tested modules Unit Test

Test data Test cases

Test data

Test cases Test data Test cases

Test data Test cases

Test data Test cases Integration

plan Build Files

Test data Test cases Review

Review

Walkthrough

Code Reading

(15)

Elementos de un Proceso de Desarrollo S.W.

Artefactos (qué)

Elementos base

z

Productos (¿Qué?)

Es una pieza de información que es producida, modificada o usada por un proceso. Son productos tangibles del el proyecto: cosas que el proyecto produce o usa para alcanzar el producto final.

Pueden ser:

z Documentos

z Modelos

z Software

(16)

Ejemplos

z

Especificación de Requerimientos de software

z

Documento Análisis y diseño

z

Agendas y minutas

z

Plan del proyecto

z

Software

Elementos de un Proceso de Desarrollo S.W.

Roles

(quién) Artefactos

(qué) Personas

(17)

Elementos base

z

Roles (¿Quién?)

Definen el comportamiento y responsabilidades de un individuo o un grupo de individuos trabajando juntos como equipo

Ejemplo de rol

Encargado de calidad

Se encarga de garantizar la calidad de los productos a elaborados.

Objetivo

z Designar un responsable del aseguramiento de la calidad en el proceso y el producto.

Responsabilidades

z Velar porque se realicen todas las revisiones a los artefactos de software.

z Actualizar las listas de revisión, de acuerdo a los estándares del proyecto.

z Asegurarse de que el proceso se realiza de acuerdo a lo

(18)

Elementos de un Proceso de Desarrollo S.W.

Roles

(qué) Personas

Elementos de un Proceso de Desarrollo S.W.

Roles

(qué) Ciclo de

vida

Personas

(19)

Ciclos de vida (¿Cuando?)

z

Forma en que se organiza la ejecución básica del desarrollo de software

z

Representa la “columna vertebral” de un proceso

z

Hay modelos básicos:

z Caótico

z Secuencial

z Iterativo (por ciclos cortos de desarrollo)

z Desarrollo con reutilización

Ciclos de vida SECUENCIALES

z

Proponen la ejecución de etapas de manera

secuencial, es decir, una etapa inicia una vez que la anterior ha culminado por completo.

z

La construcción del producto de software se realiza completa al final del ciclo de vida.

z

El cliente obtiene el producto hasta el final del

proyecto y lo obtiene completo (en una sola

(20)

Ciclos de vida SECUENCIALES

z

Proponen la ejecución de etapas de manera

secuencial, es decir, una etapa inicia una vez que la anterior ha culminado por completo.

z

La construcción del producto de software se realiza completa al final del ciclo de vida.

z

El cliente obtiene el producto hasta el final del proyecto y lo obtiene completo (en una sola implantación).

Ciclo de vida: Cascada

Definición de Requisitos Definición de

Requisitos

Análisis Análisis

Diseño Diseño

Implementación del código fuerte y pruebas unitarias Implementación del código fuerte y pruebas unitarias

Integración y pruebas globales Integración y pruebas globales

(21)

Fases del modelo de cascada

z

Análisis y definición de requerimientos

z

Diseño del sistema y del software

z

Construcción (programación,

implementación) y pruebas de unidades

z

Integración y pruebas del sistema

z

Operación y mantenimiento

Problemas del modelo de cascada

z La principal desventaja del modelo de cascada es la dificultad de admitir el cambio una vez iniciado el proceso. Una fase debe concluirse antes de iniciar la siguiente.

z Particionamiento inflexible del proyecto en etapas hace difícil de responder a requerimientos

cambiantes del cliente.

(22)

Problemas del modelo de cascada

z Solo apropiado cuando los requerimientos son bien entendidos y se prevén pocos cambios (en los requerimientos o entorno) durante el proceso de diseño.

z Pocos negocios tienen requerimientos estables.

z Se usa el modelo para el desarrollo de grandes proyectos de ingeniería de sistemas donde un sistema es desarrollado en varios sitios.

Ciclo de vida: Cascada con prototipos

z

Similar al modelo de cascada pero se entrega un prototipo al final de la etapa de diseño (antes de empezar la implementación del código fuente).

z El prototipo puede ser funcional (tener parte del código implementado) o no serlo.

z El prototipo puede ser reutilizable (ser aprovechado para la versión final del producto) o no serlo (en cuyo caso no necesariamente es desarrollado en la misma herramienta en la que se implementará la versión final).

(23)

Definición de Requisitos Definición de

Requisitos

Análisis Análisis

Diseño y PROTOTIPO Diseño y PROTOTIPO

Implementación del código fuerte y pruebas unitarias Implementación del código fuerte y pruebas unitarias

Integración y pruebas globales Integración y pruebas globales

Ciclo de vida: Cascada con prototipos

Prototipado rápido

(24)

Ciclos de vida ITERATIVOS

z Proponen dividir la construcción del software en ciclos o iteraciones, donde:

z en cada iteración se alcanza determinado nivel de desarrollo ó

z en cada iteración se abarca una parte de la funcionalidad total del sistema

z Al final de cada iteración se realiza una presentación parcial del producto al cliente.

z Permite corregir errores durante la propia construcción del software.

Ciclo de vida: Incremental (Espiral de Booch)

Requerimientos y Análisis

Implementación Diseño

Pruebas

(25)

Espiral extendida

C0 CN : C3 C2 C1 Revisión y

Compromiso

Objetivos Alternativas y Restricciones

(0)

Identificación y Resolución de Riesgos

(1)

(2) Desarrollo del siguiente nivel

del Producto (3)

Planeación de siguientes Fases

Prototipo de descarte para resolución de

riesgos

Prototipo de descarte para definir incrementos CICLOS DE LA ESPIRAL

C0: ANÁLISIS DEL DOMINIO

C1: DEFINICIÓN DEL M.R.D.P. ESPECÍFICO

C2: ELABORACION DEL MODELO DE ESPECIFICACIONES DEL NÚCLEO BÁSICO DEL PRODUCTO C3: ELABORACIÓN DEL MODELO FUNCIONAL DEL NÚCLEO BÁSICO DEL PRODUCTO C4: ELABORACIÓN DEL MODELO EJECUTIVO DEL PROT OT IPO OPERACIONAL V1.0 C5: ELABORACIÓN MODELO DE IMPLEMENTARON Y V&V DEL PROT OT IPO OPERACIONAL V1.0 C6: CONST RUCCIÓN DEL PROT OT IPO OPERACIONAL V1.1

CN: CONST RUCCIÓN DEL PROT OT IPO OPERACIONAL V1.M

Ciclo de vida: Incremental

“en cada iteración se abarca una parte de la funcionalidad total del sistema”

z Propone dividir la funcionalidad del sistema en “bloques”

que se irán abarcando cada uno en un ciclo independiente.

z El cliente ve resultados parciales que contemplan una parte del producto funcionando al 100%.

z Al final de cada ciclo se integra lo realizado en ese ciclo con lo que ya estaba terminado.

z Normalmente, antes de iniciar el primer ciclo se realiza una fase

(26)

Ciclo de vida: Incremental

Definición Bosquejo de Requisitos Definición Bosquejo

de Requisitos

Asignar Requisitos a los Incrementos Asignar Requisitos a los Incrementos

Diseñar la Arquitectura del Sistema

Desarrollar Incrementos del Sistema Desarrollar Incrementos

del Sistema

Validar Incrementos

Integrar Incrementos

Integrar

Incrementos Validar SistemaValidar Sistema

Sistema Incompleto

Sistema Final

Cada incremento es un subproducto terminado.

Desarrollo incremental

Davis et al., 1988

(27)

Ventajas del desarrollo incremental

z Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.

z Los clientes pueden aclarar los requerimientos que no tengan claros conforme ven las entregas del sistema.

z Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.

z Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

Desventajas del desarrollo incremental

z

Cada incremento debe ser pequeño para limitar el riesgo (menos de 20,000 líneas).

z

Cada incremento debe aumentar la funcionalidad.

z

Es difícil mapear los requerimientos contra los incrementos.

z

Es difícil detectar las unidades o servicios

genéricos para todo el sistema.

(28)

Ciclo de vida: Evolutivo

“en cada iteración se alcanza determinado nivel de desarrollo”

Propone abarcar toda la funcionalidad del sistema desde el primer ciclo, de modo que se va refinando conforme se avanza en el desarrollo.

z El cliente ve resultados parciales que contemplan todo el producto completo (aunque en diferentes niveles de desarrollo: prototipo, prototipo validado, prototipo con conexión a la BD, etc.).

z Normalmente, el primer ciclo es muy pretencioso.

Modelo de desarrollo evolutivo

(29)

Desarrollo con reutilización

z

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización.

z

Este modelo consta de 4 fases.

Desarrollo con reutilización

z Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.

z Modificación de requerimientos: Se adaptan (en lo posible) los requerimientos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los

requerimientos, hay que seguir buscando componentes más adecuados (fase 1).

z Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.

Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

(30)

Desarrollo con reutilización

Ing. Dominios vsIng. Aplicaciones

Requerimientos

Proceso de desarrollo

Aplicación Inventario

de componentes

Generalizar Mercado abierto

Conceptos Sistemas existentes

Adquirir-adaptar Desarrollar

Re-ingeniería

Localizar, adaptar

Reutilizar

Aplicar la reutilización

Wooding, 1995

(31)

Ventajas de este modelo

z

Disminuye el costo y esfuerzo de desarrollo.

z

Reduce el tiempo de entrega.

z

Disminuye los riesgos durante el desarrollo.

z

Permite capitalizar experiencias y productos pasados, con posibilidad de aumentar

confiabilidad y calidad de los desarrollos.

Desventajas de este modelo:

z

Los acuerdos “de compromiso” en los requerimientos son inevitables, por lo cual puede que el software no cumpla las

expectativas del cliente.

z

Las actualizaciones de los componentes

adquiridos no están en manos de los

desarrolladores del sistema.

(32)

¿Cómo selecciono el ciclo de vida que mejor se adecua a mi proyecto?

Medio o Alto Medio o Alto

Alto Alto

Alto Espiral

Medio o Alto Medio o Alto

Alto Alto

Medio o Alto Incremental

Alto Alto

Bajo a Medio Bajo a Alto

Medio Desarrollo

Orientado a Reutilizació n

Bajo Bajo

Bajo a Medio Alto

Desarrollo Formal Bajo de Sistemas

Alto Alto

Medio Medio

Evolutivo Alto Prototipado

Bajo Bajo

Bajo Cascada

Medio Alto

Bajo Bajo

Bajo Codificar y Corregir

Visión del avance por el Cliente y el

Jefe del proyecto Permite correcciones

sobre la marcha Involucra

gestión de riesgos Produce software

altamente fiable Funciona con

requerimientos y arquitectura no

predefinidos Modelo de

proceso

Elementos de un Proceso de Desarrollo S.W.

Roles

vida

Paradigma Personas

(33)

Paradigma

z

Orientación a objetos

z

Estructurado

Elementos de un Proceso de Desarrollo S.W.

Roles Artefactos

Ciclo de vida

Notación y estándares Paradigma

Personas

(34)

Notación y estándares

z

UML

z

Diagrama de flujos de datos

Elementos de un Proceso de Desarrollo S.W.

Roles

vida Herramienta

Personas

(35)

Herramientas

z

Requerimientos: REM, Requisite Pro, Rational Rose

z

Pruebas: JUNIT

z

Análisis y Diseño: Rational Rose, Visio

z

Implementación: Java, Visual Basic .NET

Elementos de un Proceso de Desarrollo S.W.

Roles

Personas

(36)

Material de apoyo

z

Ejemplos

z

Plantillas

z

Guías

Plantillas para pruebas

[Comentarios, recomendaciones acerca de las tareas]

Observaciones:

[Resultados que se obtienen al aplicar la prueba]

Resultados obtenidos:

[Resultados que se esperan luego que se aplique la prueba]

Resultados esperados:

[Explicación general de la estrategia a aplicar para efectuar la prueba]

Estrategia:

[Identificación de los objetivos de la prueba]

Objetivos:

[Nombre de la persona que especifica la prueba]

[Nombre de la persona que aplica la prueba al software]

Responsable de especificación:

Responsable de aplicación:

Aceptación Sistema Integración Componentes Unitaria Otra __________

Tipo de prueba:

[Módulo al cual se le aplica la prueba]

Módulo:

__/__/____

Fecha de especificación:

Fecha de aplicación:

[Consecutivo de prueba]

No. Prueba:

[Número de iteración]

Iteración:

[Nombre de la fase]

Fase:

[Nombre del sistema]

Proyecto:

(37)

Plantilla Documento Visión

Portada

Debe incluir, como mínimo: logo de la empresa, nombre del departamento desarrollar y del departamento cliente, nombre y/o logo del producto, nombre del documento, fecha de entrega.

Tabla de contenidos

Debe mostrar los títulos (hasta 3 niveles) con la misma prioridad que tienen los apartados del documento. Se debe utilizar alguno de los estilos propuestos por la herramienta MSWord (p.e. Distinctive).

Introducción

La introducción de un documento de visión provee una visión general del documento completo. Inicialmente hace una breve presentación del documento y se especifica si se ha realizado de acuerdo con un método o estándar.

Definición del problema

En este apartado se hace una descripción del problema o necesidad que se pretende subsanar con el proyecto propuesto.

Involucrados

En esta sección se muestran todos los involucrados en el problema y cuál es la participación en el mismo.

Límites del sistema

En este apartado se establece todo lo que no se contempla como parte del desarrollo del sistema en el presente proyecto.

Restricciones del proyecto

Se definen las restricciones que se suponen en el proyecto: plataforma, recursos, tiempo, presupuesto, etc.

Guías

Errores comunes en el tratamiento de casos de uso

z Al describir casos de uso.

z Representar los pasos, las operaciones o las transacciones individuales como casos de uso.

z Ejemplo: Dentro de un sistema de Facturación, Imprimir Factura no es más que un paso de un proceso más amplio de un caso de uso Comprar Productos y no un caso de uso en sí mismo.

z Es importante tener siempre presente que un caso de uso es la descripción de un proceso de principio a fin.

(38)

Elementos de un Proceso de Desarrollo S.W.

Roles

Materiales de apoyo Prácticas y principios

Personas

Prácticas y principios

z

Modelado visual (RUP)

z

Arquitectura basada en componentes (RUP)

z

Proceso iterativo incremental (RUP)

z

Integración continua (XP)

z

Trabajar 40 horas a la semana (XP)

z

Cliente On-Site (XP)

z

Diseño simple (XP)

(39)

Temas

z Ejemplos de metodologías o marcos de trabajo

z Clasificación

z Ejemplos

Clasificación

z

Existen varios modelos de clasificación

z Según paradigma: Estructuradas u orientadas a objetos.

z Según prácticas: Tradicionales (pesadas) o ágiles.

(40)

Metodologías ágiles

z

Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana

comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento)

Ejemplos

Entre las metodologías ágiles identificadas encontramos:

z Extreme Programming.

z Scrum.

z Familia de Metodologías Crystal.

z Feature Driven Development.

z Proceso Unificado Rational, una configuración ágil.

z Dynamic Systems Development Method.

z Adaptive Software Development.

z Open Source Software Development.

(41)

Ejemplos

z

Algunos procesos de desarrollado

considerados no ágiles (de acuerdo a su configuración) son: Proceso Unificado Rational (RUP), METRICA 3, MERISE.

Temas

z Beneficios que brinda

(42)

Estructura definida

z Contar con una definición de proceso de software que describa elementos como actividades, roles, productos, notaciones, entre otros, permite que los miembros del equipo se concentren en la tarea y no tengan que preocuparse o les genere

incertidumbre el organizarse o definir la tarea durante la ejecución.

z La base de la mejora continua en la construcción de software es contar con una definición de proceso que permita ejecutarlo e identificar

claramente sus puntos débiles, con el propósito de mejorarlos.

Estructura definida

z La base para incorporar actividades de protección o flujos de trabajo relacionados con

aseguramiento de la calidad, control de versiones, planeación y seguimiento o medición es contar con una definición de proceso que describa

detalladamente las actividades fundamentales de requerimientos, análisis, diseño, construcción e implementación. Esta definición permite identificar los puntos donde es posible (y deseable)

incorporar las actividades de protección y buscar las técnicas más convenientes.

(43)

Estructura definida

z El proceso de software de una empresa

determinada refleja sus prácticas y principios, al ser estas incorporadas como hábitos de los miembros de los equipos de trabajo. Por ello es importante analizar con detenimiento si las prácticas y principios corresponden con los objetivos de la empresa.

Uso de estándares y notación

z El uso de estándares permite a los miembros del equipo desarrollar y a los usuarios hablar en los mismos términos. Esto cada día es más

necesario, debido a que los equipos se han vuelto multidisciplinarios y podrían involucrar a varias empresas.

(44)

Uso de estándares y notación

z El proceso de desarrollo de software es una secuencia de actividades relacionadas con los flujos de trabajo de requerimientos, análisis, diseño, implementación y pruebas. Cada flujo realiza una abstracción o representación de la necesidad; al pasar de un flujo a otro se corre el riesgo de representar la abstracción en una notación que pierda datos de interés, por ello es importante contar con notaciones que permitan dar continuidad sin pérdida de información importante y faciliten a los miembros del equipo entender la notación en que se expresan los artefactos provenientes de flujos anteriores a su participación.

Uso de estándares y notación

z Si se realiza mantenimiento o ampliación del software, el uso de estándares y una notación permitirá a nuevos encargados familiarizarse más rápidamente con lo desarrollado previamente y continuar con el mismo lineamiento.

z Por medio de estándares y una notación se definen de antemano los criterios que deben cumplir los productos para satisfacer los objetivos de calidad. Esto facilita el desarrollo y la revisión de productos durante la ejecución del proceso.