Antologia Ing.de Software
-
Upload
elvis-de-lal-cruz -
Category
Documents
-
view
124 -
download
0
Transcript of Antologia Ing.de Software
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 1/64
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 PERSONALES1.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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 2/64
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/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 3/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 4/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 5/64
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 losprototipos 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?
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 6/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 7/64
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 dealmacenamiento (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 delproblema. 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 8/64
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. Lascomputadoras 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 9/64
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 padecendaltonismo
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 usandopartes 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 10/64
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 ainternet.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 11/64
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 queno 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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 12/64
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 ?
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 13/64
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 deprocesos 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,
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 14/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 15/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 16/64
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 dediseñ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 querealmente 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. Elmantenimiento 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 lassituaciones. Entre los problemas que se presentan algunas veces
cuando se aplica este paradigma se encuentran:
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 17/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 18/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 19/64
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:
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 20/64
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 quetiene 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 mascompletas 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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 21/64
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 lareacció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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 22/64
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 laplanificació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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 23/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 24/64
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 herramientagenera 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 25/64
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 lassiguientes 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 26/64
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 únicoproyecto.
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 problemausada 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 27/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 28/64
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 dedesarrollo, 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 alsistema y al proceso de desarrollo (Ej. requisitos
legislativos, éticos, etc.)
Requisitos del dominio.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 29/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 30/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 31/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 32/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 33/64
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 unproducto 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 unsistema. Esto se debe poner en contraste con requisitos no
funcionales cuáles especifican características totales tales
como coste y confiabilidad.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 34/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 35/64
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:
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 36/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 37/64
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 esla 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].
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 38/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 39/64
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,
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 40/64
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 unaactividad 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 41/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 42/64
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 cuandose 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 43/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 44/64
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 haciala 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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 45/64
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 implementarpolí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?
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 46/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 47/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 48/64
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 CuentaFactor de ponderación
SubtotalSimple Medio Complejo
Número de
entradasde 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
archivos7 10 15
Número de
interfaces5 7 10
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 49/64
Parámetro CuentaFactor de ponderación
SubtotalSimple 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 50/64
Tipos de
archivos
referenciados
Tipos de datos
elementales
1-5 6-19 20+
2-3 bajo medio alto4+ 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?
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 51/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 52/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 53/64
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 delproducto, atributos del ordenador, atributos del personal y
atributos del proyecto.
Atributos del producto
• RELY: garantía de funcionamiento requerida al software
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 54/64
• 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, extremadamentealto. 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 55/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 56/64
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áfica1,200 1,800 3,000 1,900
Rutinas
matemáticas3,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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 57/64
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
entradas7 8 10 8 4 32
Número de
salidas 4 5 7 5 5 25
Número de
peticiones5 7 9 7 4 28
Número de
archivos1 1 2 1 10 10
Número deinterfaces
externas
1 1 2 1 7 7
Total T 102
Factores
Factor Valor
Copia de seguridad y
recuperación4
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 58/64
Factor Valor
Comunicaciones de datos 2
Proceso distribuido 0
Rendimiento crítico 4
Entorno operativo
existente3
Entrada de datos en línea 4
Transacciones de entradaen múltiples pantallas
5
Archivos maestros
actualizados en línea2
Complejidad de valores
del dominio de
información
5
Complejidad del
procesamiento interno5
Código diseñado para ser
rehusado4
Conversión/instalación
en diseño 3
Instalaciones múltiples 5
Aplicación diseñada para 5
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 59/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 60/64
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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 61/64
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 lasinconsistencias 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
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 62/64
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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 63/64
– 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 lacausa 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.
7/16/2019 Antologia Ing.de Software
http://slidepdf.com/reader/full/antologia-ingde-software 64/64
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.