TEMARIO.

MODULO I. SOFTWARE.

1.1 CARACTERÍSTICAS DEL SOFTWARE

1.2 APLICACIONES DEL SOFTWARE

1.2.1 SOFTWARE DE SISTEMAS

1.2.2 SOFTWARE DE TIEMPO REAL

1.2.3 SOFTWARE DE GESTIÓN

1.2.4 SOFTWARE DE INGENIERÍA Y CIENTÍFICO

1.2.5 SOFTWARE EMPOTRADO

1.2.6 SOFTWARE DE COMPUTADORAS PERSONALES

1.2.7 SOFTWARE DE INGENIERÍA ARTIFICIAL PERSONAL

MODULO II. EL SOFTWARE CON PROCESO.

2.1 INGENIERÍA DE SOFTWARE

2.2 EL PROCESO DE SOFTWARE

2.3 MODELOS DEL PROCESO DE SOFTWARE

MODULO III. PARADIGMAS DEL SOFTWARE.

3.1 PARADIGMA DEL CICLO DE VIDA

3.2 PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS

3.3 PARADIGMA DE MODELO EN ESPIRAL

3.4 TÉCNICAS DE CUARTA GENERACIÓN

3.5 COMBINACIÓN DE PARADIGMAS

MODULO IV. ANÁLISIS Y ESPECIFICACIÓN DE REQUISITOS.

4.1 IDENTIFICACIÓN DE LOS REQUISITOS DEL SOFTWARE

4.2 ANÁLISIS DE REQUISITOS

4.3 DEFINICIÓN DE LOS REQUISITOS FUNCIONALES

4.4 DEFINICIÓN DE LOS REQUISITOS NO FUNCIONALES

4.5 ESPECIFICACIÓN DE LOS REQUISITOS DEL SOFTWARE

4.6 REVISIÓN DE LA ESPECIFICACIÓN

MODULO V. VISIÓN GENÉRICA DE LA INGENIERÍA DE SOFTWARE.

5.1 DEFINICIÓN

5.2 DESARROLLO

5.3 MANTENIMIENTO

MODULO VI. ADMINISTRACIÓN DE PROYECTOS.

6.1 IMPORTANCIA DE LA ADMINISTRACIÓN DE PROYECTOS

6.2 FUNCIONES DE LA ADMINISTRACIÓN DE PROYECTOS

6.3 QUE ES EL ADMINISTRADOR DE PROYECTOS

6.3.1 FUNCIONES DEL ADMINISTRADOR DE PROYECTOS

MODULO VII. LAS MÉTRICAS DEL PROYECTO.

7.1 MÉTRICAS DEL SOFTWARE

7.1.1 MÉTRICAS ORIENTADAS AL TAMAÑO

7.1.2 MÉTRICAS ORIENTADAS A LA FUNCIÓN

MODULO VIII. ESTIMACIÓN DEL PROYECTO.

8.1 MODELOS DE ESTIMACIÓN

8.2 TÉCNICAS DE DESCOMPOSICIÓN

8.2.1 BASADO EN EL TAMAÑO

8.2.2 BASADO EN EL PROBLEMA

8.2.3 BASADO EN EL NÚMERO DE LÍNEAS DE (LDC) CÓDIGO

8.2.4 BASADO EN EL PROCESO

ANTOLOGÍA

UNIVERSIDAD DE GUADALAJARA

CENTRO UNIVERSITARIO DE LOS LAGOS

MATERIA: INGENIERÍA DE SOFTWARE I

ALUMN0S:

ALEJANDRO FARIAS RAMIREZ

EDUARDO GONZALEZ LUNA

LAGOS DE MORENO, JALISCO.

INTRODUCCIÓN

En este trabajo se explican los paso comunes o básicos a seguir

para la generación de un software de calidad, así como la los

pasos a seguir para ir generando un software sin errores y

estable, por medio de pruebas.

Con la construcción de prototipos se realizaran los cambios

necesarios para un software de calidad, así completar los

prototipos por medio de diferentes paradigmas o métodos de

construcción para el software.

También se consideraran las métricas que deben de llevar los

programas para poder ofrecer un tiempo y costo del proyecto

para su posterior venta ahora nosotros te preguntamos como

desarrollador de software te preguntamos ¿Cuánto crees que

vale tu tiempo?

MODULO 1: SOFTWARE

1.1 Software

Se refiere al equipamiento lógico o soporte lógico de una

computadora digital, y comprende el conjunto de los

componentes lógicos necesarios para hacer posible la realización

de tareas específicas; en contraposición a los componentes

físicos del sistema, llamados hardware.

1.2 Características Del Software

1. El software se desarrolla o construye; no se manufactura en el

sentido clásico.

A pesar de que existen similitudes entre el desarrollo del

software y la manufactura del hardware, las dos actividades

serian diferentes en lo fundamental. En ambas la alta calidad se

alcanza por medio del buen diseño, la fase de manufactura del

hardware puede incluir problemas de calidad existentes en el

software.

2. El software no se desgasta.

El software es inmune a los males ambientales que desgasten el

hardware. Por lo tanto la curva de tasas de fallas para el

software debería tener la forma de la “curva idealizada”. Los

defectos sin descubrir causan tasas de fallas altas en las

primeras etapas de vida de un programa. Sin embargo, los errores

se corrigen y la curva se aplana: el software no se desgasta, pero

si se deteriora.

3. A pesar de que la industria tiene una tendencia hacia la

construcción por componentes, la mayoría del software aun se

construye a la medida.

1.2.1 Software De Sistema

En terminología informática el software de sistema, denominado

también software de base, consiste en programas informáticos que

sirven para controlar e interactuar con el sistema operativo,

proporcionando control sobre el hardware y dando soporte a

otros programas; en contraposición del llamado software de

aplicación. Como ejemplos cabe mencionar a las bibliotecas como

por ejemplo OpenGL para la aceleración gráfica, PNG para el

sistema gráfico o demonios que controlan la temperatura, la

velocidad del disco duro, como hdparm, o la frecuencia del

procesador como cpudyn.

Uno de los más prominentes ejemplos de software de sistema se

encuentra en el proyecto GNU, cuyas herramientas de

programación permitieron combinarse con el núcleo informático

basado en Unix denominado Linux, formando entre ambos las

conocidas como distribuciones Linux.

Estos programas realizan diversas tareas, como la transferencia

de datos entre la memoria RAM y los dispositivos de

almacenamiento (disco rígido, unidades de discos ópticos, etc)

entre otros.

1.2.2 Software De Tiempo Real

El software de tiempo real esta muy acoplado con el mundo

externo, esto es, el software de tiempo real debe responder al

ámbito del problema en un tiempo dictado por el ámbito del

problema. Debido a que el software de tiempo real debe operar

bajo restricciones de rendimiento muy rigurosas, el diseño del

software esta conducido frecuentemente, tanto por la

arquitectura del hardware como por la del software, por las

características del sistema operativo, por los requisitos de la

aplicación y tanto por los extras del lenguaje de programación

como prospectos de diseño.

La computadora digital se ha convertido en una maquina

omnipresente en al vida diaria de todos nosotros. Las

computadoras nos permiten ver juegos, así como contar el tiempo,

optimizar el gasto de gasolina de nuestras últimas generaciones de

coches y programar a nuestros aparatos.

Todas estas interacciones con las computadoras

1.2.3 Software de Gestión

Es un programa que sirve como herramienta la cual es

desarrollada especialmente para adecuarse a los diferentes

requerimientos de las empresas. Es una solución diseñada para

empresas medianas y grandes dinámicas con con necesidades de

alta competitividad, que buscan la eficiencia en sus procesos

internos y en la gestión con terceros Software de Gestión y

Programación.

1.2.4 Software De Ingeniería Y Científico

Utiliza algoritmos de manejo de números, simulación de sistemas,

utiliza software en tiempo real.

Astronomía, cálculo, Biología molecular, Fabricación automática.

1.2.5 Software Empotrado

Reside en memorias ROM y sirve para controlar productos y

sistemas de los mercados industriales.

Lavadoras, Microondas

1.2.6 Software Para PC

Aplicaciones orientadas a usuarios individuales o multiusuario

Procesadores de texto

Hojas de cálculo Juegos, Aplicaciones financieras, Gestores de

base de datos

1.2.7 Software De Inteligencia Artificial

Hace uso de algoritmos no numéricos para resolver complejos

para el que no son adecuados el cálculo o el análisis directo.

Sistemas Expertos

Reconocimiento de Patrones (OCR) Prueba de teoremas Redes

neuronales artificiales

1.2.8 Problemas Del Software

Defectos de diseño de programas

Diseños con colores inapropiados para las personas que padecen

daltonismo

Diseños que usan textos con tipografías de difícil lectura

por su tamaño o diseño.

Diseños que fuerzan el uso del ratón o mouse sin dejar

alternativas de teclado para personas con disfunciones

motrices.

Diseños con implicaciones culturales, por ejemplo usando

partes del cuerpo que en una determinada cultura sean

objeto de vergüenza o burla o símbolos con características

de identidad cultural o religiosa.

Estimar que el equipo donde se instalará tiene determinadas

características como la resolución de la pantalla, la

velocidad del procesador, la cantidad de memoria o

conectividad a internet

Objetos intrusivos y obstrusivos como cuadros de diálogo

modales al sistema o asistentes como "Clippy" (Clipo, en

español) que impedía el uso uniforme de Office de Microsoft.

Errores de programación comunes]

División por cero

Ciclo infinito

Problemas aritméticos como desbordamientos (overflow) o

subdesbordamientos (underflow).

Exceder el tamaño del array

Utilizar una variable no inicializada

Acceder a memoria no permitida (Access violation)

Pérdida de memoria (memory leak)

Desbordamiento o subdesbordamiento de la pila (estructura

de datos)

Buffer overflow

Deadlock

Indizado inadecuado de tablas en bases de datos.

Defectos de instalación o programación Eliminación o sustitución

de bibliotecas comunes a más de un programa o del sistema (DLL

Hell).

Reiniciar arbitrariamente la sesión de un usuario para que la

instalación tenga efecto.

Presuponer que el usuario tiene una conexión permanente a

internet.

Códigos de errores de lenguajes de programación

La mayor parte de los lenguajes de programación presentan al

menos dos tipos de errores que permiten a los programadores

manejar las fallas de los programas de una manera eficiente y que

no resulte agresiva con el usuario final. Dichos errores son de

compilación y errores en tiempo de ejecución.

MODULO2: SOFTWARE COMO PROCESO

2.1 Ingeniería De Software

La ingeniería del software es el desarrollo, operación y

mantenimiento del software de forma sistemática, disciplinada y

cuantificable, y el estudio de dichos métodos.

En otras palabras, es el estudio dedicado a la creación de

software de buena calidad, barato y fácil de desarrollar y

mantener. Es la aplicación de la ingeniería al software.

La ingeniería del software comienza a formalizarse a finales de la

década del 1960. Con el transcurso de los años se han

desarrollado recursos que conforman la ingeniería del software,

es decir, herramientas y técnicas de especificación, diseño e

implementación del software.

2.2 El Proceso Del Software

Conjunto estructurado de actividades requeridas para

desarrollar un sistema de software.

Especificación.

Diseño.

Validación.

Evolución.

Las actividades varían dependiendo de la organización y del tipo de

sistema a desarrollarse.

Debe estar explícitamente modelado si va a ser bien administrado.

Características

Entendible

Se encuentra el proceso bien definido y es entendible?

Visible

El proceso es visible al exterior?

Soportable

Puede el proceso ser soportado por herramientas CASE?

Aceptable

El proceso es aceptado por aquellos involucrados en el ?.

Confiable

Los errores del proceso son descubiertos antes de que se

conviertan en errores del producto?

Robusto

Puede continuar el proceso a pesar de problemas inesperados?

Mantenible

Puede el proceso evolucionar para cumplir con los objetivos

organizacionales ?

Rapidez

Que tan rápido puede producirse el sistema?

Problemas

Normalmente, las especificaciones son incompletas o anómalas.

No existe una distinción precisa entre la especificación, el diseño y

la manufactura

Solo hasta que el sistema se ha producido se puede probar

El software no se puede remplazar siempre durante el

mantenimiento

2.3 MODELOS DEL PROCESO DEL SOFTWARE

Los estándares establecen los diferentes procesos implicados a

la hora de desarrollar y mantener un sistema desde que surge la

idea o necesidad de desarrollar las aplicaciones hasta que éstas

se retiran de explotación. Sin embargo, ninguno impone un modelo

de procesos concreto (modelo de ciclo de vida) ni cómo realizar

las diferentes actividades incluidas en cada proceso, por lo que

cada empresa deberá utilizar los métodos, técnicas y herramientas

que considere oportuno.

Por su naturaleza, los modelos son simplificaciones; por lo tanto,

un modelo de procesos del software es una simplificación o

abstracción de un proceso real. Podemos definir un modelo de

procesos del software como una representación abstracta de

alto nivel de un proceso software.

Cada modelo es una descripción de un proceso software que se

presenta desde una perspectiva particular. Alternativamente,

A veces se usan los términos ciclo de vida y Modelo de ciclo de

vida.

Cada modelo describe una sucesión de fases y un encadenamiento

entre ellas. Según las fases y el modo en que se produzca este

encadenamiento, tenemos diferentes modelos de proceso. Un

modelo es más adecuado que otro para desarrollar un proyecto

dependiendo de un conjunto de características de éste. Existe una

gran variedad de modelos diferentes entre los que tenemos los

que se describen a continuación.

MODULO 3: PARADIGMAS DEL SOFTWARE

3.1. Paradigma Ciclo De Vida Del Software

Este fue el modelo inicial planteado para organizar el proceso de

desarrollo, aunque antiguo tiene vigencia en algunos proyectos o

como parte de otros modelos, da la medida de los pasos

tradicionales de cualquier modelo: análisis, diseño, codificación,

prueba y mantenimiento.

Ingeniería y análisis del sistema. Debido a que el software es

siempre parte de un sistema mayor el trabajo comienza

estableciendo todos los requerimientos o elementos del sistema y

luego asignando algún subconjunto de estos requerimientos al

software; esta versión del sistema es esencial cuando el software

debe interrelacionarse con otros elementos tales como

hardware, personas y bases de datos.

La ingeniería y análisis del sistema abarcan los requerimientos

globales a un nivel de sistema con una pequeña cantidad de análisis

y diseño a nivel superior. Además de un análisis costo beneficio del

sistema es decir si toda la inversión que se hará para el sistema

conviene a los beneficios que traerá el mismo.

Análisis de los requerimientos del software. El proceso de

recoger los requerimientos se centra y se intensifica

especialmente en esta etapa. Para comprender la naturaleza de los

programas que hay que construir. El ingeniero de software debe

comprender el dominio de la información del software, así como la

función, rendimiento e interfaces requeridas. En esta etapa los

requerimientos del sistema se documentan y se analizan con el

cliente.

Diseño. El diseño del software es realmente un proceso multipaso

que se enfoca sobre 3 atributos del programa.

estructura de datos

arquitectura de software

detalle procedimental

El diseño traduce los requerimientos en una representación del

software que pueda ser establecida de forma que obtenga la

calidad requerida antes que comience la codificación. Como los

requerimientos y el diseño que se documentan forman parte de la

configuración del software.

Codificación. El diseño debe traducirse en una forma legible. El

paso de la codificación ejecuta la tarea de establecer la etapa de

diseño legible para la maquina, si el diseño se ejecuta de una

manera detallada la codificación puede realizarse mecánicamente.

Prueba. Una vez que se ha generado el código, comienza la prueba

del programa, la prueba se enfoca sobre la lógica interna del

software asegurando que todas las sentencias se han probado y

sobre las funciones externas estoy realizando pruebas para

asegurar que la entrada definida producirá los resultados que

realmente se requieren.

Mantenimiento. El software sufrirá indudablemente cambios

después que se le entregue al cliente los cambios ocurrirán

debido a que se han encontrado errores, causados por cambios

del entorno externo por ejemplo un cambio solicitado debido al

cambio del Sistema Operativo o dispositivos periféricos, o debido

que el cliente requiere aumentos en las funciones del sistema. El

mantenimiento del software se aplica cada uno de los pasos

precedentes del ciclo de vida a un programa existente en lugar de

uno nuevo.

El ciclo de vida clásico es el más viejo y más ampliamente usado

paradigma en la ingeniería de software. Sin embargo con el paso de

unos cuantos años se han producido criticas al paradigma, incluso

por seguidores activos que cuestionan su aplicabilidad a todas las

situaciones. Entre los problemas que se presentan algunas veces

cuando se aplica este paradigma se encuentran:

1. Los proyectos reales raramente siguen el flujo secuencial

que propone el modelo, siempre ocurre iteraciones y se crea

problemas en la aplicación del paradigma.

2. Normalmente es difícil para el cliente establecer

explícitamente el principio todos los requerimientos del

sistema. El ciclo de vida clásico requiere esto y tiene

dificultades para acomodar posibles incertidumbres que

puedan existir al comienzo de dichos proyectos.

3. El cliente debe tener paciencia. Una versión funcional del

programa no esta disponible hasta las etapas finales del

desarrollo del proyecto. Un error importante no detectado

hasta que el programa este en funcionamiento puede ser

desastroso.

4. Los responsables del desarrollo se retrasan

innecesariamente.

3.2 Paradigma De Construcción De Prototipos.

Este modelo también denominado modelo de desarrollo

evolutivo. Para comprender este modelo, comenzaremos con

la definición de los objetivos globales para el software,

después identificaremos los requerimientos que conocemos y

los sitios del diseño en donde es necesaria más definición.

Entonces planteamos con rapidez una iteración de

construcción de prototipos y se presenta el modelado (en

forma de un diseño rápido).

Los modelos evolutivos son iterativos; los caracteriza la

forma en que permiten que los ingenieros de software

desarrollen versiones cada vez más completas del software.

El diseño rápido se basa en una representación de aquellos

aspectos del software que serán visibles para el cliente o el

usuario final (por ejemplo, la configuración de la interfaz

con el usuario y el formato de los despliegues de salida). El

diseño rápido conduce a la construcción de un prototipo, el

cual es evaluado por el cliente o el usuario para una

retroalimentación; gracias a ésta se refinan los requisitos

del software que se desarrollará. La iteración ocurre

cuando el prototipo se ajusta para satisfacer las

necesidades del cliente. Esto permite que al mismo tiempo el

desarrollador entienda mejor lo que se debe hacer y el

cliente vea resultados a corto plazo.

CONSTRUCCION DE PROTOTIPOS

A menudo un cliente define un conjunto de objetivos

generales para el software, pero no identifica los requisitos

detallados de entrada, procesamiento o salida. El

responsable del desarrollo del software está inseguro de

la eficacia de un algoritmo, de la adaptabilidad de un sistema

operativo o de la forma que debería tomar la interacción

humana – máquina, entonces en este caso cuando utilizamos

la construcción de prototipos.

El paradigma de construcción de prototipos se inicia con la

comunicación. El ingeniero de software y el cliente

encuentran y definen los objetivos globales para el

software, identifican los requisitos conocidos y las áreas

del esquema en donde es necesaria más definición. Entonces

se plantea con rapidez una iteración de construcción de

prototipos y se presenta el modelado (en la forma de un

diseño rápido). El diseño rápido se centra en una

representación de aquellos aspectos del software que

serán visibles para el usuario final. El diseño rápido conduce

a la construcción de un prototipo. Después, el prototipo lo

evalúa el usuario y con la retroalimentación se refinan los

requisitos del software que se desarrollará. La iteración

ocurre cuando el prototipo se ajusta para satisfacer las

necesidades del cliente. Esto permite que al mismo tiempo se

desarrollador entienda mejor lo que se debe hacer.

Ventajas:

No modifica el flujo del ciclo de vida.

Reduce el riesgo de construir productos que no

satisfagan las necesidades de los usuarios.

Reduce costos y aumenta la probabilidad de éxito.

Exige disponer de las herramientas adecuadas.

No presenta calidad ni robustez.

Una vez identificados todos los requisitos mediante el

prototipo, se construye el producto de ingeniería.

Desventajas

A los usuarios les gusta el sistema real y a los

desarrolladores les gusta construir algo de inmediato. Sin

embargo, la construcción de prototipos se torna

problemática por las siguientes razones:

El cliente ve funcionando lo que para el es la primera

versión del prototipo que ha sido construido con “chicle y

cable para embalaje”, y puede decepcionarse al indicarle que

el sistema aun no ha sido construido.

El desarrollador puede caer en la tentación de aumentar

el prototipo para construir el sistema final sin tener en

cuenta las obligaciones de calidad y de mantenimiento que

tiene con el cliente.

3.3 Paradigma De Modelo En Espiral.

Es un modelo de proceso de software evolutivo. En el modelo

espiral, el software se desarrolla en una serie de versiones

increméntales. Durante las primeras iteraciones. La versión

incremental podría ser un modelo en papel o un prototipo. Durante

las últimas iteraciones, se producen versiones cada vez mas

completas de ingeniería del sistema.

Características:

Es también al igual que el anterior un modelo evolutivo que

combina el modelo clásico con el diseño de prototipos.

Incluye la etapa de análisis de riesgos, no incluida

anteriormente.

Es ideal para crear productos con diferentes versiones

mejoradas como se hace con el software moderno de

microcomputadoras.

La ingeniería puede desarrollarse a través del ciclo de vida

clásico o el de construcción de prototipos.

Este es el enfoque más realista actualmente.

El modelo en espiral se divide en un número de actividades

estructurales, también llamadas regiones de tareas.

Generalmente, existen entre tres y seis regiones de tareas.

Comunicación con el cliente: las tareas requeridas para

establecer comunicación entre el desarrollador y el cliente.

Planificación: las tareas requeridas para definir recursos, el

tiempo y otras informaciones relacionadas con el proyecto. Son

todos los requerimientos.

Análisis de riesgos: las tareas requeridas para evaluar riesgos

técnicos y otras informaciones relacionadas con el proyecto.

Ingeniería: las tareas requeridas para construir una o más

representaciones de la aplicación.

Construcción y adaptación: las tareas requeridas para construir,

probar, instalar y proporcionar soporte al usuario.

Evaluación el cliente: las tareas requeridas para obtener la

reacción del cliente según la evaluación de las representaciones

del software creadas durante la etapa de ingeniería e

implementación durante la etapa de instalación.

Cuando empieza el proceso evolutivo, el equipo de ingeniería del

software gira alrededor de la espiral en la dirección de las

agujas del reloj, comenzando por el centro. El primer circuito de

la espiral produce el desarrollo de una especificación de

productos; los pasos siguientes en la espiral se podrían utilizar

para desarrollar un prototipo y progresivamente versiones mas

sofisticadas del software. Cada paso de la región de planificación

produce ajustes en el plan del proyecto. El coste y la

planificación se ajustan según la reacción ante la evolución del

cliente.

Ventajas:

El modelado en espiral puede adaptarse y aplicarse a lo

largo de la vida del software de computadora, no terminal

cuando se entrega el software.

Como el software evoluciona, a medida que progresa el

proceso, el desarrollador y el cliente comprenden y

reaccionan mejor ante riesgos en cada uno de los niveles

evolutivos.

Permite a quien lo desarrolla aplicar el enfoque de

construcción de prototipos en cualquier etapa de evolución

del producto.

Demanda una consideración directa de los riesgos técnicos

en todas las etapas del proyecto.

Reduce los riesgos antes de que se conviertan en

problemáticos.

Pero al igual que otros paradigmas puede resultar difícil

convencer a grandes clientes de que el enfoque evolutivo es

controlable. Si un riesgo importante no es descubierto y

gestionado, indudablemente surgirán problemas. El modelo en sí

mismo es relativamente nuevo y no se ha utilizado tanto como los

paradigmas lineales secuenciales o de construcción de

prototipos. Todavía tendrán que pasar muchos años antes de que

se determine con absoluta certeza la eficacia de este nuevo e

importante paradigma.

La siguiente figura define un eje de punto de entrada en el

proyecto. Cada uno de los cubos situados a lo largo del eje

representan el punto de arranque para un tipo diferente de

proyecto. Un proyecto de desarrollo de conceptos comienza en el

centro de la espiral y continuara hasta que se completa el

desarrollo del concepto. Si el concepto se va a desarrollar

dentro de un producto real, el proceso procede a través del cubo

siguiente y se inicia un nuevo proyecto de desarrollo.

Problemas:

Demostrar al cliente "exigente" (bajo contrato) que el

enfoque evolutivo es controlable.

Requiere gran habilidad y experiencia para valorar el riesgo y

saber cuando detener la evolución

3.4 Paradigma De Técnicas De Cuarta Generación

El termino de técnicas de cuarta generación (T4G) abarca un

amplio espectro de herramientas de software ha especificar

algunas características de alto nivel. Luego la herramienta

genera automáticamente el código fuente basándose en la

especificación del técnico. Existe cierto debate sobre cuanto ha

de elevarse el nivel en el que se especifique el software para una

maquina. El paradigma de T4G para la ingeniería de software se

orienta hacia la habilidad de especificar software a un nivel que

sea más próximo al lenguaje natural o a una notación que

proporcione funciones significativas.

Actualmente un entorno para el desarrollo del software que

soporte el paradigma de T4G incluye algunas o todas las

siguientes herramientas: lenguajes no procedimentales para

consulta a base de datos, generación de informes, manipulación de

datos, interacción y definición de pantallas y generación de

códigos, capacidades gráficas de alto nivel y capacidad de hojas

de cálculo. Cada una de estas herramientas existen, pero solo son

para dominios de aplicación muy específicos. No existe hoy

disponible un entorno deT4G que pueda aplicarse con igual

facilidad a todas las categorías de aplicaciones de software.

El paradigma T4G para la ingeniería de software se describe en la

siguiente figura:

3.5 Combinación De Paradigmas

Frecuentemente se describe a los paradigmas de la ingeniería de

software tratados en las secciones anteriores como métodos

alternativos, para la ingeniería de software en vez de los métodos

complementarios.

En muchos casos los paradigmas pueden y deben combinarse en

forma que puedan utilizarse las ventajas de cada uno en un único

proyecto.

La siguiente figura muestra como pueden combinarse los 3

paradigmas mencionados durante un trabajo de desarrollo del

software, en todos los casos el trabajo comienza con la

recolección de requerimientos. El método puede seguir el ciclo de

vida clásico (ingeniería de sistemas análisis de requerimiento de

software) o puede ser la definición menos formal del problema

usada en la construcción de un prototipo, independientemente

debe producirse la comunicación cliente-realizador del software.

La naturaleza de aplicación dictara la aplicabilidad del método de

construcción de prototipos. Si los requerimientos para la función

y rendimiento del software están razonablemente bien

comprendidos pueden ser aplicables los métodos de

especificación recomendados para el ciclo de vida clásico. Por

otra parte si la aplicación del software exige una fuerte

interacción hombre-maquina o requiere algoritmos no probados o

técnicas de control de salidas pueden regresarse a un prototipo.

En tales casos puede usarse un lenguaje de cuarta generación

para el desarrollo de un prototipo. Una vez que se haya evaluado y

reafinado el prototipo pueden aplicarse los pasos de diseño e

implementación del ciclo de vida clásico para desarrollar el

software formalmente.

MODULO 4: ANALISIS Y ESPECIFICACIÓN DE REQUISITOS

4.1 Identificación De Requerimientos.

Se identificaron cuáles son las funciones principales del sistema

y se asignó una prioridad. A través de una descripción de cada

componente según la visión de los usuarios finales (docentes,

alumnos, administradores) que expresaron sus necesidades y

expectativas de la herramienta.

htttp://penguien.ens.uabc.mx/~uvirtual/

Se pueden identificar dos formas de requisitos:

Requisitos de usuario: Los requisitos de usuario son frases

en lenguaje natural junto a diagramas con los servicios que

el sistema debe proporcionar, así como las restricciones

bajo las que debe operar.

Requisitos de sistema: Los requisitos de sistema determinan

los servicios del sistema y pero con las restricciones en

detalle. Sirven como contrato.

Es decir, ambos son lo mismo, pero con distinto nivel de detalle.

Ejemplo de requisito de usuario: El sistema debe hacer préstamos

Ejemplo de requisito de sistema: Función préstamo: entrada código

socio, código ejemplar; salida: fecha devolución; etc.

Se clasifican en tres los tipos de requisitos de sistema:

Requisitos funcionales

Los requisitos funcionales describen:

Los servicios que proporciona el sistema (funciones).

La respuesta del sistema ante determinadas entradas.

El comportamiento del sistema en situaciones particulares.

Requisitos no funcionales

Los requisitos no funcionales son restricciones de los servicios

o funciones que ofrece el sistema (ej. cotas de tiempo, proceso de

desarrollo, rendimiento, etc.)

Ejemplo 1. La biblioteca Central debe ser capaz de atender

simultáneamente a todas las bibliotecas de la Universidad

Ejemplo 2. El tiempo de respuesta a una consulta remota no

debe ser superior a 1/2 s

A su vez, hay tres tipos de requisitos no funcionales:

Requisitos del producto. Especifican el comportamiento del

producto (Ej. prestaciones, memoria, tasa de fallos, etc.)

Requisitos organizativos. Se derivan de las políticas y

procedimientos de las organizaciones de los clientes y

desarrolladores (Ej. estándares de proceso, lenguajes de

programación, etc.)

Requisitos externos. Se derivan de factores externos al

sistema y al proceso de desarrollo (Ej. requisitos

legislativos, éticos, etc.)

Requisitos del dominio.

Los requisitos del dominio se derivan del dominio de la aplicación y

reflejan características de dicho dominio.

Pueden ser funcionales o no funcionales.

Ej. El sistema de biblioteca de la Universidad debe ser capaz de

exportar datos mediante el Lenguaje de Intercomunicación de

Bibliotecas de España (LIBE). Ej. El sistema de biblioteca no podrá

acceder a bibliotecas con material censurado.

4.2 Análisis De Requisitos

Al inicio de un desarrollo (no de un proyecto), esta es la primera

fase que se realiza, y, según el modelo de proceso adoptado, puede

casi terminar para pasar a la próxima etapa (caso de Modelo

Cascada Realimentado) o puede hacerse parcialmente para luego

retomarla (caso Modelo Iterativo Incremental u otros de

carácter evolutivo).

En simple palabras y básicamente, durante esta fase, se adquieren,

reúnen y especifican las características funcionales y no

funcionales que deberá cumplir el futuro programa o sistema a

desarrollar.

Las bondades de las características, tanto del sistema o programa

a desarrollar, como de su entorno, parámetros no funcionales y

arquitectura dependen enormemente de lo bien lograda que esté

esta etapa. Esta es, probablemente, la de mayor importancia y una

de las fases más difíciles de lograr certeramente, pues no es

automatizable, no es muy técnica y depende en gran medida de la

habilidad y experiencia del analista que la realice.

Involucra fuertemente al usuario o cliente del sistema, por tanto

tiene matices muy subjetivos y es difícil de modelar con certeza y/o

aplicar una técnica que sea "la más cercana a la adecuada" (de

hecho no existe "la estrictamente adecuada"). Si bien se han ideado

varias metodologías, incluso software de apoyo, para captura,

licitación y registro de requisitos, no existe una forma infalible o

absolutamente confiable, y deben aplicarse conjuntamente buenos

criterios y mucho sentido común por parte del o los analistas

encargados de la tarea; es fundamental también lograr una fluida

y adecuada comunicación y comprensión con el usuario final o

cliente del sistema.

El artefacto más importante resultado de la culminación de esta

etapa es lo que se conoce como especificación de requisitos

software o simplemente documento ERS.

Como se dijo, la habilidad del analista para interactuar con el

cliente es fundamental; lo común es que el cliente tenga un

objetivo general o problema a resolver, no conoce en absoluto el

área (informática), ni su jerga, ni siquiera sabe con precisión qué

debería hacer el producto software (qué y cuantas funciones) ni,

mucho menos, cómo debe operar. En otros casos menos

frecuentes, el cliente "piensa" que sabe precisamente lo que el

software tiene que hacer, y generalmente acierta muy

parcialmente, pero su empecinamiento entorpece la tarea de

licitación. El analista debe tener la capacidad para lidiar con este

tipo de problemas, que incluyen relaciones humanas; tiene que

saber ponerse al nivel del usuario para permitir una adecuada

comunicación y comprensión.

Escasas son las situaciones en que el cliente sabe con certeza e

incluso con completitud lo que requiere de su futuro sistema, este

es el caso más sencillo para el analista.

Las tareas relativas a captura, licitación, modelado y registro de

requerimientos, además de ser sumamente importante, puede llegar

a ser dificultosa de lograr acertadamente y llevar bastante

tiempo relativo al proceso total del desarrollo; al proceso y

metodologías para llevar a cabo este conjunto de actividades

normalmente se las asume parte propia de la Ingeniería de

Software, pero dada la antedicha complejidad, actualmente se

habla de una Ingeniería en Requisitos[11] , aunque ella aún no existe

formalmente.

Hay grupos de estudio e investigación, en todo el mundo, que están

exclusivamente abocados a la idear modelos, técnicas y procesos

para intentar lograr la correcta captura, análisis y registro de

requerimientos. Estos grupos son los que normalmente hablan de

la Ingeniería en Requisitos; es decir se plantea ésta como un área o

disciplina pero no como una carrera universitaria en si misma.

Algunos requisitos no necesitan la presencia del cliente, para ser

capturados y/o analizados; en ciertos casos los puede proponer

el mismo analista o, incluso, adoptar unilateralmente decisiones

que considera adecuadas (tanto en requerimientos funcionales

como no funcionales). Por citar ejemplos probables: Algunos

requisitos sobre la arquitectura del sistema, requisitos no

funcionales tales como los relativos al rendimiento, nivel de

soporte a errores operativos, plataformas de desarrollo,

relaciones internas o ligas entre la información (entre registros

o tablas de datos) a almacenar en caso de bases o bancos de

datos, etc. Algunos funcionales tales como opciones secundarias

o de soporte necesarias para una mejor o más sencilla

operatividad; etc.

La obtención de especificaciones a partir del cliente (u otros

actores intervinientes) es un proceso humano muy interactivo e

iterativo; normalmente a medida que se captura la información, se

la analiza y realimenta con el cliente, refinándola, puliéndola y

corrigiendo si es necesario; cualquiera sea el método de ERS

utilizado. EL analista siempre debe llegar a conocer la temática y

el problema a resolver, dominarlo, hasta cierto punto, hasta el

ámbito que el futuro sistema a desarrollar lo abarque. Por ello el

analista debe tener alta capacidad para comprender problemas de

muy diversas áreas o disciplinas de trabajo (que no son

específicamente suyas); así por ejemplo, si el sistema a desarrollar

será para gestionar información de una aseguradora y sus

sucursales remotas, el analista se debe compenetrar en cómo ella

trabaja y maneja su información, desde niveles muy bajos e incluso

llegando hasta los gerenciales. Dada a gran diversidad de campos

a cubrir, los analistas suelen ser asistidos por especialistas, es

decir gente que conoce profundamente el área para la cual se

desarrollará el software; evidentemente una única persona (el

analista) no puede abarcar tan vasta cantidad de áreas del

conocimiento. En empresas grandes de desarrollo de productos

software, es común tener analistas especializados en ciertas

áreas de trabajo.

Contrariamente, no es problema del cliente, es decir él no tiene

por qué saber nada de software, ni de diseños, ni otras cosas

relacionadas; sólo se debe limitar a aportar objetivos, datos e

información (de mano propia o de sus registros, equipos,

empleados, etc.) al analista, y guiado por él, para que, en primera

instancia, defina el "Universo de Discurso", y con posterior

trabajo logre confeccionar el adecuado documento ERS.

Es bien conocida la presión que sufren los desarrolladores de

sistemas informáticos para comprender y/o rescatar las

necesidades de los clientes/usuarios. Cuanto más complejo es el

contexto del problema más difícil es lograrlo, a veces se fuerza a

los desarrolladores a tener que convertirse en casi expertos de

los dominios que analizan.

Cuando esto no sucede es muy probable que se genere un conjunto

de requisitos[12] erróneos o incompletos y por lo tanto un

producto de software con alto grado de desaprobación por parte

de los clientes/usuarios y un altísimo costo de reingeniería y

mantenimiento. Todo aquello que no se detecte, o resulte mal

entendido en la etapa inicial provocará un fuerte impacto negativo

en los requisitos, propagando esta corriente degradante a lo

largo de todo el proceso de desarrollo e incrementando su

perjuicio cuanto más tardía sea su detección (Bell y Thayer 1976)

(Davis 1993).

4.3 Definición de Requisitos Funcionales

En tecnología de dotación lógica, a requisito funcional define una

función de a sistema de software o su componente. Una función se

describe como sistema de entradas, del comportamiento, y de las

salidas (véase también software).

Los requisitos funcionales pueden ser cálculos, detalles

técnicos, manipulación de datos y el proceso y la otra

funcionalidad específica que demuestran cómo a utilice el caso es

ser satisfecho. Se apoyan cerca requisitos no funcionales, que

imponen apremios ante el diseño o la puesta en práctica (tal como

requisitos de funcionamiento, seguridad, o confiabilidad).

Según lo definido adentro ingeniería de requisitos, los requisitos

funcionales especifican comportamientos particulares de un

sistema. Esto se debe poner en contraste con requisitos no

funcionales cuáles especifican características totales tales

como coste y confiabilidad.

Típicamente, un analista de los requisitos genera requisitos

funcionales después de construir utilice los casos. Sin embargo,

esto puede tener excepciones puesto que el desarrollo del

software es un proceso iterativo y requisitos a veces ciertos se

conciben antes de la definición de los casos del uso. Ambos

artefactos (el uso encajona documentos y documentos de los

requisitos) compleméntese en un proceso bidireccional.

Proceso

Un requisito funcional típico contendrá un nombre y un número

único, un breve resumen, y un análisis razonado. Esta información

se utiliza para ayudar al lector a entender porqué el requisito es

necesario, y a seguir el requisito con el desarrollo del sistema.

4.4 Definición De Los Requisitos No Funcionales

Un requisito no funcional (NFR) especifica los criterios que se

deben usar para juzgar el funcionamiento de un sistema (operación

of a system), en lugar de un comportamientos específico (specific

behavior). En general, los requisitos funcionales definen lo que el

sistema debería de hacer, mientras que los requisitos no

funcionales verifican cómo un sistema debería de ser. Requisitos

no funcionales son a menudo llamados las “cualidades de un

sistema”. Puede dividirse en dos categorías:

1. Execution qualities: como por ejemplo la seguridad y facilidad

de uso, que son observables en tiempo de ejecución.

2. Evolution qualities, como por ejemplo el mantenibilidad,

extensibilidad y escalabilidad, que están más vinculados a la

estructura del sistema de software.

Algunos ejemplos de requerimientos no funcionales son:

Accesibilidad, Auditoría y control, Disponibilidad, Copia de

seguridad, Capacidad actual y previsiones, Certificación,

Recuperación de Desastres, Eficiencia (consumo de recursos para

la carga dada), Eficacia (resultante de rendimiento en relación con

el esfuerzo), Extensibilidad, Interoperabilidad, Mantenimiento,

Operatividad, Rendimiento / Tiempo de respuesta (véase el

rendimiento de Ingeniería), Portabilidad, Recuperación, Fiabilidad

(por ejemplo, Tiempo medio entre fallos – MTBF), Las limitaciones

de recursos (la velocidad del procesador, memoria, espacio en

disco, ancho de banda de red etc.), Tiempo de respuesta, Robustez,

Escalabilidad (horizontal, vertical), Seguridad, Estabilidad,

Seguridad,

Una buena definición de requerimientos no funcionales (NFR) es

tan importante como los requisitos funcionales. Deben de ser

apropiadamente definidos, analizados y trazados.

4.5 Especificación De Requisitos Del Software

Una especificación de requisitos del software es una descripción

completa del comportamiento del sistema a desarrollar. Incluye

un conjunto de casos de uso que describen todas las

interacciones que se prevén que los usuarios tendrán con el

software. También contiene requisitos no funcionales (o

suplementarios). Los requisitos no funcionales son los requisitos

que imponen restricciones al diseño o funcionamiento del sistema

(tal como requisitos de funcionamiento, estándares de calidad, o

requisitos del diseño).

Las estrategias recomendadas para la especificación de los

requisitos del software están descritas por IEEE 830-1998. Este

estándar describe las estructuras posibles, contenido deseable, y

calidades de una especificación de requisitos del software.

Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efectúe el

software. Ej.: el sistema debe emitir un comprobante al

asentar la entrega de mercadería.

No funcionales: son los "recursos" para que trabaje el

sistema de información (redes, tecnología). Ej.: el soporte de

almacenamiento a usar debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual

en el cual se implantará el sistema para conseguir un

objetivo macro. Ej.: abaratar costos de expedición.

4.6 Revisión De La Especificación

Personal involucrado: Cliente y analista

• Nivel macroscópico - Verificar que es completa, consistente y

exacta

: ¿Metas y objetivos?

: ¿Interfaces?

: ¿Flujo y estructura de la información?

Nivel macroscópico (II)

: ¿Inconsistencias, omisiones, redundancias?

: ¿Prototipo o manual de usuario?

: ¿Diagramas claros?

Nivel detallado

• Conectores persuasivos (ciertamente, claramente,

obviamente,...)

• Términos imprecisos (algunos, a veces, normalmente, en la

mayoría de ....)

• Términos de certidumbre (siempre, todos, nunca, ...)

Nivel detallado (II)

• Rangos: (10..100) ¿enteros, reales?

• Ejemplos para los cálculos

• No ambigüedad

OBJETIVO / FINALIDAD

• Revisión -> Firma del documento ERS

• CONTRATO entre cliente y empresa

• Cambios en requisitos ->

• Ampliación plazos fechas, costes y

• modificación del ámbito del sistema

MODULO 5: VISIÓN GENERICA DE LA INGENIERIA DE SOFTWARE

5.1 Definición

Según la definición del IEEE, citada por [Lewis 1994] "software es

la suma total de los programas de computadora, procedimientos,

reglas, la documentación asociada y los datos que pertenecen a

un sistema de cómputo". Según el mismo autor, "un producto de

software es un producto diseñado para un usuario". En este

contexto, la Ingeniería de Software (SE del inglés Software

Engineering) es un enfoque sistemático del desarrollo, operación,

mantenimiento y retiro del software", que en palabras más llanas,

se considera que "la Ingeniería de Software es la rama de la

ingeniería que aplica los principios de la ciencia de la computación

y las matemáticas para lograr soluciones costo-efectivas

(eficaces en costo o económicas) a los problemas de desarrollo

de software", es decir, "permite elaborar consistentemente

productos correctos, utilizables y costo-efectivos" [Cota 1994].

5.2 Desarrollo

El proceso de ingeniería de software se define como "un conjunto

de etapas parcialmente ordenadas con la intención de logra un

objetivo, en este caso, la obtención de un producto de software

de calidad" [Jacobson 1998].El proceso de desarrollo de

software "es aquel en que las necesidades del usuario son

traducidas en requerimientos de software, estos requerimientos

transformados en diseño y el diseño implementado en código, el

código es probado, documentado y certificado para su uso

operativo". Concretamente "define quién está haciendo qué,

cuándo hacerlo y cómo alcanzar un cierto objetivo" [Jacobson

1998].

El proceso de desarrollo de software requiere por un lado un

conjunto de conceptos, una metodología y un lenguaje propio. A

este proceso también se le llama el ciclo de vida del software que

comprende cuatro grandes fases: concepción, elaboración,

construcción y transición. La concepción define le alcance del

proyecto y desarrolla un caso de negocio. La elaboración define

un plan del proyecto, especifica las características y fundamenta

la arquitectura. La construcción crea el producto y la transición

transfiere el producto a los usuarios.

Actualmente se encuentra en una etapa de madurez el enfoque

Orientado a Objetos (OO) como paradigma del desarrollo de

sistemas de información. El Object Management Group (OMG) es un

consorcio a nivel internacional que integra a los principales

representantes de la industria de la tecnología de información

OO. El OMG tiene como objetivo central la promoción,

fortalecimiento e impulso de la industria OO. El OMG propone y

adopta por consenso especificaciones entorno a la tecnología

OO. Una de las especificaciones más importantes es la adopción en

1998 del Lenguaje de Modelado Unificado o UML (del inglés

Unified Modeling Language) como un estándar, que junto con el

Proceso Unificado están consolidando la tecnología OO.

Etapas del proceso

La ingeniería de software requiere llevar a cabo numerosas

tareas, dentro de etapas como las siguientes:

Análisis de requisitos

Extraer los requisitos de un producto de software es la primera

etapa para crearlo. Mientras que los clientes piensan que ellos

saben lo que el software tiene que hacer, se requiere de habilidad

y experiencia en la ingeniería de software para reconocer

requisitos incompletos, ambiguos o contradictorios. El resultado

del análisis de requisitos con el cliente se plasma en el documento

ERS, Especificación de Requisitos del Sistema, cuya estructura

puede venir definida por varios estándares, tales como CMM-I.

Asimismo, se define un diagrama de Entidad/Relación, en el que se

plasman las principales entidades que participarán en el

desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas

de ellos), es una parte crucial; de esta etapa depende en gran

medida el logro de los objetivos finales. Se han ideado modelos y

diversos procesos de trabajo para estos fines. Aunque aún no está

formalizada, ya se habla de la Ingeniería de Requisitos.

La IEEE Std. 830-1998 normaliza la creación de las

Especificaciones de Requisitos Software (Software Requirements

Specification).

Especificación

La Especificación de Requerimientos describe el comportamiento

esperado en el software una vez desarrollado. Gran parte del

éxito de un proyecto de software radicará en la identificación de

las necesidades del negocio (definidas por la alta dirección), así

como la interacción con los usuarios funcionales para la

recolección, clasificación, identificación, priorización y

especificación de los requerimientos del software.

Entre las técnicas utilizadas para la especificación de

requerimientos se encuentran:

Casos de Uso,

Historias de usuario,

Siendo los primeros más rigurosos y formales, los segundas más

ágiles e informales.

Arquitectura

La integración de infraestructura, desarrollo de aplicaciones,

bases de datos y herramientas gerenciales, requieren de capacidad

y liderazgo para poder ser conceptualizados y proyectados a

futuro, solucionando los problemas de hoy. El rol en el cual se

delegan todas estas actividades es el del Arquitecto. El

Arquitecto de Software es la persona que añade valor a los

procesos de negocios gracias a su valioso aporte de soluciones

tecnológicas. La Arquitectura de Sistemas en general, es una

actividad de planeación, ya sea a nivel de infraestructura de red y

hardware, o de Software. La Arquitectura de Software consiste

en el diseño de componentes de una aplicación (entidades del

negocio), generalmente utilizando patrones de arquitectura. El

diseño arquitectónico debe permitir visualizar la interacción entre

las entidades del negocio y además poder ser validado, por

ejemplo por medio de diagramas de secuencia. Un diseño

arquitectónico describe en general el cómo se construirá una

aplicación de software. Para ello se documenta utilizando

diagramas, por ejemplo:

Diagramas de clases

Diagramas de base de datos

Diagramas de despliegue plegados

Diagramas de secuencia multidireccional

Diagramas de infraestructura química

Siendo los dos primeros los mínimos necesarios para describir la

arquitectura de un proyecto que iniciará a ser codificado. Depende

del alcance del proyecto, complejidad y necesidades, el

arquitecto elige qué diagramas elaborar. Entre las herramientas

para diseñar arquitecturas de software se encuentran:

Enterprise Archit

Microsoft Visio for Enterprise Architects

Programación

Reducir un diseño a código puede ser la parte más obvia del

trabajo de ingeniería de software, pero no necesariamente es la

que demanda mayor trabajo y ni la más complicada. La complejidad

y la duración de esta etapa está íntimamente relacionada al o a los

lenguajes de programación utilizados, así como al diseño

previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente

las tareas indicadas en la especificación del problema. Una técnica

de prueba es probar por separado cada módulo del software, y

luego probarlo de forma integral, para así llegar al objetivo. Se

considera una buena práctica el que las pruebas sean efectuadas

por alguien distinto al desarrollador que la programó, idealmente

un área de pruebas; sin perjuicio de lo anterior el programador

debe hacer sus propias pruebas. En general hay dos grandes

formas de organizar un área de pruebas, la primera es que esté

compuesta por personal inexperto y que desconozca el tema de

pruebas, de esta forma se evalúa que la documentación entregada

sea de calidad, que los procesos descritos son tan claros que

cualquiera puede entenderlos y el software hace las cosas tal y

como están descritas. El segundo enfoque es tener un área de

pruebas conformada por programadores con experiencia,

personas que saben sin mayores indicaciones en qué condiciones

puede fallar una aplicación y que pueden poner atención en

detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo

del software y de la gestión del proyecto, pasando por

modelaciones (UML), diagramas, pruebas, manuales de usuario,

manuales técnicos, etc.; todo con el propósito de eventuales

correcciones, usabilidad, mantenimiento futuro y ampliaciones al

sistema.

5.3 Mantenimiento

Mantener y mejorar el software para enfrentar errores

descubiertos y nuevos requisitos. Esto puede llevar más tiempo

incluso que el desarrollo inicial del software. Alrededor de 2/3

de toda la ingeniería de software tiene que ver con dar

mantenimiento. Una pequeña parte de este trabajo consiste en

arreglar errores, o bugs. La mayor parte consiste en extender el

sistema para hacer nuevas cosas. De manera similar, alrededor de

2/3 de toda la ingeniería civil, arquitectura y trabajo de

construcción es dar mantenimiento.

MODULO 6: ADMINISTRACIÓN DEL PROYECTO

Es la planeación, organización, dirección y control de los

recursos para lograr un objetivo a corto plazo.

También se dice que la administración de proyectos ocurre cuando

se da un énfasis y una atención especial para conducir actividades

no repetitivas con el propósito de lograr un conjunto de metas.

Esta actividad es llevada a cabo por un conjunto de

administradores que actúan como agentes unificadores para

proyectos particulares, tomando en cuenta los recursos

existentes, tales como el tiempo, materiales, capital, recursos

humanos y tecnología.

6.1 Importancia De La Administración De Proyectos

La administración de proyectos implica una gran importancia, por

lo que es usada en una gran diversidad de campos; desde proyectos

espaciales, en bancos, en desarrollo de sistemas en computadora,

en procesamiento de hidrocarbono, en la industria petroquímica,

en telecomunicaciones, en defensa nacional, etc.

Los cambios tecnológicos, la necesidad de introducir nuevos

productos al mercado, las cambiantes exigencias de los

consumidores de productos, entre otras cosas, incrementan el

fluido de operaciones en una organización, provocando que los

métodos de administrativos convencionales sean inadecuados. Por

esta razón la administración de proyectos es importante, ya que

ofrece nuevas alternativas de organización.

Sirve para aprovechar de mejor manera los recursos críticos

cuando están limitados en cantidad y/o tiempo de disponibilidad.

También ayuda a realizar acciones concisas y efectivas para

obtener el máximo beneficio.

6.2 Funciones De La Administración De Proyectos

La administración procura siempre el máximo aprovechamiento de

los recursos, mediante su utilización eficiente. Las principales

funciones de la administración se engloban en planeación,

organización, dirección y control.

Durante la planeación se decide anticipadamente qué, quién, cómo,

cuándo y por qué se hará el proyecto. Las tareas más importantes

de la planeación son determinar el status actual de la

organización, pronosticar a futuro, determinar los recursos que

se necesitarán, revisar y ajustar el plan de acuerdo con los

resultados de control y coordinar durante todo el proceso de

planeación.

La organización realiza actividades en grupo, de asignación y

asesoramiento, y proporciona la autoridad necesaria para llevar a

cabo las actividades.

Dentro de esta etapa se identifica, define y divide el trabajo a

realizar, se agrupan y definen los puestos, se proporcionan los

recursos necesarios y se asignan los grados de autoridad.

El siguiente paso es la dirección, la cual sirve para conducir el

comportamiento humano hacia las metas establecidas.

Aquí se comunican y explican los objetivos a los subordinados, se

asignan estándares, se entrena y guía a los subordinados para

llegar a los estándares requeridos, se recompensa el rendimiento

y se mantiene un ambiente motivacional.

Por último se encuentra el control, que se encarga de medir el

rendimiento obtenido en relación a las metas fijadas. En caso de

haber desviaciones, se determinan las causas y se corrige lo que

sea necesario.

6.3 Que Es El Administrador De Proyectos

El administrador de proyectos puede ser definido como el individuo

que cumple con la tarea de integrar los esfuerzos dirigidos hacia

la ejecución exitosa de un proyecto específico. Esta persona

enfrenta un conjunto de circunstancias único en cada proyecto.

El administrador de proyectos es una extensión del administrador

general de una organización.

6.3.1 Funciones Del Administrador De Proyectos

El administrador de proyectos opera independientemente de la

cadena de mando normal dentro de la organización. Debe dirigir y

evaluar el proyecto; también planear, proponer e implementar

políticas de administración de proyectos, asegurar la finalización

del proyecto mediante compromisos contractuales.

Otras tareas que debe cumplir son desarrollar y mantener los

planes del proyecto, darle una calendarización y financiamiento

adecuados al proyecto y evaluar y reportar su avance.

Debe resolver los problemas a través de decisiones orientadas al

objetivo.

Además, el administrador de proyecto debe resolver las siguientes

preguntas:

* ¿Qué se va a hacer?

* ¿Cuándo se va a hacer?

* ¿Por qué se va a hacer?

* ¿Cuánto dinero está disponible para hacerlo?

* ¿Qué tan bien se está haciendo el proyecto?

MODULO 7: LAS METRICAS DEL PROYECTO

7.1 Métricas Del Software.

Cuando pueda medir lo que está diciendo y expresarlo con

números, ya conoce algo sobre ello; cuando no pueda medir,

cuando no pueda expresar lo que dice con números, su

conocimiento es precario y deficiente; puede ser el comienzo del

conocimiento, pero en tus pensamientos apenas estás avanzando

hacia el escenario de la ciencia.

Definiciones

Medida. Proporciona una indicación cuantitativa de extensión,

cantidad, dimensiones, capacidad y tamaño de algunos

atributos de un proceso o producto. Pueden ser directas, p.e.

número de líneas de código, número de errores encontrados,

etc., o pueden ser indirectas, p.e. funcionalidad, calidad,

complejidad, etc.

Medición. Acto de determinar una medida.

Métrica. Es una medida cuantitativa del grado en que un

sistema o proceso posee un atributo dado. Por lo general

relaciona una o más medidas, p.e. número de errores

encontrados por cada mil líneas de código.

Indicador. Es una métrica o combinación de métricas que

proporcionan una visión del proceso, del proyecto o del

software en sí, y poder hacer ajustes para que las cosas

mejoren.

7.1.1 Métricas Orientadas Al Tamaño.

Medidas

Líneas de código (LOC).

Esfuerzo en hombre-mes.

Costo en pesos o dólares.

Número de páginas de documentación.

Número de errores. Fallas detectadas antes de entregar el

software al cliente.

Número de defectos. Fallas detectadas después de entregar

el software al cliente.

Número de personas en el proyecto.

Métricas

Errores por KLOC (mil líneas de código).

Defectos por KLOC.

Costo por KLOC.

Páginas de documentación por KLOC.

Errores por hombre-mes.

LOC por hombre-mes.

Costo por página de documentación.

Ventajas

Son fáciles de calcular.

Muchos modelos de estimación de software usan LOC o

KLOC como datos de entrada.

Existen un amplio conjunto de datos y literatura basados en

LOC.

Desventajas

Son dependientes del lenguaje de programación.

Perjudica a los programas cortos pero bien diseñados.

Su uso en estimación es difícil porque hay que estimar las

LOC a producirse mucho antes de que se complete el análisis

y el diseño.

7.1.2 Métricas Orientadas A La Función.

La medida de punto de función se propuso en 1979 y trata de medir

la funcionalidad o utilidad del software.

Cálculo del punto de función

1. Hay que completar la siguiente tabla de valores del dominio

de la información:

Parámetro Cuenta

Factor de ponderación

Subtotal

Simple Medio Complejo

Número de

entradas

de usuario

3 4 6

Número de

salidas de

usuario

4 5 7

Número de

peticiones

de usuario

3 4 6

Número de

archivos

7 10 15

Número de

interfaces

5 7 10

Parámetro Cuenta

Factor de ponderación

Subtotal

Simple Medio Complejo

externas

Total

2. donde:

o Entradas de usuario. Son entradas que proporcionan

diferentes datos a la aplicación. No confundirlos con

las peticiones de usuario.

o Salidas de usuario. Son reportes, pantallas o mensajes

de error que proporcionan información. Los elementos

de un reporte, no se cuentan de forma separada.

o Peticiones de usuario. Es una entrada interactiva que

produce la generación de alguna respuesta del

software en forma de salida interactiva.

o Archivos. Son los archivos que pueden ser parte de una

base de datos o independientes.

o Interfaces externas. Son los archivos que se usan para

transmitir información a otro sistema.

Indicaciones:

o Contar cada medida por separado.

o Asociar, de alguna manera, un valor de complejidad a

cada medida. La siguiente tabla muestra una heurística

para decidir la complejidad de todo el sistema.

Tipos de

archivos

referenciados

Tipos de datos

elementales

1-5 6-19 20+

0-1 bajo bajo medio

Tipos de

archivos

referenciados

Tipos de datos

elementales

1-5 6-19 20+

2-3 bajo medio alto

4+ medio alto alto

o Para cada medida, multiplicar su cuenta por el factor

de complejidad elegido y escribirlo en la columna de la

extrema derecha.

o Sumar la columna de la extrema derecha y obtener un

total T que indica el valor del dominio de la

información.

3. Responder a cada una de las siguientes catorce preguntas y

asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es

incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es

esencial.

1. ¿Requiere el sistema copias de seguridad y de

recuperación fiables?

2. ¿Requiere comunicación de datos?

3. ¿Existen funciones de procesamiento distribuido?

4. ¿Es crítico el rendimiento?

5. ¿Se ejecutará el sistema en un entorno operativo

existente y fuertemente utilizado?

6. ¿Requiere entrada de datos interactiva?

7. ¿Requiere la entrada de datos interactiva que las

transacciones de entrada se lleven a cabo sobre

múltiples pantallas u operaciones?

8. ¿Se actualizan los archivos maestros de forma

interactiva?

9. ¿Son complejas las entradas, las salidas, los archivos

o las peticiones?

10. ¿Es complejo el procesamiento interno?

11. ¿Se ha diseñado el código para ser reutilizable?

12. ¿Están incluidas en el diseño la conversión y la

instalación?

13. ¿Se ha diseñado el sistema para soportar múltiples

instalaciones en diferentes organizaciones?

14. ¿Se ha diseñado la aplicación para facilitar los

cambios y para ser fácilmente utilizada por el usuario?

Sumar los puntos asignados a cada respuesta y obtener un

total F que indica un valor de ajuste de complejidad.

El punto de función FP se calcula con la siguiente ecuación:

PF = T * (0.65 + 0.01 * F).

Métricas

o Errores por PF.

o Defectos por PF.

o Costo por PF.

o Página de documentación por PF.

o PF por hombre-mes.

MODULO 8: ESTIMACIÓN DEL PROYECTO

8.1 Modelos De Estimación

La función básica que utilizan los tres modelos es:

E = a (Kl) b * m (X) donde:

A y b son constantes con valores definidos en cada submodelo

Kl son las líneas de código (en miles)

El resultado es en salarios/mes y horas-hombre.

M(X) Es un multiplicador que depende de 15 atributos.

En la siguiente tabla se muestran los coeficientes para los

diferentes modos 1.2 2.8 1.2 3.6 Empotrado 1.12 3.0 1.12 3.0

Semiencajado 1.05 3.2 1.05 2.4 Orgánico b i a i b i a i Modo

Intermedio Básico

Modelo Básico

Este modelo trata de estimar, de una manera rápida y más o menos

burda, la mayoría de proyectos pequeños y medianos. Se

consideran tres modos de desarrollo en este modelo: orgánico,

semiencajado y empotrado.

Modo orgánico

Se utilizan dos ecuaciones para determinar el esfuerzo de

personal y el tiempo de desarrollo. El coste es Km = 2.4 Sk1.05

donde Km se expresa en personas-mes y Sk es el tamaño expresado

en miles de líneas de código fuente. El tiempo de desarrollo se da

por td = 2.5 Km0.38 donde Km se obtiene de la ecuación anterior y

td es el tiempo de desarrollo en meses. Estas ecuaciones se han

obtenido por medio de ajustes de curvas realizado por Boehm en

TRW sobre 63 proyectos.

Modo Empotrado.

En este modo, el proyecto tiene unas fuertes restricciones, que

pueden estar relacionadas con el procesador y el interface

hardware. El problema a resolver es único y es difícil basarse en

la experiencia, puesto que puede no haberla. Las estimaciones de

tiempo y coste se basan en las mismas ecuaciones que en el modo

orgánico, pero con diferentes constantes. Así, el coste se da por

Km = 3.6 Sk1.20 y el tiempo de desarrollo por td = 2.5 Km0.32

Modo Semiencajado. Es un modo intermedio entre los dos

anteriores. Dependiendo del problema, el grupo puede incluir una

mezcla de personas experimentadas y no experimentadas.

Las ecuaciones son Km = 3.0 Sk1.12 y el tiempo de desarrollo

por td = 2.5 Km0.35.

Modelo Intermedio

En este modelo se introducen 15 atributos de coste para tener en

cuenta el entorno de trabajo. Estos atributos se utilizan para

ajustar el coste nominal del proyecto al entorno real,

incrementando la precisión de la estimación.

Ecuaciones nominales de coste.

Para cada modo de desarrollo, los 15 atributos del coste

intervienen como multiplicadores en el coste nominal, Kn, para

producir el coste ajustado.

Las ecuaciones nominales de coste para el modelo intermedio son

modo orgánico Kn = 3.2 Sk1.05

modo semiencajado Kn = 3.0 Sk1.12

modo empotrado Kn = 2.8 Sk1.20

Atributos de coste. Estos atributos tratan de capturar el impacto

del entorno del proyecto en el coste de desarrollo. De un

análisis estadístico de más de 100 factores que influencian el

coste, Boehm retuvo 15 de ellos para COCOMO.

Estos atributos se agrupan en cuatro categorías: atributos del

producto, atributos del ordenador, atributos del personal y

atributos del proyecto.

Atributos del producto

• RELY: garantía de funcionamiento requerida al software

• DATA: tamaño de la base de datos

• CPLX: complejidad del producto

Atributos del ordenador

• TIME: restricción de tiempo de ejecución

• STOR: restricción del almacenamiento principal

• VIRT: volatilidad de la máquina virtual

• TURN: tiempo de respuesta del ordenador

Atributos del personal

• ACAP: capacidad del analista

• AEXP: experiencia en la aplicación

• PCAP: capacidad del programador

• VEXP: experiencia en máquina virtual

• LEXP: experiencia en lenguaje de programación

Atributos del proyecto

• MODP: prácticas de programación modernas

• TOOL: utilización de herramientas software

• SCED: plan de desarrollo requerido.

Cada atributo se cuantifica para un entorno de proyecto. La

escala es muy bajo, bajo, nominal, alto, muy alto, extremadamente

alto. Estos 15 valores se multiplican al Kn, y nos proporciona el

esfuerzo ajustado al entorno.

Modelo Detallado Presenta principalmente dos mejoras respecto

al anterior: Los factores correspondientes a los atributos son

sensibles a la fase sobre la que se realizan las estimaciones,

puesto que aspectos tales como la experiencia en la aplicación,

utilización de herramientas de software, etc., tienen mayor

influencia en unas fases que en otras, y además porque van

variando de una etapa a otra. Establece una jerarquía de tres

niveles de productos, de forma que los aspectos que representan

gran variación a bajo nivel, se consideran a nivel módulo, los que

representan pocas variaciones, a nivel de subsistema; y los

restantes son considerados a nivel sistema.

8.2 TECNICAS DE DESCOMPOSICIÓN.

Estimación Basada En El Tamaño.

Puede usarse LOC o PF para hacer estimaciones.

Si se utiliza LOC, la descomposición es esencial y a menudo

debe ser a detalle.

Si se utiliza PF, en vez de centrar la descomposición en la

función, se calcula el PF como se estudió en el capítulo

anterior, estimando de alguna forma, cada uno de los

valores.

En ambos casos, mediante datos históricos o la intuición, se

estiman valores optimista (O), medio (M) y pesimista (P) para

cada función o contador, y se calcula el valor esperado (E)

con la siguiente fórmula:

E = (O + 4 * M + P) / 6

Ejemplo de estimación basada en LOC.

Supongamos que nos piden hacen un sistema que implemente las

principales operaciones con matrices, que tenga una interface

gráfica y un reporteador. El primer paso es analizar el problema y

descomponerlo en tareas que sean más fáciles de estimar. Digamos

que después de un estudio a fondo, nos damos cuenta que

necesitamos tres módulos o tareas específicas:

Interface gráfica.

Rutinas matemáticas para procesar matrices.

Reportes

Y digamos que en base a datos históricos, de sistemas que hayamos

realizado, obtenemos los siguientes estimados.

Módulo

LOC estimadas.

Optimista Medio Pesimista Esperado

Interface

gráfica

1,200 1,800 3,000 1,900

Rutinas

matemáticas

3,000 4,200 6,000 4,300

Reportes 600 1,200 1,800 1,200

Total 7,400

Si en base a los datos históricos sabemos que tenemos una

productividad media de 500 LOC/hombre-mes, podemos calcular

que el esfuerzo de desarrollar el sistema será de (7,400 / 500) =

15 hombres-mes (siempre hay que redondear hacia arriba). Y si cada

hombre-mes cuesta $10,000 (entre sueldos y gastos extras),

entonces el costo del sistema será de $150,000.

Ejemplo de estimación basada en PF.

Si queremos hacer una estimación del mismo sistema, pero usando

ahora PF, en vez de tratar de estimar las LOC que tendrá el

sistema, tratamos de estimar cada uno de los valores necesarios

para calcular el PF. Digamos que después del análisis, llegamos a

los siguientes valores:

Valores del dominio de información

Dominio de

información

Cuenta

Peso Subtotal

Optimista Medio Pesimista Esperado

Número de

entradas

7 8 10 8 4 32

Número de

salidas

4 5 7 5 5 25

Número de

peticiones

5 7 9 7 4 28

Número de

archivos

1 1 2 1 10 10

Número de

interfaces

externas

1 1 2 1 7 7

Total T 102

Factores

Factor Valor

Copia de seguridad y

recuperación

4

Factor Valor

Comunicaciones de datos 2

Proceso distribuido 0

Rendimiento crítico 4

Entorno operativo

existente

3

Entrada de datos en línea 4

Transacciones de entrada

en múltiples pantallas

5

Archivos maestros

actualizados en línea

2

Complejidad de valores

del dominio de

información

5

Complejidad del

procesamiento interno

5

Código diseñado para ser

rehusado

4

Conversión/instalación

en diseño

3

Instalaciones múltiples 5

Aplicación diseñada para 5

Factor Valor

el cambio

Total F 51

Aplicando la fórmula PF = T * (0.65 + 0.01 * F), se obtiene que PF =

118.

Si los datos históricos indican que nuestra productividad es de 7

PF / hombre-mes, entonces el esfuerzo requerido será de (118 / 7)

= 17 hombres-mes, y si el costo por hombre-mes es de $10,000,

entonces el costo del proyecto será de $170,000.

8.2.2 BASADO EN EL PROBLEMA.

Dicha estimación puede basarse en:

Datos históricos

Experiencia/intuición

Con estos valores se calcula un valor esperado.

VE = (Vo + 4Vm + Vp)/6

Una vez estimado el tamaño se aplican los datos históricos de

productividad LDC.

8.2.3 BASADO EN EL NÚMERO DE LÍNEAS DE (LDC) CÓDIGO.

La métrica de tamaño tradicional para estimar el esfuerzo de

desarrollo y productividad ha sido LOC (Lines Of Code) o SLOC

(Source Lines Of Code). Se han propuesto varios modelos de

estimación, la mayoría de ellos son funciones de las líneas de

código o de las miles de líneas de código que tendrá el software a

desarrollar. Generalmente, el modelo de estimación de esfuerzo

consiste de dos partes. La primera provee una base de estimación

como una función del tamaño del software, y es de la siguiente

forma:

donde E es el esfuerzo estimado en meses hombre, A, B y C son

constantes y KLOC es el tamaño estimado del sistema final en miles

de líneas de código. La segunda parte del modelo modifica esta

estimación en base a cuantificar la influencia de factores de

ambiente, por ejemplo la utilización de diferentes metodologías,

habilidad del equipo de desarrollo y restricciones de hardware.

La definición de KLOC es importante si se quiere comparar los

distintos modelos que se han propuesto en la literatura. Algunos

de ellos incluyen líneas de comentarios, y otros no. Del mismo

modo, la definición del esfuerzo estimado E es también importante.,

ya que E puede representar sólo el esfuerzo de codificación, o en

el otro extremo, el esfuerzo total del análisis, diseño,

codificación, test y mantención. Por estas razones, comparar

estos modelos se torna complejo.

Los principales problemas de utilizar líneas de código como

métrica para estimación del esfuerzo son la falta de una definición

universal de línea de código, su dependencia con el lenguaje de

desarrollo y la dificultad de estimar en fases tempranas del

desarrollo la cantidad de líneas que tendrá una aplicación.

Puntos de función

El análisis por puntos de función es un método para cuantificar el

tamaño y la complejidad de un sistema software en términos de las

funciones de usuario que este desarrolla (o desarrollará). Esto

hace que la medida sea independiente del lenguaje o herramienta

utilizada en el desarrollo del proyecto [1].

El análisis por puntos de función está diseñado para medir

aplicaciones de negocios; no es apropiado para otro tipo de

aplicaciones como aplicaciones técnicas o científicas. Esas

aplicaciones generalmente median con algoritmos complejos que

el método de puntos de función no está diseñado para manejar [5].

El enfoque de puntos de función tiene características que

permiten superar los principales problemas de utilizar líneas de

código como métrica del tamaño del software. Primero, los

puntos de función son independientes del lenguaje, herramientas o

metodologías utilizadas en la implementación; por ejemplo, no

tienen que considerar lenguajes de programación, sistemas de

administración de bases de datos, hardware, o cualquier otra

tecnología de procesamiento de datos [4]. Segundo, los puntos de

función pueden ser estimados a partir de la especificación de

requisitos o especificaciones de diseño, haciendo posible de este

modo la estimación del esfuerzo de desarrollo en etapas

tempranas del mismo. Como los puntos de función están

íntimamente relacionados con la declaración de requisitos,

cualquier modificación a ésta, puede ser reflejada sin mayor

dificultad en una re estimación.

Tercero, como los puntos de función están basados en una visión

externa del usuario del sistema, los usuarios no técnicos del

software poseen un mejor entendimiento de lo que los puntos de

función están midiendo. El método resuelve muchas de las

inconsistencias que aparecen cuando se utiliza líneas de código

como métrica del tamaño del software.

En resumen, los puntos de función aparecen con ventajas

substanciales por sobre las líneas de código, para fines de

estimación temprana del tamaño del software, y por ende, del

esfuerzo de desarrollo. Además es una medida ampliamente

utilizada, y con éxito, en muchas organizaciones que desarrollan

software en forma masiva.

Puntos de Característica.

Debido a que el análisis por Puntos de Función fue diseñado para

software de negocios y no es fácil de generalizar a aplicaciones

científicas, de tiempo real y otras, Caper Jones [18] propuso

ampliaciones a este método, generando una métrica que denominó

Puntos de Característica. Ésta da cabida a aplicaciones cuya

complejidad algorítmica es alta.

Este método considera los mismos elementos que considera

Albrecht [1] en su análisis por puntos de función, sólo que añade

la variable "número de algoritmos" y elimina los niveles de

complejidad, así, cada cuenta es pesada por un valor único para ese

componente (es decir, se le asigna complejidad media).

8.2.4 BASADO EN EL PROCESO

Métricas del proceso

� Indicadores del proceso

� mejora en el proceso

• Si la gestión se basa en el personal, problema y proceso, ¿por

qué nos centramos en mejorar el proceso?

• Por qué el proceso es un factor clave y controlable para

mejorar la calidad del software y el rendimiento de la

organización.

Métricas privadas:

– Índices de defectos.

– Errores de desarrollo.

• Públicas para el equipo:

– Índices de defectos.

– Errores de desarrollo.

– LDC.

– PF.

Las métricas del proceso pueden ser muy útiles, pero hay que saber

interpretarlas

• Unas normas básicas de interpretación son

- Utilizar el sentido común al interpretar los datos.

- Proporcionar una realimentación regular a particulares y

equipos.

- No utilizar métricas para evaluar a particulares.

- Establecer métricas claras y objetivos para alcanzarlas.

No utilizar métricas para amenazar a particulares o equipos.

- Si una métrica identifica un área problemática no se debería

considerar como negativa.

- Hay que interpretar todas las métricas en su conjunto, y no

primar una en particular.

La utilización de métricas e indicadores fiables da lugar a una

mejora estadística del proceso del software

• Esta mejora se basa en un análisis de fallos que identifica la

causa y origen de errores y defectos para varios proyectos de

software

- Error: fallo en un producto generado durante el proceso de IS

que es detectado antes de la entrega al cliente.

- Defecto: fallo detectado después de la entrega al cliente.

• El análisis de fallos funciona:

1. Se categorizan por origen todos los errores y defectos de

varios proyectos.

2. Se registra el coste de corregir cada error o defecto.

3. El número de errores y de defectos de cada categoría se

cuentan y se ordenan decrecientemente

4. Se computa el coste global de errores y defectos de cada

categoría.

5. Los datos resultantes se analizan para detectar las categorías

que producen el coste más alto para la organización.

6. Se desarrollan planes para modificar el proceso con el intento

de eliminar (o reducir la frecuencia de apariciones de) la clase de

errores y defectos que sean más costosos.