Guia Ingenieria Del Software I

UNIVERSIDAD TECNOLGICA
SAN ANTONIO DE MACHALA

ESCUELA DE INFORMTICA
MODALIDAD DE EDUCACIN
SEMIPRESENCIAL Y A DISTANCIA
GUA DE ESTUDIO
INGENIERA DE SOFTWARE I
QUINTO SEMESTRE
ING. BERTHA MAZN

2009
EL ORO ECUADOR
TABLA DE CONTENIDO
Introduccin.
.
Informacin
general....
objetivos..
Sistema de contenidos.
..
Bibliografa
Problema,
.
objeto,
Estrategias
Metodolgicas.
Sistema
Evaluacin...
Actividades
de
..
UTSAM-Modalidad Semipresencial y a Distancia
11
de
13
Aprendizaje.....
14
INTRODUCCIN
Con la perseverancia se obtiene la fortaleza
y esto nos permite, no dejarnos llevar por lo fcil y lo cmodo.
Bertha Mazn
Querido estudiante.!
Empezar una nueva asignatura representa reafirmar el compromiso que al principio
te propusiste, y al igual que muchos que iniciaron esta modalidad, te encuentras entre
aquellos que lograron las metas inciales.
Estudiar una profesin como sistemas en modalidad semipresencial o a distancia no
es fcil, tus propsitos deben mantenerse firmes, debes levantarte al caer y gozar del
triunfo que acompaa al trabajo terminado.
Vamos a iniciar el estudio de INGENIERA DE SOFTWARE I, cuyo requisito es Bases
de Datos I y Programacin Visual I. En esta asignatura iniciamos con el aprendizaje y
el desarrollo de habilidades concernientes al desarrollo de un proyecto de software.
Ahora, con tus aprendizajes podrs desarrollar software para empresas y/u
organizaciones, logrando alcanzar el nivel que en nuestra Institucin exigimos a los
futuros ingenieros de sistemas.
El objetivo de esta asignatura es desarrollar software de calidad que resuelvan
problemas de todo tipo, aplicando mtodos, tcnicas y herramientas del proceso de
ingeniera de software como anlisis, diseo e implementacin y los conocimientos
adquiridos de programacin, sistemas operativos, bases de datos y redes de
computadoras, para lo cual dividiremos el contenido temtico en cuatro temas que
son:
TEMA I: INTRODUCCIN A LA INGENIERA DE SOFTWARE. Nos permitir
caracterizar los conceptos, elementos y procesos de la Ingeniera de Software.
TEMA II: INGENIERA DE REQUISITOS. Con este tema te preparars para realizar la
especificacin de los requisitos de software del problema planteado.
TEMA III: GESTIN DE PROYECTOS DE SOFTWARE. Aprenders a desarrollar la
gestin del proyecto de software mediante la elaboracin de la planificacin del
proyecto, el anlisis de riesgos, la configuracin del software y el control de calidad
que permita desarrollar un producto que satisfaga las necesidades del cliente.
TEMA IV: ANLISIS DEL SOFTWARE: Con este tema sers capaz de elaborar el
modelado del software segn el enfoque estructurado mediante el estudio y anlisis
de los requisitos del usuario.
As querido amigo, lograremos alcanzar el 90% de una de las principales habilidades
del ingeniero de sistemas, el desarrollo, por lo que te pido considerar las sugerencias
y sobretodo asistir con puntualidad a los encuentros programados.
En este curso utilizars herramientas como: Microsoft Project, Erwin y Visual CASE.
Recordemos la misin y visin de nuestra institucin en esta modalidad:
Misin
A travs de la modalidad semiprensencial y a distancia la Universidad tiene el
compromiso de formar profesionales e investigadores, competitivos, creativos y
humanistas, con capacidad de liderazgo, pensamiento crtico y reflexivo, capaces de
participar activamente en el fortalecimiento de las capacidad es productivas y de
servicio.
Visin
Brindar el acceso del sector a los procesos de educacin superior, generando una
nueva orientacin de su vinculacin con la comunidad local, regional y nacional,
demostrando la apertura de la Institucin de servir a la comunidad.
Recibe pues, un fuerte abrazo de bienvenida y los deseos ms sinceros de ayuda de

tal manera que pueda aportar con un granito de arena a tu formacin profesional.
Bienvenido.a estudiar Ingeniera de Software!!!!!!!!!!!
Bertha Mazn.
INFORMACIN GENERAL
DATOS GENERALES
Escuela
Especialidad
Asignatura
Nmero de crditos
Total Horas
:
:
:
:
:
INFORMTICA.
Ingeniera en Sistemas.
Ingeniera de Software I.
7
112 Hrs.
Docente
Telfono
E-mail
Las fechas de las jornadas presenciales confrmelas en su centro universitario,

Coordinacin de Educacin a distancia (UTSAM-EAD)
Le recomendamos que desde el momento en el que disponga del material
bibliogrfico inicie el desarrollo de las actividades propuestas en esta Gua de
estudio.
FUNDAMENTACIN DE LA ASIGNATURA
Cuando un software de computadora se desarrolla con xito, satisface las necesidades
de las personas que lo utilizan, funciona impecablemente durante mucho tiempo, es fcil
de modificar o incluso es ms fcil de utilizar, puede cambiar todas las cosas y de hecho
las cambia para mejorar. Para tener xito al disear y construir un software se necesita
disciplina. Es decir, se necesita un enfoque de ingeniera
La Ingeniera de software es un rea de informtica que ofrece mtodos y tcnicas para
desarrollar y mantener software de calidad que resuelve problemas de todo tipo. Hoy en
da es cada vez ms frecuente la consideracin de la Ingeniera de Software como una
nueva rea de la ingeniera y es una profesin implantada en el mundo laboral nacional e
internacional.
Es por esta razn que esta materia pasa hacer troncal o fundamental para los
estudiantes de la carrera de Ingeniera en Sistemas de la Escuela de Informtica de la
UTSAM, la misma que permitir desarrollar habilidades y destrezas en el anlisis, diseo
e implementacin de software resolviendo todo tipo de problema.
PROBLEMA, OBJETO, OBJETIVO

PROBLEMA
La necesidad de aplicar los procesos de ingeniera de software para el desarrollo de

soluciones informticas de calidad que resuelvan problemas de todo tipo en
empresas e instituciones
OBJETO
El proceso de ingeniera de software
OBJETIVOS
INSTRUCTIVO
Al terminar el estudio de la asignatura el estudiante estar en capacidad de:
Desarrollar software de calidad que resuelvan problemas reales de organizaciones,

aplicando mtodos, tcnicas y herramientas del proceso de ingeniera de software
como anlisis, diseo e implementacin para la obtencin de un sistema informtico
de calidad y la satisfaccin del usuario.
EDUCATIVO
Fomentar en los estudiantes la prctica de valores como la responsabilidad,

honestidad, criticidad, equidad y compaerismo, en el desarrollo de sistemas
informticos para empresas e instituciones considerando su realidad socioeconmica y los avances tecnolgicos.
COMPETENCIA
Desarrollo de software de calidad considerando mtodos, tcnicas y herramientas del

proceso de ingeniera de software como anlisis, diseo e implementacin, con actitud
profesional y mentalidad positiva.
SISTEMA DE CONTENIDOS
TEMA I:
OBJETIVO:
COMPETENCIA:
DURACIN:
INTRODUCCIN A LA INGENIERA DE SOFTWARE (ISW)

Conceptualizar terminologa y modelos de Ingeniera de Software.
Conceptualiza terminologa y describe modelos de la ISW .
(16 horas)
SISTEMA DE
SISTEMA DE CONOCIMIENTOS
SISTEMA DE HABILIDADES
VALORES
Conceptos:
software, Conceptualizar
Responsabilidad
ingeniera
de
software,
terminologa referente a la
Criticidad
producto, proceso, mtodo,
ingeniera del software.
Honestidad
tcnica,
metodologa, Caracterizar los
Compaerismo
herramienta,
paradigma
modelos (paradigmas o ciclos
(modelo o ciclo de vida).
de vida) de desarrollo del
Actividades genricas
software.
de la ingeniera de software
Diferenciar el
Modelos
de
la
producto y el proceso
ingeniera del software
Describir la evolucin
Evolucin
de
la
de la ingeniera del software y
ingeniera de software
la crisis del software
Crisis del software
Describir las
Principales
principales organizaciones de
organizaciones
de
estandarizacin y los
estandarizacin de la ingeniera
estndares que se promueven
del software
Principales estndares
de la ingeniera del software.
TEMA II:
OBJETIVO:
INGENIERA DE REQUISITOS
Realizar la especificacin de los requisitos de software del problema
planteado.
COMPETENCIA:
Redacta documentos de especificacin del software.
DURACIN:
(32 horas)
SISTEMA DE
SISTEMA DE
HABILIDADES
VALORES
Conceptos
de
Ingeniera
de Identificar
y Responsabilidad
Requisitos
recolectar requisitos
Criticidad
Descripcin de las actividades del Validar y
Honestidad
proceso de la IR
gestionar requisitos
Obtencin de requisitos
Elaborar
los
Anlisis de requisitos
requisitos del software
Especificacin de Requisitos
segn el estndar de IEEE 830
Validacin de requisitos
Gestin de requisitos
TEMA III:
GESTIN DE PROYECTOS DE SOFTWARE
OBJETIVO: Gestionar el proyecto de software mediante planificacin, seguimiento y
control del proceso de desarrollo de software y la realizacin de actividades
de soporte como: anlisis de riesgos, configuracin del software y control
de calidad que permita la construccin de un producto que satisfaga las
necesidades del cliente.
COMPETENCIA:
Gestiona proyectos de software. DURACIN:
(48 horas)
SISTEMA DE
SISTEMA DE
HABILIDADES
VALORES
CONCEPTOS SOBRE GESTIN DE
Gestionar el
Responsabilidad
PROYECTOS DE SOFTWARE
personal, el proceso y el Compaerismo
El espectro de gestin, el
problema durante el
Honestidad
personal, el producto, el proceso, el
proyecto de software
proyecto
PLANIFICACIN DEL PROYECTO DE
Identificar y
Responsabilidad
SOFTWARE
generar equipos de
Compaerismo
Objetivos de la planificacin
software, estimaciones
Honestidad
del proyecto
fiables del esfuerzo,
mbito del software, recursos
costes y duracin del
Estimacin del proyecto de
proyecto
software
o
Tcnicas de puntos de
funcin
o
Modelos empricos de
estimacin
La decisin desarrollarcomprar
PLANIFICACIN TEMPORAL Y
Desarrollar la
Responsabilidad
SEGUIMIENTO DEL PROYECTO
planificacin temporal de Compaerismo
Conceptos bsicos, la relacin
proyecto
Honestidad
entre las personas y el esfuerzo
Definicin de un conjunto de
tareas para el proyecto de software.
Seleccin de las tareas de Ing.
SW
Refinamiento de las tareas
principales
Definir una red de tareas
ANLISIS DE RIEGOS
Identificar y
Responsabilidad
Estrategias de riesgos
utilizar las tcnicas para
Compaerismo
Riesgos del software
la evaluacin de los
Honestidad
Identificacin y proyeccin del
riesgos que pueden
riesgo
tener impacto en el xito
Reduccin, supervisin y
gestin del riesgo
Riesgos y peligros para la
seguridad
PLAN DE GARANTA DE CALIDAD
Introduccin
Documentacin
Revisiones y auditorias
Gestin de Configuracin
PLAN DE GESTIN DE
CONFIGURACIN
Introduccin
Actividades de GCS
Programacin
del proyecto.
Definir y
controlar la calidad de un
proyecto
Responsabilidad
Compaerismo
Honestidad
Identificar y
realizar la forma de
gestionar los cambios
durante el desarrollo de
software y despus de
entregar al cliente
Responsabilidad
Compaerismo
Honestidad
TEMA IV:
OBJETIVO:
MODELADO DE ANLISIS DEL SOFTWARE

Elaborar el modelado del software mediante el estudio y anlisis de
los requisitos del software, las metodologas de anlisis y la
elaboracin del prototipo que permita la obtencin de modelos fsicos
y lgicos para el diseo del software.
COMPETENCIA:
Crea modelos conceptuales del software.
DURACIN:
(16 horas)
SISTEMA DE
VALORES
INTRODUCCIN AL MODELADO
Comprender la
Responsabilidad
Conceptos de modelado,
importancia del modelado
Criticidad
utilidad, abstraccin, ventajas
de software
Honestidad
Compaerismo
ANLISIS ESTRUCTURADO
Obtener una
Responsabilidad
Breve historia,
representacin general del Criticidad
caractersticas
software a construir a partir Honestidad
Elementos del modelo del
de la especificacin de los
Compaerismo
anlisis
requisitos.
Modelado funcional o de
procesos y flujo de
informacin(DFDs), su notacin y
diccionario de datos
Modelado de datos (ER) y
su diccionario de datos
HERRAMIENTAS CASE (TI)
Identificar los tipos Responsabilidad
Que es CASE
de CASE
Criticidad
Objetivos de las CASE
Utilizar las
Honestidad
Elementos de las CASE
herramientas CASE apara
Compaerismo
Tipos de CASE
el desarrollo del software
Ejemplos de CASE
10
BIBLIOGRAFA
TEXTO BSICO:
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. McGraw-Hill/Interamerica de Espaa S.A.U. 2005
BIBLIOGRAFA COMPLEMENTARIA:
Kendall & Kendall, Anlisis y Diseo de software

Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Quinta Edicin.
Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2002
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Cuarta Edicin.
Mc-Graw-Hill/Interamerica de Espaa S.A.U. 1998
Sommerville, I., "Software Engineering. 6th edition". Addison Wesley. 2000
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements
Specifications: IEEE, 1998.
Jacobson, I., Booch, G. y Rumbaugh, J., "El proceso unificado de modelado",
Addison Wesley, 2000.
Rolland C. Praskash, N. From conceptual modeling to requirement engineering,
Annals of software engineering 10 (2000) 151-176
Amador Durn Toro, Beatriz Bernrdez Jimnez, Metodologa para el anlisis de
Requisitos de Sistemas Software. Versin 2.1 Informe Tcnico. Departamento de
Lenguajes y Sistemas Informticos Facultad de Informtica y Estadstica Sevilla,
2001
S. L. Pfleeger, "Software Engineering: Theory and Practice," Second ed: PrenticeHall, 2001.
Palacios, Juan. Compendio de Ingeniera de SW I. ltima revisin: Junio 2006.
Documento Electrnico: CIS I 04.PPT.
REVISTAS TCNICAS
Revista PC WORLD
Revista PC MAGAZINE (Ingles, Espaol)
URLs:
"SWEBOK, Software Engineering Body of Knowledge". 2004. www.swebok.org
Rational. http://www.rational.com
Navegapolis.net. http://www.navegapolis.net
Vico.org. http://www.vico.org
http://www.uag.mx/66/contenido.htm
http://www.inf.udec.cl/~ingsoft/transparenciasmvc.html
http://148.202.148.5/cursos/cc321/fundamentos/unidad6/tema6_4.html
11
Con toda esta referencia bibliogrfica t puedes ampliar tus conocimientos acerca de la
temtica propuesta.
12
ESTRATEGIAS METODOLGICAS
Para el desarrollo de las actividades propuestas se recomienda lo siguiente:

1. Tener una actitud positiva, voluntad, motivacin e inters.
2. Lee reflexivamente la bibliografa bsica, en ella se encuentran todos los temas de las
actividades planteadas.
3. Para aprender cualquier asignatura se necesita tener una fuente de consulta a mano, por
lo tanto se recomienda leer, como mnimo, los textos bsicos o guas expuestos en la
bibliografa y reforzar con algunos textos complementarios.
4. Cuando hayas hecho esta primera lectura comprensiva, procede a desarrollar las
actividades poniendo en prctica tu actitud crtica y reflexiva, tu capacidad de sntesis y tu
creatividad.
5. Para estudiar debes elegir siempre un lugar tranquilo, cmodo con buena iluminacin, y
tener sobre la mesa la bibliografa bsica, diccionario, papel. Esfero, etc.
6. Planifica el tiempo dedicado al sueo y a las comidas, casi todos necesitamos de 8 horas
de sueo.
7. Dedica una hora por la maana que se distribuye para: gimnasia matinal, aseo personal,
vestirse desayunar.
8. Toma en cuenta las horas que son dedicadas a tu trabajo u ocupacin personal. Lo
importante es saber determinar el tiempo que necesitas para tus estudios.
9. Es importante que en todo este proceso cultives el valor de la constancia porque no sirve
de nada tener una excelente planificacin y un horario si no eres constante.
10. Utiliza fichas de trabajo o algn cuaderno de resmenes.
11. Si algn tema o problema no est claro, no dudes en llamar o ponerte en contacto con tu
profesor gua a fin de solucionar las inquietudes. Favor no quedarse con stas porque
irn formando lagunas en su aprendizaje que luego son difciles de corregir.
12. Para los encuentros con el profesor gua revisa la ltima tarea realizada y a continuacin
lee detenidamente las instrucciones dadas en la gua de estudios, analiza y sintetiza los
temas y conceptos, realiza las tareas propuestas.
Para el desarrollo de asignatura se sugiere lo siguiente:
Un cuaderno de apuntes, y un computador Pentium IV, 160 GB de disco duro y
memoria RAM de mnimo 512MB
Instaladores de EasyEclipse Desktop Java 1.2.2., Microsoft Office, Mysql, Sqlyog
Enterprise, herramientas de anlisis y diseo de SW (CASE): Visual Case, Erwin,
Micrososft Project.
Todos tus trabajos debes entregarlos en CD.
Lee reflexivamente el texto gua, ah constan todos los temas a los que corresponden
las actividades planteadas.
Cuando hayas realizado sta lectura comprensiva, procede a desarrollar las
actividades. No hagas una copia textual, sino contesta con tus propias palabras.
13
Para realizar las actividades, adems de la lectura puedes ayudarte con la tcnica del
subrayado, mapas conceptuales, cuadros sinpticos, etc.
Presente el trabajo desarrollado en computadora con el formato siguiente.
o Papel INEN A4, utilice sangra, mrgenes, ortografa
o Margen Superior
:
3 cm
o Margen Inferior
:
2.5 cm.
o Margen Izquierdo
:
3.5 cm.
o Margen Derecho
:
2.5 cm.
Incorporamos en esta gua los siguientes grficos para un mejor desarrollo
Orientaciones de Tarea
Las especificaciones para los trabajos a desarrollar como
parte del proceso de aprendizaje
Resumen:
Sintesis de los temas desarrollados
Nota importante:
Aspectos a los que debes poner atencin y que considero
clave para el desarrollo de la asignatura.
Recuerde
EL TRABAJO ES PERSONAL, NO SE ACEPTARAN

COPIAS NI TRABAJOS IGUALES!
14
SISTEMA DE EVALUACIN
La evaluacin ser continua durante el desarrollo de las temticas programadas y se la
realizar con base en los siguientes criterios:
Aplicacin de conocimientos tericos, capacidad de anlisis y sntesis

Creatividad en la resolucin de problemas
Capacidad para seleccionar las opciones u alternativas ms adecuadas en la
resolucin de problemas
Originalidad y cientificidad, calidad de presentacin de los trabajos (limpieza, orden
etc.)
Puntualidad
De acuerdo al sistema de crditos de la UTSAM:

Trabajos de encuentros presenciales (TE)
Trabajos de la gua de estudios(TG)
Evaluacin (E)
Nota final del crdito: Suma (TE, TG, E)
10%
10 %
30%
50%
Trabajos de encuentros presenciales: Defensa de trabajos de investigacin, desarrollo de

ejercicios en clase, talleres, debates, Exposiciones de consultas, otros
Trabajos de la gua de estudios: consultas, desarrollo de ejercicios, resmenes,
autoevaluaciones, otros
El promedio de todos los crditos (PC) corresponder al 50% de la nota final
El estudiante deber desarrollar un PROYECTO FINAL (PF) que integre las temticas
tratadas en la asignatura y se evaluar sobre el 50%.
La nota final se obtiene sumando el promedio de los crditos y la nota del examen
(PC+PF)
Reflexiona:
Slo el estudio libera al

hombre de las ataduras de su
ignorancia!
15
16
INTRODUCCIN A LA
INGENIERA DE SOFTWARE (ISW)
-
Conceptos:
software,
ingeniera
de
software,
producto, proceso, mtodo,
tcnica,
metodologa,
herramienta,
paradigma
(modelo o ciclo de vida).
Actividades genricas
de la ingeniera de software
Modelos
de
la
ingeniera del software
Evolucin
de
la
ingeniera de software
Crisis del software
Principales
organizaciones
de
estandarizacin de la ingeniera
del software
Principales estndares
de la ingeniera del software.
-
Conceptualizar
terminologa referente a la
ingeniera del software.
Caracterizar los
modelos (paradigmas o ciclos
de vida) de desarrollo del
software.
Diferenciar el
producto y el proceso
Describir la evolucin
de la ingeniera del software y
la crisis del software
Describir las
principales organizaciones de
estandarizacin y los
estndares que se promueven
SISTEMA DE
VALORES
Responsabilidad
Criticidad
Honestidad
Compaerismo
TIEMPO ESTIMADO DE ESTUDIO

Horas presenciales:
Horas de investigacin:
Total horas mnimas requeridas del tema:
Horas de actividades laborales:
Total de Horas de estudio del tema:
8
8
16
8
24
INTRODUCCIN
INTRODUCCIN
En la actualidad, el software de computador es la tecnologa ms importante en el mbito
mundial, las economas de los pases desarrollados dependen en gran parte del software,
20
ms y ms sistemas son actualmente controlados por software. El software es el producto

que los ingenieros de software construyen y despus mantienen en el largo plazo. Incluye los
programas que se ejecutan dentro de una computadora de cualquier tamao y arquitectura.
La Ingeniera de Software concierne a teoras, mtodos y herramientas para el desarrollo
profesional de software.
OBJETIVO
Conceptualizar terminologa y modelos de Ingeniera de Software.
ESQUEMA
ESQUEMADEL
DELTEMA
TEMAI I
21
ACTIVIDADES
ACTIVIDADESDE
DEAPRENDIZAJE
APRENDIZAJETEMA
TEMAI I
Para el estudio del Tema I necesitas revisar la siguiente bibliografa:
Roger S. Pressman. Ingeniera del Software un Enfoque Practico.

Sexta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005.
Captulos: 1, 2, 3, 4; Pginas:1-99.
Quinta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005.
Captulos: 1 y 2; Pginas: 3-33.
Palacios, Juan. Compendio de Ingeniera de SW I. ltima revisin:
Junio 2006. Documento Electrnico: CIS I 04.PPT. Captulos 1 y 2,
Diapositivas: 1- 53.
1.
CONCEPTOS DE INGENIERA DE SOFTWARE
En este tema se realiza una introduccin a la Ingeniera del software. Se revisan conceptos
como: software, ingeniera de software, producto, proceso, actividad, tarea, paradigma,
metodologa, tcnica, herramientas, estndares, entre otros.
Principales conceptos a tener en cuenta en la ingeniera de software
Proceso a seguir para resolver una situacin o
Proceso a seguir para resolver una situacin o
problema con un orden y objetivos establecidos.
Mtodo
problema con un orden y objetivos establecidos.
Mtodo
Proceso {actividades} {tareas}
Proceso {actividades} {tareas}
Tcnica
Tcnica
Estrategia para desarrollar una actividad de un

Estrategia para desarrollar una actividad de un
mtodo
mtodo
Metodologa
Metodologa
Mtodo + tcnicas + soporte documental

Mtodo + tcnicas + soporte documental
Herramienta
Herramienta
Soporte automatizado, Ejm. CASE, CARE

Soporte automatizado, Ejm. CASE, CARE
Producto
Producto
Resultado de cada etapa o actividad, denominado

Resultado de cada etapa o actividad, denominado
tambin entregable
tambin entregable
El software se ha convertido en el elemento clave de la evolucin de los sistemas y

productos informticos. El software considerado como el producto se compone de
22
programas, datos y documentos. Cada uno de estos elementos componen una configuracin
que se crea como parte del proceso de la ingeniera del software.
Qu es la ingeniera de software? Hay diferentes autores que conceptualizan la
ingeniera de software desde sus propias perspectivas, sin embargo todos guardan relacin.
A continuacin se presentan algunos conceptos de diferentes autores:
Por ejemplo la definicin que propuso Fritz Bauer en una conferencia mundial en 1968: La
ingeniera de software es el establecimiento y uso de principios de la ingeniera para obtener
econmicamente un software confiable y que funcione eficiente en mquinas reales
Ingeniera del Software es la aplicacin practica del conocimiento cientfico en el diseo y
construccin de programas de computadora y la documentacin necesaria requerida para
desarrollar, operar (funcionar) y mantenerlos (Bohem, 1976).
Disciplina para producir software de calidad desarrollado sobre las agendas y costes
previstos y satisfaciendo los requisitos (S. Schach 1990, Software Engineering).
Ingeniera al software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable
al desarrollo, operacin (funcionamiento) y mantenimiento del software (IEEE, 1993).
La ingeniera de software es una disciplina que integra al proceso, los mtodos y las
herramientas para el desarrollo del software de computadora. Se ha propuesto un gran
nmero de modelos para la ingeniera de software, pero todos definen un conjunto de
actividades del marco de trabajo, una coleccin de tareas conducidas para realizar cada
actividad, productos de trabajo generados como consecuencia de las tareas y un conjunto de
actividades de soporte que acompaan el proceso entero.
Un objetivo de dcadas ha sido el encontrar procesos o metodologas predecibles y
repetibles que mejoren la productividad y la calidad. Los modelos prescriptitos (paradigmas
o ciclos de vida) del proceso de software se han aplicado durante muchos aos en un
esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada uno de estos
modelos convencionales sugiere un flujo de proceso o ciclo de vida que de alguna forma es
diferente, pero todos realizan un conjunto de actividades genricas del marco de trabajo:
comunicacin, planeacin, modelado, construccin y despliegue.
2. ACTIVIDADES GENRICAS DE LA INGENIERA DE SOFTWARE
Comunicacin
Esta actividad del marco de trabajo implica una intensa colaboracin y comunicacin con los
clientes; adems abarca la investigacin de requisitos y otras actividades relacionadas.
Planeacin
Esta actividad establece un plan para el trabajo de la ingeniera del software. Describe las
tareas tcnicas que deben realizarse, los riesgos probables, los recursos que sern
requeridos, los productos del trabajo que han de producirse y un programa de trabajo.
Modelado
Esta actividad abarca la creacin de modelos que permiten al desarrollador y al cliente
entender mejor los requisitos del software y el diseo que lograr satisfacerlos.
23
Construccin
Esta actividad combina la generacin del cdigo y la realizacin de pruebas necesarias para
descubrir errores en el cdigo.
Despliegue
El software (como una entidad completa o un incremento completado de manera parcial) se
entrega al cliente, quin evala el producto recibido y proporciona informacin basada en su
evaluacin.
Segn el estndar ISO 12207, los procesos de la ingeniera de software se organizan en:
proceso primario (Actividades: adquisicin, suministro, desarrollo, operacin y
mantenimiento), proceso de soporte (Actividades: documentacin, gestin de la
configuracin, control de calidad, verificacin, validacin, reuniones, auditora, resolucin de
problemas) y proceso organizacional (Actividades: gestin, infraestructura, mejora y
formacin). Tambin, se identifican como actividades genricas del la ingeniera del software
a las siguientes:
Anlisis
Anlisis
Implementaci
Implementaci
n
n
Gestin
Gestin
del
del
Proyect
Proyect
o
o
Pruebas
Pruebas
Planeaci
Planeaci
nn
Desarroll
Desarroll
o
o
3. MODELOS (PARADIGMAS O CICLOS DE VIDA) DE LA INGENIERA DEL SOFTWARE
La ingeniera de software tiene varios modelos considerados tambin paradigmas o ciclos de

vida de desarrollo en los cuales se puede apoyar para la realizacin de software, de los
cuales podemos destacar algunos por ser los ms utilizados y los ms completos: el modelo
de cascada o ciclo de vida clsico, los modelos incrementales, el DRA (Desarrollo Rpido de
Apicaciones), los procesos evolutivos como la construccin de prototipos y el espiral, el
modelo basado en componentes, los mtodos formales (CMM, CMMI), el orientado a
aspectos, el proceso unificado UML, los mtodos giles.
4. EVOLUCIN DE LA INGENIERA DE SOFTWARE
La ingeniera de software es una disciplina muy joven, a finales de la dcada de los 60

comenzaron a establecer algunos principios bsicos, sin embargo se ha producido una
preocupante crisis del software de la cual an no se logra salir. A continuacin se presenta
una breve evolucin:
24
(< 1968)
Dominios sencillos
El software era diseado a medida
Carencia de mtodos sistemticos
La programacin del software se consideraba como un arte.
(1968)
Fritz Bauer, utiliza por primera vez el trmino Ingeniera del Software, en la 1era.
Conferencia sobre desarrollo de software patrocinada por el Comit de Ciencia de la
OTAN celebrada en Garmisch, Alemania.
(>1968)
Dominios complejos
Aplicaciones variadas y complejas
Separacin desarrollador cliente
Exigencias de calidad
Desarrollo en grupos
Crisis del software
Se evidencia una preocupacin de las universidades y organismos de
estandarizacin (SEI, IEEE, ISO) por el desarrollo de estndares, metodologas,
tcnicas y herramientas para la ingeniera de software.
5. CRISIS DEL SOFTWARE
El trmino crisis del software se acu en 1968, en la primera conferencia organizada por
la OTAN sobre desarrollo de software.
La crisis del software es el hecho de que el software que se construye no solamente no
satisface los requerimientos ni las necesidades pedidos por el cliente, sino que adems
excede los presupuestos y los horarios de tiempos. La industria del software no ha podido
satisfacer la demanda. La complejidad del software producido y demandado se incrementa
constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y
est presente en todos los sistemas que van desde los ms sencillos hasta los de misin
crtica. Las aplicaciones de software son complejas porque modelan la complejidad del
mundo real. En estos das, las aplicaciones tpicas son muy grandes y complejas para que
un individuo las entienda y, por ello, lleva gran tiempo implementar software.
A continuacin se citan algunas causas de la crisis del software:
Imprecisin en la planificacin del proyecto y estimacin de los costos.
Baja calidad del software.
Dificultad de mantenimiento de programas con un diseo poco estructurado, etc.
Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en
la compra.
Tambin se requiere una serie de caractersticas como fiabilidad, facilidad de
mantenimiento y de uso, eficiencia, etc
25
Comparativa de proyectos para el desarrollo de sistemas de software

Fracaso
2004
2000
1998
19%
53%
23%
xito
29%
49%
28%
28%
46%
40%
1995
1994
Problemtico
26%
33%
31%
27%
53%
16%
Proyecto no terminado, nunca se llega a utilizar

Desbordamiento de agendas o costes. Las funcionalidades no cubren las
expectativas. Problemas funcionales
Proyecto realizado en el tiempo previsto, con los costes previstos, con la
funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey
(http://www.standishgroup.com/)
6. PRINCIPALES ORGANIZACIONES DE ESTANDARIZACIN DE LA INGENIERA DE

SOFTWARE
Desde la identificacin del fenmeno crisis del software, han sido muchas las
organizaciones que han abordado, con mayor o menor rigor, el anlisis de problemas en el
desarrollo de sistemas de software. Sus trabajos se han encaminado a la localizacin de las
causas; y a la exposicin en textos didcticos, normativos o estndares de procesos o
prcticas necesarias para abordar el desarrollo, mantenimiento y operacin con las mayores
garantas de xito.
Han sido muchos los departamentos de universidades, organismos de normalizacin o
investigacin nacionales o internacionales, sociedades de profesionales, departamentos de
defensa, departamentos de calidad y procesos de empresas los que han ido generando
normas y estndares.
Se considera como entidades de mayor reconocimiento internacional, por sus trabajos y
esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a:
ISO, SEI e IEEE- Computer Society.
ISO. Organizacin Internacional para la Estandarizacin, fundada en 1947.
Son miembros 87 pases. En 1987 la Organizacin
Internacional para la Estandarizacin (ISO) y la Comisin
26
Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las

Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de los
sistemas de tecnologas de la informacin, incluyendo microprocesadores y equipos.
Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software:
ISO/IEC 12207
ISO/IEC TR 15504
SEI. Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/). Integrado en la
Universidad Carnegie Mellon.
La aportacin ms significativa de este Instituto son
los modelos de madurez de las capacidades: CMM
y CMMI; que en sus casi 15 aos de implantacin
efectiva en entornos de produccin de software han
demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para
mejora de procesos, y como criterio de evaluacin para determinar la madurez, y por tanto
fiabilidad de resultados previsibles de una organizacin de software.
IEEE Computer Society
IEEE Es el Instituto de Ingenieros en Electricidad y Electrnica (Institute of Electrical and
Electronics Engineers).
Su misin es preservar, investigar y promover la informacin de las
tecnologas elctricas y electrnicas.
Surgi en 1963 con la fusin del AIEE (Instituto Americano de
Ingenieros Elctricos) y el Instituto de Ingenieros de Radio (IRE).
La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada
en la actualidad por ms de 100.000 miembros en todo el mundo.
Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la
informacin. Realiza conferencias, publicaciones, cursos de formacin, y desarrolla
estndares.
IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software. Algunos
de ellos, correspondientes a las principales reas especficas de la Ingeniera del Software
son:
IEEE Std. 830 Prcticas recomendadas para las especificaciones de software.
IEEE Std. 1362 Gua para la especificacin del documento de requisitos ConOps
IEEE Std. 1063 Estndar para la documentacin de usuario de software.
IEEE Std. 1012 Estndar para la verificacin y validacin de software.
IEEE Std. 1219 Estndar para el mantenimiento del software
27
7. PRINCIPALES ESTNDARES Y MODELOS DE LA INGENIERA DE SOFTWARE

La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse
Definirse aa s
s misma:
misma: Cules
Cules son
son las
las reas
reas de
de conocimiento
conocimiento que
que la
la comprenden?
comprenden?
SWEBOK: Software Engineering Body of knowledge
http://www.swebok.org
Definir
Definir los
los procesos
procesos que
que intervienen
intervienen en
en el
el desarrollo,
desarrollo, mantenimiento
mantenimiento yy operacin
operacin del
del
software
software
ISO/IEC 12207: Procesos del ciclo de vida del software
De
De las
las mejores
mejores prcticas,
prcticas, extraer
extraer modelos
modelos de
de cmo
cmo ejecutar
ejecutar esos
esos procesos
procesos para
para evitar
evitar los
los
problemas
problemas de
de la
la crisis
crisis del
del software
software
CMM / CMMI
ISO/IEC TR 15504
Definir
Definir estndares
estndares menores
menores para
para dibujar
dibujar criterios
criterios unificadores
unificadores en
en requisitos,
requisitos, pruebas,
pruebas,
gestin
gestin de
de la
la configuracin,
configuracin, etc.
etc.
IEEE 830 - IEEE 1362 - ISO/IEC 14764
Los estndares son tiles porque:

Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de
software.
Engloban los conocimientos.
Proporcionan un marco para implementar procedimientos de aseguramiento de la
calidad.
Proporcionan continuidad y entendimiento entre el trabajo de personas y
organizaciones distintas.
28
TAREAS
TAREASDEL
DELCRDITO
CRDITO11
Realice las siguientes actividades para fortalecer el aprendizaje del tema:
Realice las siguientes actividades para fortalecer el aprendizaje del tema:
Investigue los conceptos de los siguientes trminos:

Investigue los conceptos de los siguientes trminos:
Ingeniera
Ingeniera
Ingeniera de sistemas
Ingeniera de sistemas
Sistema y Software
Sistema y Software
Ingeniera de software
Ingeniera de software
Producto, proceso y personas(Recurso Humano) en el desarrollo de software
Producto, proceso y personas(Recurso Humano) en el desarrollo de software
Mtodos, paradigmas o ciclos de vida
Mtodos, paradigmas o ciclos de vida
Metodologa, tcnicas, tecnologa y herramientas
Metodologa, tcnicas, tecnologa y herramientas
Realice un cuadro donde se resuma las caractersticas, ventajas y desventajas de los
Realice un cuadro donde se resuma las caractersticas, ventajas y desventajas de los
paradigmas de desarrollo de software
paradigmas de desarrollo de software
Explique las causas de la crisis del software
Explique las causas de la crisis del software
Grafique y explique el proceso genrico de la ingeniera del software
Grafique y explique el proceso genrico de la ingeniera del software
Describa las principales organizaciones de estandarizacin de la ingeniera de software
Describa las principales organizaciones de estandarizacin de la ingeniera de software
Describa los principales estndares y modelos de ingeniera de software.
Describa los principales estndares y modelos de ingeniera de software.
Realice el primer avance del proyecto final. Revise las orientaciones que se explican a
Realice el primer avance del proyecto final. Revise las orientaciones que se explican a
continuacin
continuacin
ORIENTACIONES
ORIENTACIONESPARA
PARAEL
ELPROYECTO
PROYECTOFINAL
FINAL
Realizar una pre-investigacin de una empresa o institucin donde se va a desarrollar el

proyecto de software de fin de asignatura, y como resultado de esa investigacin, elaborar el
documento del estudio preliminar en el cual se describir brevemente el problema a dar
solucin.
El Estudio preliminar debe contener el siguiente formato:
Cartula (Primera pgina):
Logotipo del proyecto de desarrollo de software

Nombre del Documento (en este caso Estudio Preliminar)
Versin del Documento
A todas las pginas del documento colocar:
29
Encabezado de pgina: Cdigo y nombre del documento, nmero de

pgina, versin, Nombre del Proyecto
Pie de pgina: Autor y fecha de creacin
Control de Cambios (Segunda Pgina): Es una matriz que incluye los

siguientes campos: fecha de cambio, descripcin del cambio, responsable,
versin
ndice (Tercera pgina)
1. Introduccin (Hacer un breve resumen del documento)

1.1. Propsito (del documento del estudio preliminar)
1.2. Definiciones, acrnimos y abreviaturas
1.3. Referencias
2. Datos de la empresa o institucin donde se desarrollar el proyecto de
software: nombre de la empresa o institucin, direccin, telfonos, ciudad
3. Fuentes de informacin (las personas de la empresa o posibles usuarios
directos e indirectos del software)
4. Descripcin de la institucin o empresa (Realizar una breve descripcin
histrica, misin y visin en caso de tener)
4.1. Objetivos de la institucin (general y especficos)
4.2. Orgnico funcional (organigrama funcional)
4.3. Orgnico de procesos (funciones de cada uno de los cargos)
4.4. Funcionamiento actual de la empresa,
4.5. Identificacin de problemas, causas y posibles efectos
5. Alternativa(s) de solucin y objetivos de la empresa con el software a
desarrollar)
6. Anexos
AUTOEVALUACIN
AUTOEVALUACINTEMA
TEMAI I
1. Conteste con una (V) si es verdadero o con una (F) si es falso:
a. (
) El producto en ingeniera de SW es considerado como el resultado de ejecutar
una actividad o tarea.
b. (
) El proceso es un conjunto de entregables.
c. (
) La tcnica es la estrategia que se aplica para ejecutar una actividad de un
mtodo
d. (
) El software es considerado como el conjunto de programas.
2. Complete:
a. Con sus propias palabras defina el trmino Ingeniera de Software:
....................................................................................................................
....................................................................................................................
b. Mtodo en ingeniera de software...........................................................
....................................................................................................................
....................................................................................................................
30
c. Tcnicas:
....................................................................................................................
....................................................................................................................
d. CASE:
....................................................................................................................
....................................................................................................................
Principales organizaciones de estandarizacin: ....
....................................................................................................................
....................................................................................................................
Proceso: ....
....................................................................................................................
....................................................................................................................
3. Elabore un cuadro resumen de las caractersticas de los diferentes paradigmas de
desarrollo de software
4. Describa las etapas de un proceso de Ingeniera de SW Genrico
5. Describa brevemente los principales estndares de la ingeniera de software
TUTORAS
TUTORASPROGRAMADAS
PROGRAMADAS
Consulte en su centro de informacin o a su tutor el horario de los encuentros presenciales,
y/o virtuales (Chat) o las consultas por telfono. Anote a continuacin para que lo tenga en
cuenta en el desarrollo de este tema:
Fecha
Hora
Actividad
31
INGENIERA DE REQUISITOS
NGENIERA DE SOFTWARE I
SISTEMA DE
SISTEMA DE
HABILIDADES
VALORES
Conceptos
de
Ingeniera
de Identificar
y Responsabilidad
Requisitos
recolectar requisitos
Criticidad
Descripcin de las actividades del Validar y gestionar Honestidad
proceso de la IR
requisitos
Obtencin de requisitos
Elaborar
los
Anlisis de requisitos
requisitos del software
Especificacin de Requisitos
segn el estndar de IEEE 830
Validacin de requisitos
Gestin de requisitos
TIEMPO
TIEMPOESTIMADO
ESTIMADODE
DEESTUDIO
ESTUDIO
Horas presenciales:
16
16
32
16
48
INTRODUCCIN
INTRODUCCIN
Los requisitos constituyen un insumo determinante en el desarrollo del software; los
usuarios o clientes juegan un papel de proveedores de informacin y los desarrolladores
deben interactuar con ellos para la obtencin de requisitos. La fase de requisitos del
software se puede describir como un proceso ingenieril (por esta razn algunos autores lo
consideran como Ingeniera de Requisitos (IR)) que consta de una serie de actividades
que dan lugar, fundamentalmente, a una especificacin del producto software que se ha
decidido construir. En concreto todas ellas se organizarn por actividades de educcin u
obtencin de informacin, de especificacin, de validacin y de gestin.
En los ltimos aos han surgido grandes cambios en el campo de la Ingeniera de
Requisitos. As, en primer lugar, se ha establecido un reconocimiento general de la
importancia de la Ingeniera de Requisitos y de los riesgos en que se incurren si sta se
realiza de forma incorrecta o insuficiente. Actividades propias de esta rea, como la
35
especificacin de requisitos o la gestin de requisitos del usuario, son algunas de las

consideradas ms crticas en el desarrollo y la produccin del software.
Pero, en segundo lugar, y como consecuencia de la asuncin de esta problemtica
situacin por parte de los implicados en la industria del software, se ha llegado a introducir
explcitamente la Ingeniera de Requisitos en modelos de Mejora del Proceso Software. O,
por la misma razn, se han desarrollado guas e interpretaciones que permiten el estudio
de la conformidad de procesos y productos de la Ingeniera de Requisitos a estndares
internacionales de Calidad que buscan garantizar la satisfaccin del cliente. Este tema
trata la implicacin entre aspectos de calidad del producto final con las prcticas
relacionadas con la Ingeniera de Requisitos.
OBJETIVO
Realizar la especificacin de los requisitos de software del problema planteado
ESQUEMA
ESQUEMADEL
DELTEMA
TEMAIIII
36
ACTIVIDADES
ACTIVIDADESDE
DEAPRENDIZAJE
APRENDIZAJETEMA
TEMAIIII
Para el estudio del Tema II necesitas revisar la siguiente bibliografa:

Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta
Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1,
2, 3, 4; Pginas: 1-99.
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Quinta
Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005. Captulos: 1
y 2; Pginas: 3-33.
Palacios, Juan. Compendio de Ingeniera de SW I). ltima revisin: Junio
2006. Documento Electrnico: CIS I 04.PPT. Captulo 3, Diapositivas:
54- 117.
P. Loucopoulos, V. Karakostas; System Requirements Engineering;
McGraw-Hill International series in Software Engineering, 1995.
Kendall & Kendall, Anlisis y Diseo de software. Captulos 4-8,
Pginas: 79-213
37
1. CONCEPTOS DE INGENIERA DE REQUISITOS
Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender

perfectamente los requisitos del software. Independientemente de lo bien diseado o
codificado que est un programa, si se ha analizado y especificado pobremente,
decepcionar al usuario y desprestigiar al que lo ha desarrollado (Roger S. Pressman.
Ingeniera del Software Mc Graw Hill 1995).
En este tema se tratar el proceso de la Ingeniera de Requisitos y su importancia como
etapa fundamental en el desarrollo de SW. El documento de Especificacin de Requisitos
(ERS en espaol o SRS en ingls) es un producto importante que servir de base para
procesos subsiguientes de ingeniera de software como planificacin, anlisis, diseo,
construccin, pruebas y validacin con los usuarios.
Importancia de los Requisitos
Los requisitos indudablemente son importantes porque constituyen la base para los
dems procesos de desarrollo del software. Diferentes autores mencionan lo complejo de
este proceso, los posibles errores y sus repercusiones en el producto de SW y sus
usuarios.
La parte ms difcil en la construccin de sistemas software es decidir precisamente qu
construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los
requerimientos tcnicos detallados, incluyendo todas las interfaces con humanos,
mquinas y otros sistemas software. Ninguna otra parte del trabajo puede perjudicar tanto
el resultado final si se realiza de forma errnea. Ninguna otra parte es tan difcil de
rectificar posteriormente (Frederick P. Brooks J., 1987. Es autor del libro The mythical
Man-Month, un clsico de la Ingeniera del Software escrito en 1975 y reeditado 20 aos
despus y que an sigue vigente).
Qu porcentaje de proyectos concluyen con xito? Un estudio realizado por Standish
Group analiz el desarrollo de 8000 proyectos de software, realizados por 350 empresas
diferentes y concluy que slo el 16% de los proyectos de software se realizan con xito.
El estudio identific como principales causas de los problemas:
Falta de informacin por parte de los usuarios
Requisitos deficientes (incompletos y cambiantes)
La planificacin de agendas y estimaciones de costes no se realizaron en base a los
requisitos
Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del
proyecto
Los criterios de xito de un proyecto son:
Implicacin de los usuarios
Apoyo de los directivos
38
Enunciado claro de los requisitos

No desviarse de las fechas previstas.
No desviarse de los costes estimados.
Que el producto final cubra las expectativas y necesidades del cliente.
Que funcione correctamente.
Errores en los requisitos

Segn Boehm (1975), 45% de los errores tienen su origen en los requisitos y en el
diseo preliminar. DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto
SW, se deben a una mala especificacin de requisitos.
Tragedias ocurridas por defectos en el SW
De 6 nuevos proyectos que entran en servicio 2 quedan cancelados.
Los proyectos de sistemas de tamao medio consumen 150% ms de tiempo
Alrededor de 3/4 partes de sistemas grandes no funcionan como se quera o no se

utilizan para nada.
El 55 % de los proyectos cost ms de lo esperado
El 68% incumpli plazos previstos.
El 88% tuvo que redisearse
El 34% se termin y no se utiliz por cambio de tecnologa

Algunos casos reales de fracasos de SW:
Un sensor mal programado por Francia, destruy el supe cohete europeo Ariane
5 (El Pas, 23 de junio de 1996)
2 Billones de dlares perdidos al no poder poner en marcha el aeropuerto de

Denver (USA) por culpa del software de control del sistema de traslado de equipajes
(fecha prevista apertura 1-noviembre-93; abri el 28-febrero-95, retraso de 16 meses).
Computer, Febrero, 1995.
Proyeccin de errores
Los errores que no se logren identificar en la fase de requisitos provocarn errores
mayores en las siguientes fases de desarrollo del software. Los errores en los requisitos
se comportan como una enfermedad contagiosa que siempre repercute en todas las fases
del proyecto.
Estimacin: No es posible estimar con rigor costes y recursos necesarios para
desarrollar algo que no se conoce.
Planificacin: No se puede confiar en la planificacin para el desarrollo de algo que no
se sabe bien como es.
Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en
restricciones o futuras evoluciones, producen arquitecturas que ms tarde se
confirmarn como errneas y sern modificadas.
Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de
prueba y error que derrochan horas y paciencia de programacin sobre patrones de
re codificacin continua y programacin heroica.
39
Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones

tienen errores de bulto, o peor an, no estn reflejadas en una especificacin de
requisitos, no ser posible validar el producto con el cliente.
50-200X
Coste de la
correccin
50-200X
Fase en la que se
detecta el fallo
Requisitos
1X
1X
Arquitectura
Diseo detallado
Construccin
Requisitos
Arquitectura
Diseo
detallado
construccin
Produccin
Fase en la que se soluciona el fallo
Los defectos comunes en los requisitos y sus consecuencias
40
Implicacin insuficiente
del cliente
Problemas en la validacin
del producto obtenido
Requisitos crecientes
y cambiantes
Degradacin de la estructura
y arquitectura del producto
Requisitos ambiguos
Prdida de tiempo en
re-codificacin
Requisitos
innecesarios
Trabajo innecesario
Requisitos insuficientes
Problemas en la validacin
del producto obtenido
Requisitos insuficientes
Error en la estimacin
y planificacin
Omisin de las necesidades

de grupos de usuarios
Usuarios insatisfechos
Beneficios de los buenos requisitos
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe

realizarse. Requisitos bien elaborados y validados con el cliente evitan descubrir al
terminar el proyecto que el sistema no era lo que se peda.
Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se

emplearn para su validacin. Resulta muy difcil demostrar al cliente que el
producto desarrollado hace lo que el pidi si su peticin no est documentada y
validada por l.
Base objetiva para la estimacin de recursos (coste, personal en nmero y

competencias, equipos y tiempo). Si los requisitos no comprenden necesidades
reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el
fondo son clculos de probabilidad que siempre implican un margen de error; por esta
razn disponer de la mayor informacin posible reduce el error.
Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.). Ms all

de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios
que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente
sistemas sobredimensionados o con serias deficiencias de rendimiento.
41
Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de

omisiones y malentendidos. Tener un conocimiento preciso de lo que hay que hacer
evita la prueba y error, repeticin de partes ya desarrolladas, etc.
Qu son los requisitos?

Los requisitos del sistema son La descripcin de los servicios y restricciones.
IEEE define Requisito como:
Condicin o aptitud necesaria para resolver un problema o alcanzar un objetivo.

Condicin o facilidad que debe proporcionar un sistema o algunos de sus
subsistemas para satisfacer un contrato, norma, especificacin o cualquier otra
condicin impuesta formalmente a travs de un documento.
Una representacin documentada de una condicin o facilidad.
Requisito segn Norma MIL-STD STD-498. Caracterstica del sistema que es una
condicin para su aceptacin.
Requisito segn Goguen. Propiedad que un sistema debera tener para tener xito en el
entorno en el que se usar.
Un requisito define: Qu hace el sistema? Y no Cmo lo hace?
mbitos de los requisitos
Sistema
Sistema
Descripcin
Descripcin del
del sistema
sistema
ConOps
ConOps
Software
Software
Requisitos
Requisitos del
del software
software
SRS
SRS
mbitos
mbitos
Descripcin del sistema. Documento, tambin denominado ConOps y normalizado en

el estndar IEEE Std. 1362-1998.
Definicin de ConOps: Documento dirigido a los usuarios, que describe las caractersticas
de un sistema propuesto, desde el punto de vista del usuario. La Descripcin del Sistema
es el medio de comunicacin que recoge la visin general, cualitativa y cuantitativa de las
caractersticas del sistema; compartido por la parte cliente y desarrolladora.
Especificacin de requisitos del software (SRS o ERS). Un documento SRS es la
especificacin de las funciones que realiza un determinado producto de software,
programa o conjunto de programas en un determinado entorno.
42
A travs de los SRS se determina qu funcionalidades deben realizarse, qu datos deben

generarse en cada resultado, en qu lugar y quin los debe producir. La SRS debe
centrarse en los servicios que se realizarn, pero, en general, no debe especificar
elementos de diseo o de proyecto. Deben centrarse nicamente en el punto de vista
externo del sistema, y no en el funcionamiento interno.
El documento de especificacin de requisitos puede elaborarlo el personal representativo
de la parte suministradora (desarrollador), o de la parte cliente; si bien es aconsejable la
intervencin de ambas partes.
QU ES INGENIERA DE REQUISITOS?
La Ingeniera de Requisitos comprende las actividades de desarrollo de software (y
Sistemas de Informacin) relacionadas con la gestin y definicin de necesidades,
restricciones y atributos de calidad para sistemas nuevos o actuales.
La IR trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir,
documentar y mantener los requisitos para sistemas basados en computadora, de forma
sistemtica y repetible.
IEEE define la IR como: Proceso de estudio de necesidades de los usuarios con el objeto
de llegar a una definicin del sistema HW/SW.
Segn el profesor Loucopoulos: La IR consiste en un trabajo sistemtico de desarrollo de
requisitos, a travs de un proceso iterativo y cooperativo de anlisis del problema,
documentando los resultados en una variedad de formatos y probando la exactitud del
conocimiento adquirido.
Proceso de la Ingeniera de Requisitos
Obtener informacin
Obtener
informacin
OBTENCIN
Clasificarla, localizar
inconsistencias, dar
prioridades, pasar a
requisitos
ANLISIS
Registro y contrastacin
Escribir los
requisitos
Comprobar que
son formalmente
correctos y lo que
el cliente quiere
ESPECIFIC
ACIN
VERIFICACIN
&
VALIDACIN
Controlar las
modificaciones
Registrar
cambios, estudiar
su impacto,
actualizar
documentacin
GESTIN
1. Obtencin (elicitacin). El primer paso consiste en conocer y comprender las

necesidades y problemas del cliente.
En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y,
en funcin de las caractersticas del entorno y del proyecto se emplean las tcnicas ms
apropiadas para la identificacin de las necesidades que deben satisfacerse.
43
2. Anlisis. Una vez obtenida la informacin necesaria del entorno, es necesario

sintetizarla, darle prioridades, analizar posibles contradicciones o conflictos, descomponer
el sistema y distribuir las necesidades de cada parte, delimitar los lmites del sistema y
definir su interaccin con el entorno.
3. Especificacin. Cuando ya se conoce el entorno del cliente y sus necesidades, es
necesario plasmarlas en forma de requisitos en los documentos que sirven de base de
entendimiento y acuerdo entre cliente y desarrollador, y que establecern tanto la gua
desarrollo como los criterios de validacin del producto final.
Documentar los requisitos es la condicin ms importante para gestionarlos
correctamente.
4. Verificacin y validacin. Los requisitos deben ser formal y tcnicamente correctos
(verificacin), y satisfacer las necesidades del sistema, sin omitir ninguna ni incluir
funcionalidades innecesarias (validacin).
El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico
que los diferencia es que verificacin se refiere a la calidad formal, en este caso de los
documentos de requisitos (no son ambiguos, no son incompletos, son posibles,
verificables, etc.) y validacin comprende la adecuacin en el entorno de produccin, en el
caso de la documentacin de requisitos, la conformidad por parte del cliente de que
reflejan lo que l quiere.
5. Gestin. Los requisitos cambiarn durante el desarrollo del sistema, y es necesario
poder trazar en cada cambio todas las partes afectadas, as como poder medir el impacto
que cada modificacin implica en la planificacin del proyecto.
TAREAS
TAREASDEL
DELCRDITO
CRDITO22
Realiza las siguientes actividades con el propsito de reforzar conocimientos en IR:
Realiza las siguientes actividades con el propsito de reforzar conocimientos en IR:
Cules son los factores de xito y de fracaso de los proyectos de software?

Cules son los factores de xito y de fracaso de los proyectos de software?
Qu tragedias ha causado el desarrollo de software con defectos?
Qu tragedias ha causado el desarrollo de software con defectos?
Qu es la Ingeniera de Requisitos (IR)?
Qu es la Ingeniera de Requisitos (IR)?
Cul es la importancia de la Ingeniera de Requisitos?
Cul es la importancia de la Ingeniera de Requisitos?
A quienes dirigirnos para recolectar requisitos?
A quienes dirigirnos para recolectar requisitos?
Cul es la clasificacin de los requisitos?
Cul es la clasificacin de los requisitos?
Describa las etapas del proceso de la IR
Describa las etapas del proceso de la IR
Investigue las tcnicas de especificacin de requisitos
Investigue las tcnicas de especificacin de requisitos
Cmo se clasifican los requisitos?
Cmo se clasifican los requisitos?
Describa el estndar IEEE 830 -1998 para documentar requisitos.
Describa el estndar IEEE 830 -1998 para documentar requisitos.
44
2. DESCRIPCIN DE LAS ACTIVIDADES DEL PROCESO DE LA IR
A. OBTENCIN DE REQUISITOS.
Este proceso tambin es considerado como: elicitacin, educcin, formulacin,
identificacin o extraccin.
La especificacin de requisitos se refiere a la captura y descubrimiento de los

requisitos.
Es una actividad ms humana que tcnica.
Se identifica a los interesados (clientes y usuarios) y se establecen las primeras
relaciones entre ellos y el equipo de desarrollo.
A quin (es) se dirigen los requisitos?

El proceso de obtencin de requisitos se dirige a:
Usuarios potenciales o clientes

Productores de software o sistemas
Cada uno de estos dos escenarios lleva a situaciones totalmente diferentes: En el primer
caso, se definen las necesidades (puede servir como base para el pliego de condiciones)
y ser muy general para permitir distintas soluciones. En el segundo caso, las
especificaciones suponen un paso inicial para el desarrollo de software y debern ser
mucho ms especficas.
Fuentes de los requerimientos
Identificar los objetivos del proyecto y eventualmente realizar un estudio de
viabilidad de los mismos.
mbito de aplicacin o dominio de conocimiento del proyecto (permitir resolver
conflictos entre actores)
Identificar a todos los actores del proyecto para poder disear un sistema que
recoja diferentes puntos de vista de manera consensuada y sea fcil de usar por
todos ellos
Identificar el entorno operacional para poder establecer las restricciones del
proyecto y los costes.
Entorno organizativo: identificacin de los condicionantes que la estructura, la
cultura y la poltica interna de la organizacin puedan imponer o sobre-entender.
Tcnicas de obtencin de los requerimientos
Entrevistas con los actores (clientes y/o usuarios): cerradas / abiertas
45
Encuestas aplicando cuestionarios con preguntas concretas y respuestas

cerradas / abiertas
Escenarios. Los requisitos se sitan en el contexto de uso (casos de uso).
Permiten contextualizar y preguntarse sobre Qu pasara si ... ? Cmo se
hace sto ?
Prototipos: permiten clarificar y precisar requerimientos. tiles cuando la
incertidumbre es total acerca del futuro sistema.
Reuniones de grupo (normales o brainstorming): permiten aportar mayores
puntos de vista que a travs de entrevistas individuales y aflorar puntos de vista
contrapuestos. Es necesario gestionarlas correctamente para evitar conflictos o
puntos de vista dominantes.
Observacin de los sistemas actuales y medida de distintos parmetros de los
mismos a travs de la inmersin operacional. Ilustra acerca de las tareas y ciertos
procesos complejos o sobreentendidos que raramente se explicitan.
Estudio de los documentos y formularios existentes.
Visitas a otras instalaciones, investigacin externa, jornadas profesionales, ferias
Presentaciones comerciales, estudio de productos SW ya existentes.
B. ANLISIS DE REQUISITOS.
Consiste en detectar y resolver conflictos entre requisitos.

Se precisan los lmites del sistema y la interaccin con su entorno.
Se trasladan los requisitos de usuario a requisitos del software (implementables).
Se realizan tres tareas fundamentales: Clasificacin, Modelizacin y
Negociacin.
Clasificacin de Requisitos.
La clasificacin ms tpica de los requisitos es la que se presenta a continuacin:
Capacidades
FUNCIONALES
Restricciones
TIPOS DE REQUISITOS
NO FUNCIONALES
Restricciones
DE INTERFAZ
Sin embargo, algunos autores presentan otras formas de clasificacin de requisitos:

Por prioridades
Por coste de implementacin
Por niveles (alto nivel, bajo nivel)
46
Segn su volatilidad/estabilidad
Si son requisitos sobre el proceso o sobre el producto
Requisitos Funcionales:
Definen el comportamiento del sistema.
Describen los servicios o funciones del sistema
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la
excesiva generalidad, insuficiencia de detalle o ambigedad, y el exceso de detalle
con precisiones o descripciones innecesarias o redundantes.
Requisitos No funcionales: Definen aspectos, que sin ser funcionalidades, (tareas que
el sistema debe realizar) resultan deseables desde el punto de vista del usuario.
Generalmente comprenden atributos de calidad:
Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento. etc.
Requitos de Interfaz. Definen las interacciones del sistema con su entorno. Interfaces de
Usuarios o con otros sistemas.
Modelizacin de Requisitos:
La meta es entender mejor el problema, ms que iniciar el diseo de la solucin
(idealmente)
El tipo de modelo elegido depende de:
La naturaleza del problema
La experiencia del modelizador
La disponibilidad de herramientas
Por decreto. El cliente impone una notacin
Tradicionalmente se entenda que el anlisis se reduca a modelizar (DFDs, modelos de
objetos, etc), pero el anlisis de requisitos NO es exclusivamente un proceso de
modelizacin. Por otro lado, no existe la mejor forma de modelar requisitos. En
realidad, no hay evidencia emprica que demuestre, en general, la superioridad de unas
notaciones de modelizacin frente a otras.
Negociacin de Requisitos:
Tambin denominada resolucin de conflictos entre:
Requerimientos incompatibles
Actores que demandan requerimientos incompatibles
Recursos disponibles y requerimientos solicitados
Requerimientos funcionales y restricciones
47
Frecuentemente el analista no tiene capacidad para decidir, por lo que debe favorecer el
consenso, y si hay un contrato de prestacin de servicios, debe dejarse traza del por qu
de la decisin tomada.
Podra incorporarse como parte de la Validacin de requerimientos. La mejor tcnica es
la de las reuniones con los involucrados, previamente preparadas y documentadas
para conocer el impacto de los conflictos y sus posibles soluciones.
Otras tcnicas son: correo electrnico, boletines electrnicos, bases de datos compartidas
tipo Lotus Notes con la documentacin de los requerimientos y sus conflictos. No estn
excesivamente probadas y su utilidad puede ser dudosa si se genera una actitud de
desinters.
C. ESPECIFICACIN DE REQUISITOS.
Para la especificacin de los requisitos o documentacin es necesario utilizar algn
estndar, as encontramos a los siguientes:
IEEE Std. 830-1998

PSS-05 de la Agencia Espacial Europea (ESA)
El estndar IEEE std. 830 1998 contiene la siguiente estructura:

1. Introduccin
2.1. Propsito
2.2. Alcance
2.3. Definiciones
2.4. Referencias
2.5. Visin General
3. Descripcin General
3.1. Perspectiva del producto
3.2. Funciones del producto
3.3. Caractersticas del usuario
3.4. Restricciones
3.5. Suposiciones
4. Requisitos Especficos
5. Apndices
6. ndice
Fuente: (http://es.tldp.org/I+D/donantonio/doc-ers_ieee830-donantonio-servidor/donantonio-servidor-html/index.html )
Los aspectos bsicos que una descripcin de requisitos debe cubrir son:
Funcionalidad. Descripcin de lo que el software debe hacer.
Interfaces externos. Cmo debe interactuar el software con las personas, el
sistema de hardware, o con otros sistemas (software y hardware).
Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta,
tiempos de recuperacin, tiempos de determinadas funciones.
48
Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad,

etc.
Restricciones de diseo en la implementacin. Indicacin de las restricciones
que puedan afectar por la necesidad de sometimiento a estndares, lenguajes,
polticas de integridad de bases de datos, lmites de recursos disponibles para el
desarrollo, sistema operativo, etc.
Propiedades deseables de los requisitos.
Comprensible por clientes, usuarios y desarrolladores.

Correcto, sin requisitos innecesarios o redundantes.
No ambiguo y con el nivel de precisin necesario.
Completo, que no falten requisitos y que todas las respuestas del sistema a entradas
tanto vlidas como invlidas estn especificadas.
Consistente, sin conflictos ni contradicciones entre los requisitos o con documentos de
nivel superior y con una terminologa nica.
Verificable, que pueda comprobarse que el sistema final cumple los requisitos
mediante un proceso finito y de coste razonable.
Fcilmente modificable, organizada, con los requisitos identificados y con control de
configuracin.
Rastreable, de forma que se conozcan las dependencias de los requisitos hacia detrs
y hacia delante.
Priorizada, indicando la importancia de los requisitos.
Anotada con estabilidad, para conocer posibles fuentes de cambios durante el
desarrollo.
Independiente del diseo y la implementacin, para evitar complejidades innecesarias
y no limitar a los diseadores.
D. VALIDACIN DE REQUISITOS
La validacin de requisitos consiste en descubrir problemas en el documento de requisitos
antes de comprometer recursos en la implementacin del software.
El documento debe revisarse para:
Descubrir omisiones
Conflictos
Ambigedades
Comprobar la calidad del documento y su grado de de adhesin a estndares
Para revisar el documento de los requisitos es aconsejable conformar una comisin de
revisin que incluya desarrolladores y usuarios. Esta comisin debe encargarse de:
Buscar problemas en el documento de los ERS.
Convocar a reuniones y establecer acuerdos.
Algunas tcnicas para identificar problemas habituales:
Listas de comprobacin checklists
49
Prototipado. Permite descubrir con rapidez si el usuario se encuentra satisfecho o

no con los requisitos
Validacin de Modelos. Cuando los requisitos son expresado en base a modelos
como: Casos de Uso, DFDs u otros.
Validacin de su testeabilidad. El equipo de pruebas debe revisar los requisitos.
E. GESTIN
La gestin de requisitos debe realizarse durante todo el proceso de desarrollo del
software. Es parte de la Gestin de la Configuracin del Software y se realizan algunas
actividades:
Definir procedimientos de cambios: definen los pasos y los anlisis que se
realizarn antes de aceptar los cambios propuestos.
Cambiar los atributos de los requisitos afectados.
Mantener la trazabilidad: hacia atrs, hacia delante y entre requisitos.
Control de versiones del documento de requisitos
TAREAS DEL CRDITO 3

1. Para desarrollar habilidades en la aplicacin del proceso de Ingeniera de Requisitos, verifica
si los siguientes requisitos estn bien redactados, disctelo con tu profesor gua. Identifica en
cada requisito los siguientes elementos: proceso a automatizar, archivo(s) lgico(s), los datos
a utilizar, y las restricciones u observaciones.
Gestin de Doctores
Req (11) Registrar nuevo doctor, con los siguientes datos: cdigo del doctor, nombre del
doctor, apellido del doctor, especialidad del doctor, estado del doctor, telfono del doctor,
direccin del doctor.
Req (12) Se permitir buscar por cdigo o nombres del doctor, pidiendo que ingrese el dato
que desea buscar.
Req (13) Se podr modificar datos del doctor cumpliendo con el (Req 12) y no se podr
cambiar el cdigo del doctor. En caso de no constar los datos del doctor en la base de datos
se proceder a cumplir el (Req 11).
Req (14) Genera una consulta que muestre en pantalla un listado de todos los doctores con
sus respectivos datos, previamente cumpliendo con el (Req 12).
Req (15) Dar de baja a los datos de un Doctor, aplicando un criterio de eliminacin lgica por
medio del (Req12). Este proceso no implica una eliminacin definitiva de la base de datos.
2. Como actividad del crdito 3 debe realizar el SEGUNDO AVANCE DE SU PROYECTO

FINAL. Revisa las orientaciones que se indican a continuacin.
50
ORIENTACIONES
ORIENTACIONESPARA
PARAEL
ELPROYECTO
PROYECTOFINAL
FINAL
Como actividad laboral de avance del proyecto final, en este tema se deber elaborar el
documento de ESPECIFICACIN DE REQUISITOS DEL SOFTWARE (ERS). Para lo
cual es necesario realizar las siguientes tareas:
Recolectar los requisitos del software a desarrollar, es necesario ejecutar tcnicas

de recoleccin de informacin como entrevistas, encuestas, observacin, revisin
de archivos y documentos, monitoreo de tareas, efectuar reuniones formales. Para
esta actividad se debe involucrar a todos los usuarios directos o indirectos del
software a desarrollar.
Documentar los requisitos aplicando el estndar IEEE 830-1998
Refinar (depurar) el documento de requisitos realizando reuniones formales con
los usuarios.
Gestionar los requisitos.
El ESPECIFICACIN DE REQUISITOS DEL SOFTWARE (ERS) debe contener el

siguiente formato:

Nombre del Documento (en este caso ESPECIFICACIN DE
REQUISITOS DEL SOFTWARE (ERS))


versin
1. Introduccin (Hacer un breve resumen del documento)

1.1. Propsito (del documento)
1.2. mbito del Sitema
1.4. Referencias
1.5. Visin general
51
2. Descripcin General
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Caractersticas de los usuarios
2.4. Restricciones
2.5. Dependencias
3. Requisitos Especficos
3.1. Requisitos Funcionales
3.2. Requisitos de interfaces externos
3.2.1. Interfaces de Usuario
3.2.2. Interfaces Hardware
3.2.3. Interfaces Software
3.2.4. Interfaces de Comunicacin
3.3. Requisitos de Rendimiento
3.4. Requisitos de desarrollo
3.5. Requisitos Tecnolgicos
3.6. Atributos
3.7. Seguridad
4. Apndices (Anexos)
4.1. Entrada de datos
4.2. Salida de datos
AUTOEVALUACIN
AUTOEVALUACINTEMA
TEMAIIII
1. Complete:
a.
b.
c.
d.
e.
Requisito:
....................................................................................................................
....................................................................................................................
IEEE 830...........................................................
....................................................................................................................
....................................................................................................................
Cul es la parte ms difcil en la construccin de un software?
....................................................................................................................
....................................................................................................................
....................................................................................................................
Tcnicas usadas en el proceso de validacin de requisitos:
....................................................................................................................
....................................................................................................................
....................................................................................................................
Cmo se comportan los errores en los requisitos en las dems fases del
proceso de ingeniera del software?: .. ..
..
....................................................................................................................
....................................................................................................................
52
f.
Cul es el mbito de los requistos?:

....................................................................................................................
....................................................................................................................
....................................................................................................................
2. Elabore un cuadro resumen de las tcnicas para recolectar requisitos del

software
3. Qu es la Ingeniera de Requisitos
4. Realice un ensayo sobre los procesos de la Ingeniera de Requisitos
TUTORAS
TUTORASPROGRAMADAS
PROGRAMADAS
Consulte en su centro de informacin o a su tutor el horario de los encuentros
presenciales, y/o virtuales (Chat) o las consultas por telfono. Anote a continuacin para
que lo tenga en cuenta en el desarrollo de este tema:
Fecha
Hora
Actividad
53
GESTIN DE PROYECTOS DE
SOFTWARE
SISTEMA DE
HABILIDADES
CONCEPTOS SOBRE GESTIN DE
Gestionar el
PROYECTOS DE SOFTWARE
personal, el proceso y el
El espectro de gestin, el
problema durante el
personal, el producto, el proceso, el
proyecto de software
proyecto
PLANIFICACIN DEL PROYECTO DE
Identificar y
SOFTWARE
generar equipos de
Objetivos de la planificacin del
software, estimaciones
proyecto
fiables del esfuerzo,
mbito del software, recursos
costes y duracin del
Estimacin del proyecto de
proyecto
software
o
Tcnicas de puntos de
funcin
o
Modelos empricos de
estimacin
La decisin desarrollar-comprar
PLANIFICACIN TEMPORAL Y
Desarrollar la
SEGUIMIENTO DEL PROYECTO
planificacin temporal de
Conceptos bsicos, la relacin
proyecto
entre las personas y el esfuerzo
Definicin de un conjunto de
tareas para el proyecto de software.
Seleccin de las tareas de Ing.
SW
Refinamiento de las tareas
principales
Definir una red de tareas
ANLISIS DE RIEGOS
Identificar y
Estrategias de riesgos
utilizar las tcnicas para
Riesgos del software
la evaluacin de los
Identificacin y proyeccin del
riesgos que pueden tener
riesgo
impacto en el xito del
Reduccin, supervisin y
proyecto.
gestin del riesgo
Riesgos y peligros para la
seguridad
PLAN DE GARANTA DE CALIDAD
Definir y
Introduccin
controlar la calidad de un
Documentacin
proyecto
Revisiones y auditorias
Gestin de Configuracin
PLAN DE GESTIN DE
Identificar y
CONFIGURACIN
realizar la forma de
SISTEMA DE
VALORES
Responsabilidad
Compaerismo
Honestidad
Responsabilidad
Compaerismo
Honestidad
Responsabilidad
Compaerismo
Honestidad
Responsabilidad
Compaerismo
Honestidad
Responsabilidad
Compaerismo
Honestidad
Responsabilidad
Compaerismo
57
Introduccin
Actividades de GCS
Programacin
gestionar los cambios

durante el desarrollo de
software y despus de
entregar al cliente
Honestidad
58
TIEMPO
TIEMPOESTIMADO
ESTIMADODE
DEESTUDIO
ESTUDIO
Horas presenciales:
24
24
48
24
72
INTRODUCCIN
INTRODUCCIN
En este tema se estudiar los conceptos clave que conducen a una gestin efectiva de
proyectos de software. Comenzaremos con los conceptos bsicos de gestin de proyectos
de software, se analizarn algunas tcnicas para la estimacin, elaboracin de un
cronograma realista, revisin de algunas tcnicas de gestin que conducen a una efectiva
supervisin, reduccin y gestin del riesgo, finalmente, se considerarn tcnicas para
asegurar la calidad conforme un proyecto se lleva a cabo y se gestionan los cambios a lo
largo de la vida de una aplicacin.
OBJETIVO
Gestionar el proyecto de software mediante planificacin, seguimiento y control del

proceso de desarrollo de software y la realizacin de actividades de soporte como:
anlisis de riesgos, configuracin del software y control de calidad que permita la
construccin de un producto que satisfaga las necesidades del cliente.
59
ESQUEMA
ESQUEMADEL
DELTEMA
TEMAIIIIII
60
ACTIVIDADES
ACTIVIDADESDE
DEAPRENDIZAJE
APRENDIZAJETEMA
TEMAIIIIII
Para el estudio del Tema III necesitas revisar la siguiente bibliografa:
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. McGraw-Hill/Interamerica de Espaa S.A.U. 2005.
Conceptos de Gestin de proyectos. Pgina 640
Mtricas de proceso y proyecto. Pgina 663
Estimacin para proyectos de SW. Pgina 690
Calendarizacin de proyectos de SW. Pgina 724
Gestin de riesgo. Pgina 747
Gestin de calidad. Pgina 767
Gestin del cambio. Pgina 796
Roger S. Pressman. Ingeniera del Software un Enfoque Practico. Sexta Edicin. McGraw-Hill/Interamerica de Espaa S.A.U. 2005.
Gestin del Proyecto de SW. Pginas: 37 - 52.
Mtricas del SW. Pginas: 53 - 76.
Planificacin del proyecto de SW. Pginas: 77 96
Anlisis de Riesgos. Pginas: 97- 110
Plan Temporal y seguimiento. Pginas: 111 - 130.
Calidad del SW. Pginas. 131 - 150.
Gestin de la Configuracin del Software. Pginas: 151- 164
Kendall & Kendall, Anlisis y Diseo de software.
Estudio de Factibilidad: Pginas: 47- 53
Planificacin del proyecto: Pginas: 54-74
Calidad del Software: Pginas: 745-765
61
1. CONCEPTOS SOBRE GESTIN DE PROYECTOS DE SOFTWARE
Qu es gestionar? Un concepto general de gestionar es coordinar todos los recursos

disponibles para conseguir determinados objetivos, implica amplias y fuertes interacciones
fundamentalmente entre el entorno, las estructuras, el proceso y los productos que se
deseen obtener.
La gestin de proyectos involucra la planificacin, supervisin y control del personal, el
proceso y los eventos que ocurren durante la ejecucin del proyecto desde un concepto
preliminar hasta una implementacin operativa.
Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres
grandes etapas:
Fase de planificacin. Se trata de establecer cmo el equipo de trabajo deber satisfacer
las restricciones de prestaciones, planificacin temporal y coste. Una planificacin detallada
da consistencia al proyecto y evita sorpresas que nunca son bien recibidas.
Fase de ejecucin. Representa el conjunto de tareas y actividades que suponen la
realizacin propiamente dicha del proyecto, la ejecucin de la obra de que se trate.
Responde, ante todo, a las caractersticas tcnicas especficas de cada tipo de proyecto y
supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la
obra en cuestin. Cada tipo de proyecto responde en este punto a su tecnologa propia, que
es generalmente bien conocida por los tcnicos en la materia.
Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto est destinado
a finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la
puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y
responde a las especificaciones en su momento aprobadas. Esta fase es tambin muy
importante no slo por representar la culminacin de la operacin sino por las dificultades
que suele presentar en la prctica, alargndose excesivamente y provocando retrasos y
costes imprevistos.
A estas tres grandes etapas es conveniente aadir otras dos que, si bien pueden incluirse en
las ya mencionadas, es preferible nombrarlas de forma independiente ya que definen un
conjunto de actividades que resultan bsicas para el desarrollo del proyecto:
Fase de iniciacin. Definicin de los objetivos del proyecto y de los recursos necesarios
para su ejecucin. Las caractersticas del proyecto implican la necesidad de una fase o etapa
previa destinada a la preparacin del mismo, fase que tienen una gran trascendencia para la
buena marcha del proyecto y que deber ser especialmente cuidada. Una gran parte del
xito o el fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto
con una buena etapa de planificacin, algunas personas tienden a menospreciar, deseosas
por querer ver resultados excesivamente pronto.
62
Fase de control. Monitorizacin del trabajo realizado analizando cmo el progreso difiere de
lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye tambin el
liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso
subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.
El espectro de gestin. La gestin eficaz de proyectos de software se enfoca sobre las
cuatro P: personal, producto, proceso y proyecto. El orden no es arbitrario.
PRODUCTO
PRODUCTO
PROYECTO
PROYECTO
PERSONAL
PERSONAL
PROCESO
PROCESO
EL PERSONAL. La formacin de personal de software motivado y altamente calificado se

ha debatido desde los aos 60. De hecho, el factor humano es considerado como el ms
importante en el proyecto, debido a que el desarrollo del software es un trabajo ms
intelectual que fsico. En los modelos formales como el CMM (Modelo de Madurez de
Capacidades), define en su proceso de gestin de personal, las siguientes reas:
reclutamiento, seleccin, gestin del desempeo, entrenamiento, retribucin, desarrollo de la
carrera, desarrollo de la organizacin y el trabajo, y desarrollo de la cultura de equipo.
M.M.C.G.P
Reclutamiento
Seleccin
Gestin de rendimiento
Desarrollo
Entrenamiento
Retribucin
Diseo / organizacin
Desarrollo cultural
Los participantes. Se pueden clasificar en 5 categoras:
Gestores Superiores
Gestores tcnicos del proyecto
Profesionales
Clientes
Usuarios Finales
63
Los jefes de equipo. Los Jefes de equipo deben poseer ciertas capacidades, as, el modelo
MOI considera las siguientes:
Motivacin.- Habilidad para motivar con un <<tira y afloja>>
Organizacin.- Moldear procesos existentes
Ideas o innovacin.- Motivar al personal para crear y sentirse creativos
El equipo de software
La mejor estructura d equipo depende del estilo de gestin de una organizacin. Mantei,
sugiere tres organigramas de equipos genricos.
DESCENTRALIZADO
DEMOCRTICO
DESCENTRALIZADO
CONTROLADO
CENTRALIZADO CONTROLADO
No tiene jefe permanente

Las decisiones se hacen por consensos
La comunicacin entre los miembros es horizontal
Tiene jefe definido, coordina tareas
Jefes secundarios, para subtareas
Comunicacin vertical
El jefe se encarga de la solucin de problemas
La comunicacin entre el jefe y los miembros del
equipo es vertical.
La gestin exitosa de proyectos, independientemente de la estructura organizativa, es slo

tan buena como lo sean los individuos y lderes que gestionen las funciones bsicas
(Kerzner, 1998)
EL PRODUCTO. Antes de planear un proyecto se deberan establecer los objetivos y el
mbito del producto, considerar soluciones alternativas e identificar las restricciones
tcnicas y de gestin. Sin esta informacin es imposible definir estimaciones razonables del
costo, valoraciones efectivas del riesgo, una divisin realista de las tareas del proyecto o un
calendario del proyecto que ofrezca una indicacin fiable del progreso.
El desarrollador del software y el cliente se deben reunir para definir los objetivos y el mbito
del producto. En muchos casos, esta actividad comienza como parte de la ingeniera del
sistema o de la ingeniera del proceso de negocio y contina como primer paso en la
ingeniera de requisitos del SW.
EL PROCESO. Un proceso de software
proporciona el marco de trabajo desde el
PROCESO
cual se puede establecer un plan detallado
para
el
desarrollo
del
software.
ACTIVIDAD 1
ACTIVIDAD n
Generalmente
est
guiado
por
la
metodologa (mtodo o ciclo de vida +

tcnicas + soporte documental) que se
TAREA 1
TAREA X
TAREA 1
haya seleccionado para llevar a cabo el

proyecto de software. El proceso se descompone en actividades y a su vez las actividades
en tareas.
64
EL PROYECTO. Un proyecto es una accin en la que recursos humanos, financieros y

materiales se organizan de una nueva forma para acometer un trabajo nico. En este
trabajo, dadas unas especificaciones y dentro de unos lmites de costes y tiempo, se intenta
conseguir un cambio beneficioso dirigido por unos objetivos cualitativos y cuantitativos. Estos
elementos implican que un proyecto lleva una incertidumbre considerable y riesgo, y por lo
tanto su xito depender en gran medida de una adecuada gestin.
2. PLANIFICACIN DEL PROYECTO DE SOFTWARE.
El proceso de produccin del software tiene que ser gestionado y dirigido de una manera
extremadamente rigurosa y cuantitativa. De este modo se podr verificar que el trabajo
correspondiente a cada fase se ha realizado completamente dentro de los plazos de tiempo
y coste establecidos y de acuerdo con estndares especficos de calidad. Por lo tanto, las
claves del xito en la gestin del desarrollo de software son: una adecuada gestin del
proyecto de desarrollo de software y una adecuada gestin del proceso de software.
El nmero de tareas identificables a realizar por un director de proyectos, dentro del rea de
la gestin de proyectos son varias. Sin embargo, hay tres que son crticas y que deben ser
desarrolladas correctamente si se desea que el proyecto termine bien.
Estas tareas son:
a. Estimacin de duracin, coste y esfuerzo necesarios para construir el producto.
b. Planificacin de tareas a realizar, asignacin de personas, tiempos, etc. para construir el
producto.
c. Seguimiento, durante la realizacin del trabajo, para asegurar el cumplimiento de lo
planificado en cuanto a costes, fechas, etc. En caso de desviaciones del plan, se deben
tomar las medidas pertinentes.
LOS OBJETIVOS de la planificacin del Proyecto de Software, es proporcionar un marco
de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado
al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que
progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor
caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.
El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la
informacin que lleve a estimaciones razonables.
MBITO DEL SOFTWARE. Es la primera actividad que se lleva a cabo durante la
planificacin del proyecto de Software. Describe la funcin, el rendimiento, las restricciones,
las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se
refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de
rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los
lmites del software originados por el hardware externo, por la memoria disponible y por otros
sistemas existentes.
65
El mbito se define como un pre-requisito para la estimacin y existen algunos elementos

que se debe tomar en cuenta como es:
a. La Obtencin de la Informacin necesaria para el software. Para esto el analista y el
cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los
puntos de inters para su desarrollo.
b. Viabilidad. Una vez identificada la informacin necesaria para el software, es razonable
preguntarse Podemos construir el SW de acuerdo a ese mbito? Es factible el
proyecto?
Estudio de viabilidad. El estudio de viabilidad comprende:
Tcnico.
Econmico
Legal
Operativo
Anlisis costo/beneficio
Estudio de viabilidad Tcnico. Consiste en identificar el recurso hardware, software, de
comunicacin y recurso humano especializado. Se debe concluir indicando si es factible o
no desarrollar tcnicamente el proyecto.
Estudio de viabilidad Econmico. Determinar propuestas de costos de los recursos
tcnicos, humanos y materiales tanto para el desarrollo como para la implantacin (puesta
en produccin) del Sw. Adems, comprende anlisis de los costos de desarrollo, comparados
con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado, es decir
un anlisis costo/beneficio. Se debe concluir indicando si es econmicamente factible el
desarrollo del proyecto.
Anlisis coste/beneficio
Costes:
Personal Informtico
Consultora
Software adicional
Hardware
Infraestructura
Debidos al usuario
Caso de estudio:
Supongamos una empresa que lleva la contabilidad de forma manual y decide implantar un
sistema informtico para que el proceso resulte ms rpido y fiable. Actualmente dispone de 2
personas dedicadas a la contabilidad, cuyo coste (sueldo bruto + SS a cargo de la empresa) es
de 5.200.000 cada uno. Se decide comprar un paquete de contabilidad cuyo precio es de
3.000.000 y el coste de mantenimiento un 15% de ste, y que requerir una adaptacin (slo
inicialmente) valorada en 44 jornadas de trabajo de un analista programador cuya hora se
presupuesta en 4.500 pts. El ordenador que requiere se presupuesta en 500.000 pts, con un
coste de mantenimiento de un 10% anual. El departamento de contabilidad estima que se
ahorrara un 50% de tiempo de las 2 personas dedicadas a contabilidad si el sistema fuese
automtico. Se considera que la vida del sistema es de 4 aos. La formacin para su manejo
requiere una semana y se hace con los propios manuales del paquete. Se considera que el
sistema est plenamente operativo en 3 meses.
66
Anlisis coste/beneficio del caso de estudio:
Estudio de viabilidad Legal. Es determinar cualquier posibilidad de infraccin, violacin o

responsabilidad legal en que se podra incurrir al desarrollar el Sistema. Se debe indagar las
disposiciones legales de la propia empresa o externos, que los desarrolladores deben
considerar en la construccin del software. Se debe concluir indicando si es legalmente
factible el desarrollo del proyecto.
Estudio de viabilidad Operativo. Consiste en indagar a todos los usuarios que se requiere
involucrar en el proyecto, adems, contrariedades de los usuarios, posibles oponencias a la
automatizacin del software. Se debe concluir indicando si es operativamente factible el
desarrollo del proyecto.
RECURSOS. La segunda tarea de la planificacin del desarrollo de Software es la
estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software,
esto simula a una pirmide donde las Herramientas (hardware y Software), son la base
proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la
pirmide se encuentran los Componentes reutilizables.
Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el
recurso humano).
Cada recurso queda especificado mediante cuatro caractersticas:
Descripcin del recurso.

Informes de disponibilidad.
Fecha cronolgica en la que se requiere el recurso.
Tiempo durante el que ser aplicado el recurso.
67
Recursos Humanos.
La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo
puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por
ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin
y la especialidad que desempear cada profesional.
Recursos o componentes de software reutilizables.
Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin,
esto es la creacin y la reutilizacin de bloques de construccin de Software.
Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse
para una fcil aplicacin y validarse para la tambin fcil integracin.
El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener
en cuenta a medida que se avanza con la planificacin:
Componentes ya desarrollados.
Componentes ya experimentados.
Componentes con experiencia Parcial.
Componentes nuevos.
Recursos de entorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de
Ingeniera de Software, incorpora Hardware y Software.
El Hardware proporciona una plataforma con las herramientas (Software) requeridas para
producir los productos que son el resultado de la buena practica de la Ingeniera del
Software, un planificador de proyectos debe determinar la ventana temporal requerida para
el Hardware y el Software, y verificar que estos recursos estn disponibles. Cada elemento
de hardware debe ser especificado por el planificador del Proyecto de Software.
ESTIMACIN DEL PROYECTO DE SOFTWARE
Al principio, el costo del software constitua un pequeo porcentaje del costo total de los
sistemas basados en computadoras. Hoy en da el Software es el elemento ms caro de la
mayora de los sistemas informticos.
Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre
beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una
ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas, que
pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.
Qu es estimar?
Es predecir valores subjetivos pero no muy alejados de la realidad.

Se basa en la especificacin de requisitos.
68
Estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.

Aunque la estimacin, es mas un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de
costes y de tiempo. Y dado que la estimacin es la base de todas las dems actividades de
planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto,
sino que se toma en cuenta los recursos, costos y planificacin. El Tamao del proyecto es
otro factor importante que puede afectar la precisin de las estimaciones. A medida que el
tamao aumenta, crece rpidamente la interdependencia entre varios elementos del
Software.
La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la
estimacin.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:
Deje la estimacin para ms adelante (obviamente podemos realizar una estimacin

al cien por cien fiable despus de haber terminado el proyecto).
Base las estimaciones en proyectos similares ya terminados.
Utilice tcnicas de descomposicin relativamente sencillas para generar las
estimaciones de costos y esfuerzo del proyecto.
Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software.
Desdichadamente la primera opcin, aunque atractiva no es prctica.

La Segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante
similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las
opciones restantes son mtodos viables para la estimacin del proyecto de software. Desde
el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada
una de ellas como comprobacin de las otras.
Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del
software a construir y generar una estimacin de su tamao.
Tamao del software. Puede estimarse utilizando:
Una medida directa. LDC (Lneas de Cdigo fuente)
Una medida indirecta. Puntos de Puncin (PF).
Tcnicas de descomposicin:
Descomposicin del problema
Descomposicin del proceso
Estimacin basada en el problema. Las Lneas de Cdigo LDC y los Puntos de Puncin
PF son medidas utilizadas para la estimacin.
69
Estimacin basada en el Proceso. Se basa la estimacin en el proceso que se va a utilizar,

es decir, el proceso se descompone en un conjunto relativamente pequeo de actividades o
tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea.
Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso
comienza en una delineacin de las funciones del software obtenidas a partir del mbito del
proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo
paso se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de
software.
Los Modelos Empricos de estimacin.
Donde los datos que soportan la mayora de los modelos de estimacin obtienen una
muestra limitada de proyectos. Por esta razn, el modelo de estimacin no es adecuado para
todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados
obtenidos de dichos modelos se deben utilizar con prudencia.
El Modelo COCOMO
Barry Boehm, en su libro clsico sobre economa de la Ingeniera del Software, introduce una
jerarqua de modelos de estimacin de Software con el nombre de COCOMO, por su nombre
en Ingles (Constructive, Cost, Model) modelo constructivo de costos. El modelo ha
evolucionado a un modelo de estimacin ms completo llamado COCOMO II, consta de una
jerarqua de modelos de estimacin que tratan las siguientes reas:
Modelo de composicin de aplicacin. Utilizado durante las primeras etapas de la
ingeniera de software, donde el prototipado de las interfaces de usuario, la interfaz del
sistema y del software, la evaluacin del rendimiento, la evaluacin de la madurez de la
tecnologa son de suma importancia.
Modelo de fase de diseo previo. Utilizado una vez que se han establecido los requisitos y
la arquitectura bsica del software.
Modelo de fase posterior a la arquitectura. Utilizado durante la construccin del software.
Herramientas Automticas de Estimacin.
Las herramientas automticas de estimacin permiten al planificador estimar costos y
esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con importantes variables del
proyecto, tales como la fecha de entrega o la seleccin del personal. Aunque existen muchas
herramientas automticas de estimacin, todas exhiben las mismas caractersticas generales
y todas requieren de una o ms clases de datos.
A partir de estos datos, el modelo implementado por la herramienta automtica de
estimacin proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto,
los costos, la carga de personal, la duracin, y en algunos casos la planificacin
temporal de desarrollo y riesgos asociados.
70
En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de
que comience el proyecto: cuanto durara, cuanto esfuerzo requerir y cuanta gente estar
implicada. Adems el planificador debe predecir los recursos de hardware y software que va
a requerir y el riesgo implicado.
La estimacin del proyecto de software nunca ser una ciencia exacta, pero la combinacin
de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin.
Ejemplo de software de estimacin:
ESTICMACS
PLANMACS
COCOMOII
CA-SUPERPROJECT
TCNICA DE PUNTOS DE FUNCIN
Esta tcnica permite medir el tamao (funcionalidad proporcionada por el usuario), por lo que
es necesario contar con un buen documento de Especificacin de Requisitos del Software
(ERS SRS). Es la base para la estimacin de costos, esfuerzo, personas y tiempo.
En el caso de subsistemas diseados independientemente los Puntos de Funcin se
calcularn para cada uno de ellos, y luego se sumarn. Por ejemplo, cuando un sistema que
proporcione por un lado una funcionalidad on-line y por otro lado una funcionalidad batch, y
por tanto, se han diseado independientemente los dos subsistemas que proporcionan cada
funcionalidad.
Los objetivos de los Puntos de Funcin son:
Medir lo que el usuario pide y lo que el usuario recibe.
Medir independientemente de la tecnologa utilizada en la implantacin del sistema.
Proporcionar una mtrica de tamao que d soporte al anlisis de la calidad y la
productividad.
Proporcionar un medio para la estimacin del software.
Proporcionar un factor de normalizacin para la comparacin de distintos software.
Adems de estos objetivos, el proceso de contabilizar los Puntos de Funcin debera ser:
Suficientemente simple como para minimizar la carga de trabajo de los procesos de

medida.
Conciso en sus resultados.
El anlisis de los Puntos de Funcin se desarrolla considerando cinco parmetros bsicos

externos del Sistema:
Entradas (EI, del ingls External Input).

Salidas (EO, del ingls External Output).
Consultas (EQ, del ingls External Query).
Grupos de datos lgicos internos (ILF, del ingls Internal Logic File).
71
Grupos de datos lgicos externos (EIF, del ingls External Interface File).
Con estos parmetros, se determinan los puntos de funcin sin ajustar.

A este valor, se le aplica un Factor de Ajuste obtenido en base a unas valoraciones
subjetivas sobre la aplicacin y su entorno. Es decir las caractersticas generales del
sistema.
Tipos de funciones:
Datos y
Transacciones
Funciones de Datos
Representan la funcionalidad proporcionada a los usuarios para cumplir con sus requisitos
de datos internos y externos.
Son de dos tipos:
Ficheros Lgicos Internos y
Ficheros de Interfaces Externos.
Ficheros Lgicos Internos (ILF)
Un Fichero Lgico Interno es un grupo de datos lgicamente relacionados identificables por
los usuarios o informacin de control mantenidos y utilizados dentro de los lmites de la
aplicacin.
Ejemplos de ILF son:
Ficheros maestros
Aplicaciones de Seguridad de Datos
Datos de Auditora Actualizados por la aplicacin
Mensajes de Error Actualizados por la aplicacin
Ficheros Internos Lgicos mantenidos por ms de una aplicacin
Ficheros Interfase Externos (EIF)
Representan un grupo de datos relacionados lgicamente identificables por el usuario o
informacin de control utilizada por la aplicacin de solo lectura, pero mantenida por otra
aplicacin.
Funciones de Transaccin
Comprende tres tipos de funcin:
Entradas externas (EI): mantiene datos almacenados internamente.

Salidas externas (EO): datos de salida de la aplicacin.
Consultas externas (EQ): Combinacin de una entrada (pregunta) y de una salida
(respuesta).
72
Entradas Externas (EI. External Input)

Las Entradas Externas son datos o informacin de control que se introducen en la aplicacin
desde fuera de sus lmites. Comprende el mantenimiento de un Fichero Lgico Interno (ILF),
es decir: altas, bajas y eliminaciones.
Ejemplos de este tipo de funcin son:
Las pantallas de entrada.
Las entradas por lotes.
Las entradas externas duplicadas (banco)
Salidas Externas (EO. External Output)
Las Salidas Externas son datos o informacin de control que sale de los lmites de la
aplicacin. Esta salida debe ser considerada nica si tiene un formato nico o si el diseo
lgico requiere un proceso lgico distinto de otras salidas del mismo formato. Toda salida ha
de requerir un proceso de clculo de la informacin que se proporciona.
Ejemplos
Transferencia de datos a otras aplicaciones (vista lgica de un archivo fsico, vista lgica
de 2 o ms archivos fsicos)
Los grficos estadsticos y datos estadsticos en formato tabla
Los generadores de informes
No se deben contar como Salidas:
Las ayudas
Las distintas formas de invocar la misma salida lgica
Los mensajes de error/confirmacin distintos a salidas externas
Los informes Ad Hoc: Cuando el usuario dirige y es responsable de la creacin mediante
la utilizacin de lenguajes como SQL de un nmero indefinido de informes, no se cuentan
como salidas.
Consultas Externas (EQ. External Query)
Las consultas representan los requisitos de informacin a la aplicacin en una combinacin
nica de entrada/salida que se obtiene de una bsqueda de datos, no actualiza un Fichero
Lgico Interno y no contiene datos derivados. Una consulta se considera nica si tiene un
formato distinto de otras consultas, ya sea en entrada o salida, o si el diseo lgico requiere
ediciones distintas a las de otras consultas.
Se entiende por datos derivados aqullos que requieren un proceso distinto a la bsqueda
directa, edicin o clasificacin de informacin de Ficheros Lgicos Internos o Ficheros
Interfases Externos.
Ejemplos:
La bsqueda inmediata de datos.
Las consultas no explcitas. Las pantallas de modificacin/borrado que proporcionan
capacidad de bsqueda de datos
73
Pantallas de conexin. Las pantallas de logon que proporcionaran seguridad se cuentan

como una consulta
Los mens con consultas implcitas: Las pantallas de men que proporcionan una
seleccin de pantallas y entradas para la bsqueda de datos para la pantalla llamada, se
cuenta como una Consulta.
Las ayudas: Son una consulta donde la entrada y la salida (texto) son nicas. Un texto
que puede ser accedido o mostrado en pantalla mediante distintas peticiones o diferentes
reas de una aplicacin se cuenta como una consulta.
Las salidas duplicadas: Consultas iguales que producen una salida en diferentes
soportes, como consecuencia de especificaciones del usuario, se cuentan como
consultas distintas.
Tutoriales: Los sistemas de software relativos a la formacin de usuarios debera
contarse como un sistema distinto.
No se consideran como Consultas:

Los mensajes de Error/Confirmacin.
La utilizacin de distintos mtodos de llamada a la misma consulta.
Valoracin de la Complejidad
Para cada uno de los parmetros externos se ha de indicar su complejidad como Baja,
Media o Alta. Para las entradas, salidas y consultas, se puede evaluar su complejidad en
funcin del nmero de campos que contengan y del nmero de ficheros a los que hagan
referencia. Para los ficheros, por el contrario, su complejidad vendr dada en funcin del
nmero de registros y de campos que tengan.
Valoracin de la complejidad de los tipos de funcin datos
A cada ILF y EIF identificado se le asigna una complejidad funcional que es funcin del
nmero de tipos de elementos datos (DETs) y el nmero de tipos de elementos registros
(RETs) de los que estn compuestos, y que vienen expresada mediante las tablas de
contribucin y complejidad.
Elementos datos (DETs). Un tipo de elemento dato es un campo nico y no recursivo sobre
un tipo de funcin datos y que es reconocible por el usuario. Normalmente se corresponden
con los atributos de las entidades lgicas de usuario.
Elementos registros (RETs). Un tipo de elemento registro es un subgrupo de datos
elementales reconocibles por el usuario dentro de un tipo de funcin datos. Los subgrupos
son de dos tipos; opcionales y mandatorios. Los grupos opcionales son aquellos que el
usuario tiene la opcin de incluir o no mediante un proceso elemental que aada o cree una
instancia dentro un tipo de funcin datos. Los grupos mandatorios son aquellos en los que
el usuario debe incluir cuando se crea o aade una instancia.
RET
DET
1 a 19
20 a 50
Baja
Baja
51
o
ms
Media
2 a 5
Baja
Media
Alta
6
o Media
Alta
UTSAM-Modalidad
Semipresencial
y a Distancia
ms
Alta
74
Valoracin de la complejidad de los tipos de funcin transaccin

Para este tipo de valoracin, adems de los DETs, se requiere del nmero de tipos fichero
referenciados (FTRs).
Valoracin de la complejidad de las entradas externas EI
A cada El se le asigna una complejidad funcional que es funcin del nmero de tipos de
elementos datos (DETs) que procese el procedimiento elemental, y el nmero de tipos
ficheros referenciados (FTRs)) a los que acceda tal proceso. Viene expresada mediante las
tablas de contribucin y complejidad.
FTR
DET
1 a 4
B a ja
B a ja
M ed ia
0 a 1
2
3 o m s
5 a 15
B aja
M ed ia
A lta
16 o m s
M e d ia
A lta
A lta
Valoracin de la complejidad de las salidas externas EO

A cada EO identificada, asignarle una complejidad funcional basada en el nmero de tipos
ficheros referenciados (FTRs) por el proceso elemental de dicha EO y el nmero de tipos
elemento de datos (DETs) que la forman. Viene expresada mediante las tablas de
contribucin y complejidad.
FTR
0 a 1
2 a 3
4 o ms
D ET
1 a 5
B aj a
B aj a
M e dia
6 a 19
B aj a
M e dia
A lt a
20 o ms
M e di a
A lta
A lta
Valoracin de la complejidad de las consultas externas EQ

A cada EQ que ha sido identificada, asignarle una complejidad funcional basada en el
nmero de tipos fichero referenciados (FTRs) y de tipos elemento de datos (DETS) que
intervienen en el proceso de la componente de entrada y de la componente de salida
respectivamente. Una vez calculada ambas complejidades, escoger la ms alta entre la de la
entrada y la de la salida, y traducirla a nmero de puntos de funcin sin ajustar segn las
tablas de contribucin y complejidad.
A continuacin se llena los parmetros determinados de complejidad de ILF, EIF, EI, EO, EQ,
en la tabla que se presenta a continuacin. Se obtendr el total de puntos de funcin sin
ajustar.
PARAMETRO
COMPLEJIDAD NUMERO X PESO TOTAL
75
ILF
EIF
EI
EO
EQ
ALTA
MEDIA
BAJA
ALTA
MEDIA
BAJA
ALTA
MEDIA
BAJA
ALTA
MEDIA
BAJA
ALTA
MEDIA
BAJA
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
15
10
7
10
7
5
6
4
3
7
5
4
6
4
3
Utilizando la herramienta CASE COCOMO II se calcula los puntos de funcin y las LDC:
76
2
1.
2.
3.
4.
5.
Valor costo/mes que debe ingresarse

Tamao del software en LDC
Esfuerzo hombre/mes
Costo total del software
# de personas
DECISIN DE DESARROLLAR-COMPRAR.
TAREAS DEL CRDITO 4
TAREAS
CRDITO
4
En muchas reas de aplicacin del
software,DEL
a menudo
es ms rentable
adquirir el software
de
computadora
que
desarrollarlo.
En
una
empresa
antes
de
desarrollar
adquirir
Realiza las siguientes actividades con el propsito de desarrollar habilidades en el o
proceso
de un
Realiza las siguientes actividades con el propsito de desarrollar habilidades en el proceso de
software,
recomienda
analizar las diferentes posibilidades:
gestin
delse
proyecto
de software:
gestin del proyecto de software:
Conceptualice
siguientes
trminos:
Conceptualice
Construir ellos
software
desde
el inicio
los siguientes
trminos:
Gestin
Gestin
Reutilizar los componentes de otro SW para construir el nuevo
Estimacin
Estimacin
Comprar o adquirir un software disponible y adaptarlo a las necesidades
Proyecto
Proyecto
Proyecto
Contratar
el desarrollo del software a un vendedor externo.
de software
Proyecto de software
COCOMO
COCOMO
Subcontratacin
Las actividades
dede
ingeniera
Mediante un grfico(outsourcing).
explique las etapas
de la gestin
proyectosde software se contratan a
Mediante
un
grfico
explique
las etapas
decostoasegurando
la gestin de proyectos
un
tercero,
quien
hace
el
trabajo
a
bajo
unapara
alta desarrollar
calidad. Eluna
trabajo de
Realice un ensayo de mnimo 150 palabras sobre los elementos
Realice
un
ensayo
de
mnimo
150
palabras
sobre
los
elementos
para
desarrollar
una
software
llevado
de la compaa
se reduce a una actividad de gestin de contratos.
gestin eficaz
dedentro
un proyecto
de software.
gestin eficaz de un proyecto de software.
Cmo organizar un equipo para el desarrollo de software?
Cmo organizar un equipo para el desarrollo de software?
Cules son las tareas identificables a realizar por un director de proyectos, dentro del
Cules son las tareas identificables a realizar por un director de proyectos, dentro del
rea de la gestin de proyectos?
rea de la gestin de proyectos?
Cules son los objetivos de la planificacin del proyecto de software?
Cules son los objetivos de la planificacin del proyecto de software?
Qu es el mbito del software?
Qu es el mbito del software?
En que consiste el estudio de factibilidad?
En que consiste el estudio de factibilidad?
Describa el proceso de estimacin del software mediante la tcnica de los puntos de
Describa el proceso
de estimacin
del software mediante la tcnica de los puntos de 77
UTSAM-Modalidad
Semipresencial
y a Distancia
funcin
funcin
Realice el tercer avance de su proyecto final que involucra el Estudio de Factibilidad, la
Planificacin General del proyecto de software incluido el proceso de Estimacin y la
organizacin del equipo de trabajo.
3. PLANIFICACIN TEMPORAL Y SEGUIMIENTO DEL PROYECTO
La planificacin temporal y el seguimiento del proyecto tienen como objetivo primordial evitar los
retrasos en las entregas del software.
Causas de los retrasos:
Fechas lmite de entrega poco realistas.

Cambio de los requisitos que no se reflejan en la planificacin temporal
Subestimacin honesta del esfuerzo y/o recursos.
Riesgos predecibles e impredecibles no considerados.
Dificultades tcnicas y humanas
Falta de comunicacin entre la plantilla.
Falta de reconocimiento del retraso en un proyecto.
Falta de medidas para corregir el problema.
Las fechas lmite poco realistas son bastante frecuente en el desarrollo de software, jams
debemos empezar un proyecto sabiendo que la fecha impuesta es imposible de alcanzar.
Tampoco es factible cambiar la fecha, pues por lo general, est impuesta por la ley del
mercado.
Solucin:
78
Realizar una estimacin detallada (productividad>25%).

Utilizar un modelo incremental que implemente la funcionalidad crtica mnima para la
fecha lmite impuesto.
Reunirse con los clientes y explicar la situacin.
Cmo se retrasan las planificaciones temporales en los proyectos?

diariamente [Fred Brooks]
Cmo se cumplen las planificaciones temporales en los proyectos?
diariamente [Antonio Navarro]
Planificacin temporal
Es la culminacin de una actividad de planificacin, componente primordial de la direccin de
proyectos de software. Cuando se combinan mtodos de estimacin y anlisis de riesgos, la
planificacin temporal se convierte en un mapa de carreteras a seguir por el gestor de
proyectos.
La planificacin temporal empieza con la descomposicin del proceso. Las caractersticas
del proyecto se emplean para adaptar un conjunto de tareas apropiado al trabajo a realizar.
Una red de tareas muestra todas las tareas de la ingeniera, sus dependencias con otras
tareas y sus duraciones previstas. La red de tareas (PERT) se usa para calcular el camino
crtico del proyecto, un grfico de tiempo e informacin diversa del proyecto (GANTT). El
gestor del proyecto puede seguir y controlar todos los procesos de software usando la
planificacin temporal como directriz.
Construccin de un cronograma de actividades. Mediante MS Project
WBS (Work Breakdown Structure): Estructura de las tareas en las que se descompone el
proyecto.
Tipos de dependencias entre tareas
FC (de Fin a Comienzo) la ms habitual
CC (de Comienzo a Comienzo)
FF (de Fin a Fin)
CF (de Comienzo a Fin) suele ser
problemtica
Ejemplo:
79
Diseo
Diseo
Web
Web
Desarrollo
Desarrollo
Web
Web
Anlisis
Anlisis
Integracin
Integracin
Diseo
Diseo
Admin
Admin
ImplanImplantacin
tacin
Desarrollo
Desarrollo
Admin
Admin
Asignacin de recursos y personas a las tareas
Optimizacin. Conceptos clave para la optimizacin del proyecto:

Paso adelante
Paso atrs
Ruta crtica
Reasignacin de recursos
Paso adelante
Estimar la fecha ms temprana para comenzar y terminar cada tarea

Comenzando por la fecha de inicio del proyecto
Estima la fecha de fin ms optimista
80
Paso atrs
Estimar cuales pueden ser las fechas mas retrasadas para el inicio y fin de cada tarea
sin causar retrasos en el proyecto.
Se puede estimar con la fecha de entrega calculada por paso adelante, o con la fecha
de entrega deseada
Al calcular con la fecha de entrega por paso adelante se debe obtener a la misma
fecha de inicio.
Al calcular con la fecha de entrega esperada se obtiene la fecha lmite para comenzar
el proyecto
Demora total
Diferencia entre las fechas calculadas con paso adelante y paso atrs para cada tarea
Retraso mximo para una tarea sin retrasar sin afectar a la fecha de entrega del proyecto
La demora total se comparte entre las tareas en una cadena. Si se emplea en una tarea
ya no queda disponible para otras.
81
Demora permisible. Tiempo que puede retrasarse una tarea sin afectar a la agenda del
proyecto
Algunos programas como MS Project pueden hacer los clculos de forma
82
Ruta crtica. Es la ruta ms larga en el plan del proyecto, y delimita la fecha de entrega ms
temprana posible
Actividades crticas. Actividades que estn en la ruta crtica y que no tienen demora
permisible. Sus retrasos afectan al proyecto.
Optimizacin de agenda
1.- Dirigir el esfuerzo de trabajo sobre las actividades de la ruta crtica
2.- Revisar la asignacin de personas
3.- Modificar la asignacin de recursos

4.- Redistribuir a las personas
Recomendaciones
Duplicar la asignacin de personas no significa la mitad de tiempo
Menos tiempo de entrega no significa menor presupuesto
Cada tarea debe tener un resultado cuantificable para comprobar que se ha realizado
Usar el sentido comn
83
SEGUIMIENTO DE LA PLANIFICACIN
El seguimiento es un factor clave en la planificacin temporal. Hay distintas formas de
implementarlo:
Realizando reuniones peridicas.
Evaluando los resultados de las revisiones.
Determinando si se han conseguido los hitos.
Recavando las opiniones subjetivas del equipo.
Comparando la fecha real de inicio con las previstas.
Utilizando el anlisis del valor ganado.
La comparacin de las fechas reales y de inicio puede hacerse:
Mediante tablas.
Utilizando diagramas Gantt de seguimiento.
R
I
E
S
G
O
S
4. GESTIN DE RIESGOS
IDENTIFICACIN
ANLISIS
TRATAMIENTO
Plan de gestin
de riesgos
D
E
GE
S
T
I
IEEE Std P1540-2001
84
El riesgo. Se halla de forma implcita asociado a toda actividad:

Todo suceso se ve marcado por las acciones del pasado, Se puede, por tanto,
actuar ahora para crear oportunidades en el futuro?
El riesgo acompaa a todo cambio
El riesgo implica eleccin e incertidumbre.
Estrategias reactivas. Consiste en tomar acciones una vez ocurrido el riesgo. Los mtodos
que se pueden aplicar comprenden: la evaluacin de las consecuencias del riesgo cuando
este ya se ha producido (ya no es un riesgo) y actuar en consecuencia. Las consecuencias
de una estrategia reactiva pueden ser: apagado de incendios, gabinetes de crisis, se pone el
proyecto en peligro.
Estrategias proactivas. Antes de que ocurra el riesgo, se analizan y se planifican
estrategias de prevencin de los riesgos. Como mtodo de prevencin se pueden ejecutar
las siguientes actividades: evaluacin previa y sistemtica de riesgos, evaluacin de
consecuencias, plan de evitacin y minimalizacin de consecuencias, plan de contingencias.
Algunas posibles consecuencias son la evasin del riesgo, menor tiempo de reaccin,
justificacin frente a los superiores.
Riesgo del software. Implica dos caractersticas: Incertidumbre (probabilidad de que
ocurra) y prdida, si el riesgo se convierte en realidad.
Categoras de los riesgos:
Riesgos del proyecto: implica incremento en costes y desbordamiento organizativo
Riesgos tcnicos
Riesgos del negocio:
De mercado
De estrategia
De ventas
De gestin
De presupuesto
IDENTIFICACIN DE RIESGOS. La identificacin del riesgo es un intento sistemtico para
especificar las amenazas al plan de proyecto (estimaciones, planificacin temporal, carga de
recursos, etc.). Existen dos tipos de riesgos para cada categora presentada anteriormente:
Genricos: Son comunes a todos los proyectos
Especficos: Implican un conocimiento profundo del proyecto
Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de
riesgo basado en las siguientes subcategoras:
Relacionados con el tamao del producto
Con el impacto en la organizacin
Con el tipo de cliente
Con la definicin del proceso de produccin
Con el entorno de desarrollo
Con la tecnologa
Con la experiencia y tamao del equipo
85
Componentes del riesgo. Los componentes de riesgo se definen de la siguiente manera:

Rendimiento
Coste
Mantenibilidad
Planificacin
El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro
categoras de impacto: despreciable, marginal, crtico y catastrfico.
ESTIMACIN DE RIESGOS. Denominado tambin proyeccin del riesgo. Intenta medir el
riesgo de dos maneras: la probabilidad de que el riesgo sea real y las consecuencias de los
problemas asociados con el riesgo, si ocurriera. Se realiza cuatro actividades de proyeccin
del riesgo:
1. Establecer una escala que refleje la probabilidad percibida del riesgo,
2. Definir las consecuencias del riesgo,
3. Estimar el impacto del riesgo en el proyecto y el producto y
4. Apuntar la exactitud general de la proyeccin del riesgo de manera que no haya
confusin.
Creacin de una tabla de riesgos:
Ordenacin y filtrado
Ordenacin por probabilidad y prioridad
Despreciar riesgos poco probables y los medianamente probables con poco impacto
Factores que definen el impacto de la ocurrencia de un riesgo

86
Alcance del mismo: cun serio y cunto del proyecto se ve afectado

Temporalizacin de los efectos, cundo y por cunto tiempo
Cundo desistir y finalizar el proyecto

Se debe definir un punto de referencia
Se debe marcar la relacin entre cada factor de riesgo enumerado y el punto de
referencia
Definir el rea de incertidumbre, donde ser tan vlido continuar como interrumpir el
trabajo
Predecir cmo la combinacin de riesgos afectar a los niveles de referencia
Gestin, Monitorizacin y Mitigacin de Riesgos (RMMM)
Objetivo: Marcar las estrategias y formas de actuar del equipo de trabajo frente a los riesgos:
Como evitarlos
Como monitorizarlos
Como gestionarlos y plan de contingencia
Evitacin del riesgo
Definir las estrategias necesarias para evitar que el riesgo no se produzca
Tomar las medidas encaminadas para que, an cuando se produzca, se minimecen sus
efectos
Monitorizacin del riesgo
Definir los indicadores que influyen en la probabilidad de que el riesgo se produzca
Monitorizar peridicamente dichos factores
Monitorizar la efectividad real de las acciones encaminadas a evitar el riesgo
Gestin del riesgo y plan de contingencia
Se asume que la evitacin y la monitorizacin han fallado y el riesgo se ha producido
Se definen las estrategias y acciones a tomar para evitar que los efectos se minimicen
Nunca se podr reducir a cero el coste del plan de contingencia. Dicho plan puede
implicar unos costes en s mismo, por lo cual se ha de valorar el beneficio que se espera
obtener de ste
Riesgos de seguridad y peligros
En general se pueden considerar los riesgos de seguridad y peligros fsicos.
Generalmente, por su importancia, deben tratarse por separado, teniendo que tratarse
como un requerimiento especial, observado en todas las fases del ciclo de vida
Se puede incluir dentro de las actividades de validacin de calidad del producto
PLAN RMMM
87
Introduccin
mbito y propsito del documento
Descripcin de los riesgos principales
Responsabilidades
Gestores
Personal tcnico
Tabla de evaluacin de riesgos
Descripcin de todos los riesgos
considerados
Factores que influyen en la probabilidad e
impacto
RMMM
Riesgo X
Evitacin
Estrategia general
Pasos para mitigar el riesgo
Monitorizacin
Factores a monitorizar
Modo de monitorizacin
Gestin
Plan de contingencias
Consideraciones especiales
Planificacin
TAREAS
TAREASDEL
DELCRDITO
CRDITO55
Conceptualice los siguientes trminos:

GANTT
GANTT
Riesgo
Riesgo
Cul es el objetivo de la planificacin temporal y el seguimiento del proyecto?
Cul es el objetivo de la planificacin temporal y el seguimiento del proyecto?
Describa algunas causas por las que se retrasa un proyecto.
Describa algunas causas por las que se retrasa un proyecto.
Describa los tipos de dependencias entre tareas
Describa los tipos de dependencias entre tareas
Qu es una ruta crtica?
Qu es una ruta crtica?
En qu consiste el seguimiento de la planificacin?
En qu consiste el seguimiento de la planificacin?
Elabore un resumen mediante un organizador grfico de la Gestin de Riesgos
Elabore un resumen mediante un organizador grfico de la Gestin de Riesgos
5. GESTIN DE LA CALIDAD DEL SOFTWARE
Conceptos (ISO 8402)

Calidad: Conjunto de propiedades y caractersticas de un producto o servicio que le
confieren su aptitud para satisfacer unas necesidades explcitas o implcitas
Control de calidad: Conjunto de tcnicas y actividades de carcter operativo, utilizadas
para verificar los requerimientos relativos a la calidad del producto o servicio.
88
Garanta de calidad: Conjunto de acciones planificadas y sistemticas necesarias para

proporcionar la confianza adecuada de que un producto o servicio satisfar los
requerimientos dados sobre calidad.
Gestin de la calidad: Aspecto de la funcin de gestin que determina y aplica la poltica
de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la
planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de la
calidad.
La gestin de la calidad es responsabilidad de todos los niveles ejecutivos, pero debe estar
guiada por la alta direccin. Su realizacin involucra a todos los miembros de la
organizacin.
En la gestin de la calidad, se tienen en cuenta tambin criterios de rentabilidad.
Sistema de gestin de la calidad (QS): Conjunto de la estructura de la organizacin, de
responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a
trmino la gestin de calidad.
El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad.
El QS de una organizacin est fundamentalmente previsto para satisfacer las
necesidades internas de la organizacin. Es ms amplio que los requerimientos de un
cliente concreto que nicamente valor el QS que le interesa (directamente).
Para finalidades contractuales o vinculantes en la valoracin de la calidad, se puede
exigir que se ponga de manifiesto la realizacin de ciertos elementos del QS.
La calidad del software
La calidad del software es el grado con el que un sistema, componente o proceso cumple
los requerimientos especificados y las necesidades o expectativas del cliente o usuario.
(IEEE, Std. 610-1990).
Concordancia del software producido con los requerimientos explcitamente establecidos,
con los estndares de desarrollo prefijados y con los requerimientos implcitos no
establecidos formalmente, que desea el usuario (Pressman, 1998)
Software quality is the degree to which software possesses a desired combination of
attributes (e.g., reliability, interoperability). (IEEE Std. 1061)
Factores que determinan la calidad del software
Se centran en tres aspectos importantes de un producto software (McCall):
Caractersticas operativas
Capacidad de soportar los cambios
Adaptabilidad a nuevos entornos
Satisfaccin del usuario
SATISFACCIN DEL USUARIO =
PRODUCTO SATISFACTORIO +
BUENA CALIDAD +
ENTREGA EN PRESUPUESTO +
ENTREGA EN TIEMPO ESTABLECIDO
89
Control de Calidad del Software

Conjunto de inspecciones, revisiones y pruebas utilizadas a lo largo del ciclo de
desarrollo para asegurar que el producto cumple con los requisitos
Proceso retroalimentado y de medicin
Proceso manual, automtico o semiautomtico
Aseguramiento de la calidad de software (SQA)
SQA engloba:
Un enfoque de gestin de calidad
Tecnologa de Ingeniera de Software efectiva
Revisiones tcnicas formales (RTF) que se aplican durante el proceso del software
Una estrategia de prueba multiescalada
Un control de la documentacin del software y de los cambios realizados
Un procedimiento que asegure un ajuste a los estndares de desarrollo de software
Mecanismos de medicin y de generacin de informes
Calidad del proceso y del producto
DEL PROCESO
Atributos de tcnicas, herramientas, personal, organizacin, facilidades
DEL PRODUCTO
Atributos de documentacin de desarrollo y mantenimiento, cdigo, pruebas
Productividad y calidad
PRODUCTIVIDAD: LDC/mes-persona
INCREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD
Mejor calidad, menor trabajo (+/- 50% de ahorro)
Disminuyen las pruebas
Localizacin temprana de errores a menor costo
DECREMENTO DE LA PRODUCTIVIDAD CON LA CALIDAD
Mejor calidad requiere inversin que se recupera en la entrega
La revisin de los productos de desarrollo mejora la calidad pero disminuye la
productividad
Las tcnicas de calidad insisten en detalles que pueden constituirse en obstculos
para el trabajo
PLAN DE GARANTA DE LA CALIDAD

Introduccin
Propsito
Definiciones, acrnimos y abreviaturas
Referencias
Especificaciones de gestin
Organizacin
Responsables
Grupo de garanta de la calidad del software
Documentacin
90
Revisin de la gestin
Revisin de los requisitos del software
Revisin de diseo
Revisin del producto
Revisin de operacin.
Gestin de configuracin
Gestin de problemas y acciones correctivas
6. GESTIN DE CONFIGURACIN DE SOFTWARE (GCS)
Es la tarea de identificar, organizar y controlar las modificaciones que sufre el software a lo

largo de toda su vida til, es un control de cambios.
La meta a alcanzar es maximizar la productividad minimizando los errores cometidos. Se
aplica a lo largo de todo el proceso de ingeniera del software.
Las actividades de GCS sirven para:
1.
2.
3.
4.
5.
6.
Identificar el cambio.
Controlar el cambio.
Estado.
Auditora y revisin.
Garantizar que el cambio se implementa correctamente.
Informar del cambio a todos aquellos que se vean afectados.
Elementos de Configuracin del software (ECS)

Al aplicarse el proceso de ingeniera del software se genera una informacin que se puede
dividir en tres clases:
1. Programas de ordenador (ejecutables y cdigo fuente).
2. Documentos descriptivos de las aplicaciones (tanto tcnicos como de usuario).
3. Datos (datos internos del programa o externos a l).
Todos los elementos que componen la fuente de informacin producida como resultado del
proceso de ingeniera se conocen como ELEMENTOS DE CONFIGURACIN DEL
SOFTWARE.
Lneas base
En el contexto de la ingeniera del software, definimos una lnea base como un punto de
referencia en el desarrollo del software que queda marcado por la revisin, evaluacin y
aprobacin de unos elementos software relacionados.
Las tareas de ingeniera del software producen una o ms ECS. Una vez que un ECS se ha
revisado y aprobado, se coloca en una base de datos del proyecto (biblioteca del proyecto o
depsito de software), se convierten en lnea base.
91
Cuando un miembro del equipo de ingeniera del software quiere hacer modificaciones en un
ECS de lnea base, se copia de la base de datos del proyecto en un rea de trabajo privada
del ingeniero. Sin embargo este ECS solo se puede modificar siguiendo todas las directrices
exigidas en la gestin de configuracin del software.
Versin
Una versin es una instancia de un elemento de configuracin.
El trmino se utiliza indicar un elemento de configuracin que tiene un conjunto de
caractersticas funcionales.
Revisin
Se define revisin como una versin que se construye sobre otra versin anterior.
Variante
Es una versin alternativa a otra versin. Las variantes permiten a un elemento de
configuracin satisfacer elementos en conflicto.
Una variante en una nueva versin de un elemento que ser aadida sin reemplazar a la
versin anterior.
Proceso de GCS
El proceso de GCS se divide en 5 tareas:
Identificacin.
Control de versiones.
Control de cambios.
Auditorias de configuracin.
Generacin de informes.
Identificacin
Se puede tener dos tipos de objetos: objetos bsicos y objetos compuestos.
Un objeto bsico es una unidad de texto creado por un ingeniero del software durante el
anlisis, diseo, codificacin o pruebas.
Un objeto compuesto es un grupo de objetos bsicos o de otros compuestos.
Cada objeto tiene una coleccin de atributos que le identifican unvocamente.
Control de versiones
92
El control de versiones est formado por procedimientos y herramientas para gestionar las
versiones de los objetos de configuracin creadas durante el proceso de ingeniera del
software.
Para representar las diferentes versiones se puede utilizar un grafo de evolucin o el fondo
de objetos.
Control de cambios
El control de cambios proporciona formas de control humano y herramientas automatizadas
para controlar los mecanismos de control de cambio.
Se reconoce la necesidad del cambio
El usuario suscribe la peticin del cambio
El desarrollador la evala
Se genera un informe de cambios
La autoridad de control de cambios decide
La peticin queda pendiente de actuacin,
se genera la OCI (orden de cambio de ingeniera)
Asignacin personalizada los objetos de configuracin
Peticin de cambio denegada

Informacin al usuario
Dar de baja objetos (elementos) de configuracin

Realizacin del cambio
Revisin de cambio (auditora)
Los elementos de configuracin que han cambiado son dados de alta
Establecimiento de una lnea base para la prueba
Realizacin de actividades de garanta de calidad y de prueba
Promocin de los cambios para ser incluidos en la siguiente versin (revisin)
Reconstruccin de la versin adecuada del software
Revisin (auditora) de los cambios en todos los elementos de configuracin.
Cambios incluidos en la nueva versin
Distribucin de la nueva versin
Proceso de Control de Cambios

Control de acceso y de sincronizacin
93
Alta
Objeto de configuracin
(versin de lnea base)
(versin modificada)
Inf. de auditora
Ingeniero
de software
Desbloqueo
Control de
acceso
Info. de pertenencia
Base de datos
del proyecto
Bloqueo
(versin extrada)
Baja
(versin de lnea base)
Auditora de configuracin
La auditora responde a estos nuevos elementos:
1. Se ha realizado exactamente los cambios especificados en la OCI? Se han
incorporado las modificaciones adicionales?
2. Se ha llevado a cabo una revisin tcnica formal para evaluar la correccin tcnica?
3. Se ha aplicado los estndares de ingeniera del software?
4. Se han reflejado lo suficiente los cambios en el ECS? Se ha reflejado la fecha del
cambio y el nombre del autor del cambio? Reflejan los cambios los atributos del
objeto de configuracin?
5. Se han seguido procedimientos del GCS para sealar el cambio, registrarlo y
divulgarlo?
6. Se han actualizado adecuadamente todos los ECS relacionados?
Informes de Estado
De la generacin de informes de estado de la configuracin (contabilidad de estado) se
encarga la gestin de configuracin del software, la cual responde a las siguientes
preguntas:
1. Qu sucedi?
2. Quin fue el autor?
3. En qu fecha ocurri?
4. Cuntos elementos se vieron afectados?
Plan de Gestin de la Configuracin
Introduccin
Propsito del plan
Alcance
Definiciones y acrnimos
Referencias
Especificaciones de gestin
Organizacin
Responsabilidades
94
Actividades de gestin de la configuracin

Jerarqua preliminar del producto
Seleccin de los elementos de configuracin
Esquema de identificacin de los ecs
Esquema de identificacin de versiones y revisiones
Definicin de relaciones
Relacin de equivalencia
Relacin de composicin
Definicin y establecimiento de lneas base
Definicin y establecimiento de bibliotecas de software
Control de cambios
Anexos
Anexo 1: solicitud de cambio
Anexo 2: certificacin del cambio
Anexo 3: contabilidad del estado de la configuracin
TAREAS
TAREASDEL
DELCRDITO
CRDITO66

Calidad
Calidad
Control de calidad
Control de calidad
Garanta de calidad
Garanta de calidad
Gestin de la calidad
Gestin de la calidad
Sistema de gestin de la calidad
Sistema de gestin de la calidad
Calidad del software
Calidad del software
Satisfaccin del software
Satisfaccin del software
ECS
ECS
Qu actividades comprende el aseguramiento de la calidad de software?
Qu actividades comprende el aseguramiento de la calidad de software?
Enumere las actividades de la gestin de la configuracin del software
Enumere las actividades de la gestin de la configuracin del software
Elabore un resumen mediante un organizador grfico de calidad y gestin de la
Elabore un resumen mediante un organizador grfico de calidad y gestin de la
configuracin del software
configuracin del software
Realice el CUARTO AVANCE DE SU PROYECTO FINAL que involucra el Plan de
Realice el CUARTO AVANCE DE SU PROYECTO FINAL que involucra el Plan de
Calidad del Software y el Plan de la Gestin de Calidad del Software.
Calidad del Software y el Plan de la Gestin de Calidad del Software.
AUTOEVALUACIN
AUTOEVALUACINTEMA
TEMAIIIIII
95
1.
Complete:
a.
Gestin:
....................................................................................................................
....................................................................................................................
b.
Personas
....................................................................................................................
....................................................................................................................
....................................................................................................................
....................................................................................................................
....................................................................................................................
c.
Calidad
....................................................................................................................
....................................................................................................................
....................................................................................................................
d.
Riesgo:
....................................................................................................................
....................................................................................................................
....................................................................................................................
e.
Cronograma: .. ..
..
....................................................................................................................
....................................................................................................................
f.
Qu son puntos de funcin?:
....................................................................................................................
....................................................................................................................
....................................................................................................................
2. Cmo se realiza la valoracin de los tipos de funcin en la tcnica de los PF
96
3. Qu son los ECS y qu aspectos se considera ECS?
4. Realice un ensayo sobre el proceso de gestin de riesgos
TUTORAS
TUTORASPROGRAMADAS
PROGRAMADAS
Consulte en su centro de informacin o a su tutor el horario de los encuentros presenciales,
y/o virtuales (Chat) o las consultas por telfono. Anote a continuacin para que lo tenga en
cuenta en el desarrollo de este tema:
Fecha
Hora
Actividad
97
MODELADO DE ANLISIS DEL

SOFTWARE
INTRODUCCIN AL MODELADO
Conceptos de modelado,
utilidad, abstraccin, ventajas
Comprender la
importancia del modelado
de software
ANLISIS ESTRUCTURADO
Breve historia,
caractersticas
Elementos del modelo del
anlisis
Modelado funcional o de
procesos y flujo de
informacin(DFDs), su notacin y
diccionario de datos
Modelado de datos (ER) y
su diccionario de datos
HERRAMIENTAS CASE (TI)
Que es CASE
Objetivos de las CASE
Elementos de las CASE
Tipos de CASE
Ejemplos de CASE
Obtener una
representacin general del
software a construir a partir
de la especificacin de los
requisitos.
Identificar los tipos

de CASE
Utilizar las
herramientas CASE apara
el desarrollo del software
SISTEMA DE
VALORES
Responsabilidad
Criticidad
Honestidad
Compaerismo
Responsabilidad
Criticidad
Honestidad
Compaerismo
Responsabilidad
Criticidad
Honestidad
Compaerismo
TIEMPO
TIEMPOESTIMADO
ESTIMADODE
DEESTUDIO
ESTUDIO
Horas presenciales:
8
8
16
8
24
INTRODUCCIN
INTRODUCCIN
101
El Anlisis de Sistemas, descompone el software en componentes para estudiarlos:

aisladamente e interactuando con el resto. Sirve para identificar requisitos insuficientes,
para representar los requisitos funcionales del software en modelos grficos de datos, lo
que permite mejora de la comprensin y validar requisitos. Mediante revisin se logra:
correccin, integridad, consistencia de los requisitos.
OBJETIVO
Elaborar el modelado del software mediante el estudio y anlisis de los requisitos

del software, las metodologas de anlisis y la elaboracin del prototipo que
permita la obtencin de modelos fsicos y lgicos para el diseo del software.
ESQUEMA
ESQUEMADEL
DELTEMA
TEMAIV
IV
102
ACTIVIDADES
ACTIVIDADESDE
DEAPRENDIZAJE
APRENDIZAJETEMA
TEMAIV
IV
Para el estudio del Tema IV necesitas revisar la siguiente bibliografa:

Sexta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005.
Captulos: 1, 2, 3, 4; Pginas:1-99.
Quinta Edicin. Mc-Graw-Hill/Interamerica de Espaa S.A.U. 2005.
Captulo: 12; Pginas: 199-218.
Kendall & Kendall, Anlisis y Diseo de software.
Estudio de Factibilidad: Pginas: 47- 53
Planificacin del proyecto: Pginas: 54-74
Calidad del Software: Pginas: 745-765
1. INTRODUCCIN AL MODELADO DEL SOFTWARE
El modelado del software representa las funciones y subfunciones de un Sistema. Los

modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos
modelos pueden incluir notacin grfica, informacin y comportamiento del Sistema.
Todos los Sistemas basados en computadoras pueden modelarse como transformacin
de la informacin empleando una arquitectura del tipo entrada y salida.
La base para el modelado de anlisis del software es la Especificacin de los requisitos
del software (ERS).
Qu es un modelo?
Un modelo es una simplificacin de la realidad
Un modelo es el resultado de un proceso de abstraccin y ayuda a comprender y
razonar sobre una realidad
Un modelo de software es una descripcin de un aspecto del sistema, expresada
en un lenguaje bien definido.
Divisin del producto
Se fracciona el producto de modo que cada fragmento lo puede realizar un integrante del
equipo de desarrollo.
Ejemplo de un modelo de software
103
Modelado del Software. Comprende el modelado es el anlisis y diseo de aplicaciones

software antes de escribir el cdigo. Se crean un conjunto de modelos (planos del
software) que permiten especificar aspectos del sistema como los requisitos, la
estructura y el comportamiento.
Utilidad del modelado.
Una empresa software con xito es aquella que produce de manera consistente
software de calidad que satisface las necesidades de los usuarios
El modelado es la parte esencial de todas las actividades que conducen a la
produccin de software de calidad
Abstraccin - Modelado Visual (MV). El modelado captura las partes esenciales del
sistema. Parte del proceso de negocio para representar en un modelo visual la solucin
del sistema computacional.
104
Algunas ventajas del modelado visual:

Hay estructuras que no son visibles en los programas.
Ayuda a razonar sobre el cmo se implementa.
Se facilita la comunicacin entre el equipo al existir un lenguaje comn.
Se dispone de documentacin que trasciende al proyecto.
Generacin de cdigo a partir de modelos
Ha surgido un nuevo paradigma de desarrollo de software a partir de los modelos
Los modelos:
visualizan cmo es o queremos que sea el sistema
especifican la estructura y comportamiento del sistema.
guan la construccin del sistema.
documentan las decisiones.
2.
ENFOQUES DE MODELADO DE ANLISIS
105
Existen dos enfoques claramente establecidos:

1. Anlisis Estructurado. Comprende actividades como:
Separacin datos y procesos
Modelado de Datos
Atributos y relaciones
Modelado de Procesos
Transformacin de datos
2. Anlisis Orientado a Objetos
Definicin de clases
Colaboracin entre las clases
3. ANLISIS ESTRUCTURADO
Breve Historia
Es una tcnica de modelado del flujo, contenido y transformacin de la informacin que
fluye por un sistema. Naci como complemento al Diseo Estructurado. El trmino
Anlisis Estructurado fue popularizado por DeMarco a fines de los 70, quien present y
denomin los smbolos grficos que permitiran al analista crear modelos de flujos de
informacin.
Yourdon, Gane y Sarson y otros presentaron variaciones a la propuesta original. A
mediados de los 80, Ward y Mellor proponen ampliaciones para su aplicacin en
sistemas de tiempo real y ms tarde, Hatley y Pirbhai presentan sus aportes a estos
mismos sistemas.
Caractersticas
Descomposicin / Modularizacin
Soporte grfico
106
Ausencia de Redundancia
Centrado en modelizar el flujo y el contenido de la informacin PROCESOS y
DATOS
Aproximacin TOP-DOWN
Elementos del Modelo de Anlisis
Diagramas de Flujo de Datos

(DFDs)
DFD
ER
Diccionario de Datos (DD)
Diagramas de EntidadRelacin (ER)
EP
ED
Diagramas de Transicin de
DD
DTE
EC
Estado (DTEs)
Especificaciones de procesos (EP), de Control (EC) y de Datos (ED)
DIAGRAMAS DE FLUJO DE DATOS (DFDS)
107
Un modelo de proceso es una manera formal de representar cmo funciona un

negocio
Los DFD son una herramienta para el modelado de procesos
Es un proceso de modelado TOP-DOWN, es decir se comienza modelando el
NIVEL 0 o CONTEXTUAL, luego se procede con un refinamiento ms detallado de
sus subprocesos.
Notacin:
DICCIONARIO DE DATOS DEL DFD. Es un conjunto de informacin (datos) sobre

datos, es decir es un conjunto de metadatos, que ayuda a describir el modelado de Flujos
de Datos y permite organizar de forma comn el conocimiento.
108
Objetivos del DD:

Crear un Glosario de trminos
Establecer terminologa estndar
Proporcionar referencias cruzadas
Proporcionar control centralizado para cambios
Ejemplo que permite visualizar la Especificacin de Procesos vs DFD y DD
El diccionario de datos de los DFDs se describe en matrices los procesos, almacenes ,

entidades y flujos de datos
Procesos: Nombre, Descripcin, Nivel, Flujos entrantes, flujos salientes
Flujos de Datos: Nombre, Descripcin, Alias (opcional), Origen y Destino
Almacenes y entidades: Nombre, Descripcin, Flujos entrantes, flujos
salientes
DIAGRAMA ENTIDAD RELACIN
Se utilizan para definir el modelo de datos
Identifican Objetos y sus Relaciones
109
DICCIONARIO DE DATOS DEL DIAGRAMA ENTIDAD RELACIN

Entidades: Nombre de entidad, descripcin, atributos y descripcin de atributos
Relaciones: ID de relacin, entidad padre, entidad(es) hija(s), tipo de relacin,
cardinalidad
4. HERRAMIENTAS CASE.
CASE. Es acrnimo de Computer Aided/Assisted Software/System Engineering.

Comprende un conjunto de herramientas y metodologas que prestan soporte a un
enfoque de ingeniera en el desarrollo de software o en alguna o en todas las fases de
este proceso. La tecnologa CASE supone la informatizacin de la informtica o la
automatizacin del desarrollo del software.
Objetivos:
Permitir la aplicacin prctica de metodologas estructuradas
Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones
Simplificar el mantenimiento de los programas
Mejorar y estandarizar la documentacin
Aumentar la portabilidad de las aplicaciones
Facilitar la reutilizacin de componentes del software
Permitir un desarrollo y un refinamiento visual de las aplicaciones.
Elementos de una herramienta CASE
Repositorio (Diccionario). Donde se almacenan los elementos creados por la
herramienta.
Metamodelo. Marco para la definicin de las tcnicas y metodologas soportadas
por la herramienta.
Generador de Informes. Herramienta que permite obtener la documentacin
sobre el sistema que se est desarrollando.
Carga/Descarga de datos. Para intercambiar datos del repositorio con otros
sistemas.
110
Comprobacin de errores. Analizar la exactitud, integridad y consistencia de los

esquemas.
Interfaz de usuario. Soporte grfico para las interacciones del usuario.
Tipos de herramienta CASE

Herramientas de Gestin. Encargadas de la estimacin, planificacin y seguimiento
del proyecto.
Herramientas Tcnica.
CASE Frontales o superiores, que abarcan las primeras fases del anlisis y del
diseo
CASE dorsales o inferiores, que abarcan el diseo detallado y la generacin del
cdigo.
Herramientas de Soporte. Como el sistema de repositorio/diccionarios, control y
configuracin, seguridad
Ejemplo de algunas herramientas CASE:
Erwing
Visual Case
Easy Case
Power Designer
Weilan LCase
CASO DE ESTUDIO:
Modelar un Sistema de Informacin de compra de libros.
El cliente elabora un pedido de libros
La empresa elabora pedidos de libros a los distintos proveedores.
Los proveedores aportan los libros
Se informa a los clientes que sus libros han llegado
Diagrama de Contexto
Se sabe que para la gestin del sistema de pedidos, se realizan las siguientes funciones:
1. Verificacin de la validez del pedido del cliente
2. Armar los pedidos a los editores
3. Verificar el envo de los editores
111
4. Asignar libros a pedidos

5. Armar entrega a los clientes.
DFD de Nivel 1
TAREAS DEL CRDITO 7

Para desarrollar habilidades en el modelado de anlisis del software, realice las
siguientes actividades:
1.
2.
3.
4.
5.
Ample la investigacin de los DFDs y su diccionario de datos.

Profundice la investigacin del MER y su diccionario de datos
Elabore un resumen de las herramientas CASE
Investigue una herramienta CASE para modelar los DFDs y el MER
Como actividad del crdito 7 debe realizar el ltimo AVANCE FINAL DE SU
PROYECTO. Este avance involucra la elaboracin de su documento de Anlisis del
Software. A continuacin se explican las orientaciones respectivas.
112
Realizar el modelado de anlisis del software segn el enfoque estructurado, del
ORIENTACIONES
ORIENTACIONESPARA
PARAEL
ELPROYECTO
PROYECTOFINAL
FINAL
proyecto final
El Documento de Modelado de Anlisis del Software debe contener el siguiente
formato:

Nombre del Documento (en este caso Modelado de Anlisis del
Software)


versin
1. Introduccin
1.1. Propsito (del documento)
1.3. Referencias
2. Modelado de procesos
2.1. DFDs
2.2. Diccionario de datos de los DFDs
3. Modelado de Datos
3.1. Modelo Entidad Relacin (ER)
3.2. Diccionario de datos del modelo ER
4. Anexos
AUTO
AUTOEVALUACIN
EVALUACIN
113
1. Complete:
a.
En el contexto de los DFD, qu es proceso? :

....................................................................................................................
....................................................................................................................
....................................................................................................................
....................................................................................................................
e. Ventajas del modelado

....................................................................................................................
....................................................................................................................
....................................................................................................................
f. Enfoques del anlisis del software:
....................................................................................................................
....................................................................................................................
....................................................................................................................
2. Describa la notacin de los DFDs
3. Explique el proceso de Modelado de Datos
TUTORAS
TUTORASPROGRAMADAS
PROGRAMADAS
114
Consulte en su centro de informacin o a su tutor el horario de los encuentros

presenciales, y/o virtuales (Chat) o las consultas por telfono. Anote a continuacin para
que lo tenga en cuenta en el desarrollo de este tema:
Fecha
Hora
Actividad
115
ANEXO 1. SOLUCIONES DE AUTOEVALUACIN

SOLUCIONES DE AUTOEVALUACIN AL TEMA I
ENUNCIADO 1:
a.
b.
c.
d.
Verdadero
Falso
Verdadero
Falso, en ingeniera de software, el software no solo a los programas
sino tambin los documentos y datos.
116

Guia Ingenieria Del Software I

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia Ingenieria Del Software I

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TECNOLGICA

SAN ANTONIO DE MACHALA

ING. BERTHA MAZN

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

Recibe pues, un fuerte abrazo de bienvenida y los deseos ms sinceros de ayuda de

UTSAM-Modalidad Semipresencial y a Distancia

Las fechas de las jornadas presenciales confrmelas en su centro universitario,

UTSAM-Modalidad Semipresencial y a Distancia

PROBLEMA, OBJETO, OBJETIVO

La necesidad de aplicar los procesos de ingeniera de software para el desarrollo de

El proceso de ingeniera de software

Desarrollar software de calidad que resuelvan problemas reales de organizaciones,

Fomentar en los estudiantes la prctica de valores como la responsabilidad,

Desarrollo de software de calidad considerando mtodos, tcnicas y herramientas del

UTSAM-Modalidad Semipresencial y a Distancia

INTRODUCCIN A LA INGENIERA DE SOFTWARE (ISW)

MODELADO DE ANLISIS DEL SOFTWARE

UTSAM-Modalidad Semipresencial y a Distancia

Kendall & Kendall, Anlisis y Diseo de software

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

Para el desarrollo de las actividades propuestas se recomienda lo siguiente:

UTSAM-Modalidad Semipresencial y a Distancia

EL TRABAJO ES PERSONAL, NO SE ACEPTARAN

UTSAM-Modalidad Semipresencial y a Distancia

Aplicacin de conocimientos tericos, capacidad de anlisis y sntesis

De acuerdo al sistema de crditos de la UTSAM:

Trabajos de encuentros presenciales: Defensa de trabajos de investigacin, desarrollo de

Slo el estudio libera al

UTSAM-Modalidad Semipresencial y a Distancia

UTSAM-Modalidad Semipresencial y a Distancia

TIEMPO ESTIMADO DE ESTUDIO

ms y ms sistemas son actualmente controlados por software. El software es el producto

Conceptualizar terminologa y modelos de Ingeniera de Software.

UTSAM-Modalidad Semipresencial y a Distancia

Roger S. Pressman. Ingeniera del Software un Enfoque Practico.

Estrategia para desarrollar una actividad de un

Mtodo + tcnicas + soporte documental

Soporte automatizado, Ejm. CASE, CARE

Resultado de cada etapa o actividad, denominado

El software se ha convertido en el elemento clave de la evolucin de los sistemas y

3. MODELOS (PARADIGMAS O CICLOS DE VIDA) DE LA INGENIERA DEL SOFTWARE

La ingeniera de software tiene varios modelos considerados tambin paradigmas o ciclos de

La ingeniera de software es una disciplina muy joven, a finales de la dcada de los 60

UTSAM-Modalidad Semipresencial y a Distancia

Comparativa de proyectos para el desarrollo de sistemas de software

Proyecto no terminado, nunca se llega a utilizar

Fuente: Standish Group Survey

6. PRINCIPALES ORGANIZACIONES DE ESTANDARIZACIN DE LA INGENIERA DE

Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las

UTSAM-Modalidad Semipresencial y a Distancia

7. PRINCIPALES ESTNDARES Y MODELOS DE LA INGENIERA DE SOFTWARE

Los estndares son tiles porque:

UTSAM-Modalidad Semipresencial y a Distancia

Investigue los conceptos de los siguientes trminos:

Realizar una pre-investigacin de una empresa o institucin donde se va a desarrollar el

Cartula (Primera pgina):

Logotipo del proyecto de desarrollo de software

A todas las pginas del documento colocar:

UTSAM-Modalidad Semipresencial y a Distancia

Encabezado de pgina: Cdigo y nombre del documento, nmero de